loading...
Cover image for Programming is Hard

Programming is Hard

somedood profile image Basti Ortiz (Some Dood) ・7 min read

What programming is not about

Programming is not about mashing the keyboard and typing as fast as possible. It is not about religiously memorizing keyboard shortcuts and ultimately rendering the mouse obsolete. It is not about learning every single programming language out there, if that is even possible in the first place. A good programmer is not defined by the brand, price, performance, and operating system of their computer, nor by their preference of code editors and IDEsVS Code, Atom, IntelliJ IDEA, Vim, Notepad++, or otherwise. Contrary to popular belief thanks to many Hollywood films, programming is definitely not equivalent to hacking.

Furthermore, it goes beyond memorizing the syntax and built-in functionalities of a programming language. Logic, conditions, if statements, and algorithms—particularly those of sorting—do not paint a full picture of what programming truly is. Mathematics, recursion, computer science, and design patterns do not do justice to it either. Although they are a huge part of what programming is, they are only one piece of the puzzle.

Designing and planning

Before writing a single line of code, the design and architecture of a project is thoroughly planned to ensure or at least increase the likelihood of having a smooth development cycle. This is where software design comes into play. Toolchains, pipelines, layers of abstractions for public and internal APIs, modularization, object relationships, and database structuring are all planned out during this stage of development.

We are living, breathing debuggers

The art of programming requires us to think outside the box and solve problems with the most pragmatic, effective, and feasible solutions. This is probably why we are most likely the "I.T. guy" or "customer support" of the household. It is practically our job to fix what is broken. It is as if "programming" is a glorified way of saying "problem solving".

In other words, we are living, breathing debuggers on and off our computers, and because of this, it is important that we know how to read and write documentation. Proper documentation—which comes in the form of actual pages of detailed documentation, or as simple as sprinkling worthwhile comments to the code base—serves as one of the most important lifelines of a programmer. Without it, we are lost in the dark, unable to fulfill our very duties as debuggers. Little to no progress can be made because most of our time would be spent on experimenting and investigating how a framework or legacy code base works. Overall, it would result in a terribly awful developer experience.

Consider all possible scenarios

Debugging is already hard enough as it is. To make matters worse, the execution of code is usually not linear. Large projects entail multiple "branches" of possible execution paths due to program logic with the if statement. We have to account for every single possible scenario and error, especially if it involves user input. The cognitive load required to keep track of every possible execution path makes programming all the more difficult.

User Experience

Stepping outside the world of development, we fill in the shoes of an average user. In addition to providing functionality, adding new features, fixing bugs, and documenting our code base, we also focus on how an average user interacts with our app or software. We consider multiple factors that lead to great user experience such as (but not limited to) accessibility, usability, user-friendliness and -discoverability, UI design, color themes, functional animations, and performance.

Performance and Optimization

Speaking of which, performance is a huge facet of programming in itself. We, especially those with a background in computer science, strive to use and write the most time- and space-efficient algorithms. We obsess over the unfathomable time scale of microseconds in order to squeeze the most out of our available memory, CPUs, and GPUs.

In the context of web development, network optimization is an important concept to grasp. We jump through hoops to minify and compress our HTML, CSS, and JavaScript just to minimize the payload of a response from the server. Images and other miscellaneous resources are also compressed and lazy-loaded to minimize the amount of data the user has to download before a page becomes meaningful and usable.

However, there are times when we become too obsessed with performance. Premature optimization becomes a problem when we unnecessarily preoccupy ourselves with optimizing certain parts of a code base instead of focusing on what needs to be done for actual progress and productivity. In that case, we must have the wisdom to judge which parts of the code base really need optimization.

Security

Beyond the UI and logic of our software, as programmers, we are responsible for the security of our users. In our day and age where data is greatly coveted and heavily monetized, it is more important than ever to make sure that the personal information of our users are safe. We take extra steps in protecting private data because our users trust our software. If we do not uphold that responsibility, we are certainly not real programmers, not even by a longshot.

We can never be too safe when approaching security. As a general rule of thumb, we "never trust user input". It can even be considered a "best practice" to go to great lengths to sanitize data and user input. Not only do we put our software and infrastracture at great risk if we are not careful with them, we also run the risk of compromising sensitive user data—the very data we promise to protect as programmers.

Security is not exclusive to user data and input, though. Viruses, worms, Trojan horses, adware, key loggers, ransomware, and other forms of computer malware continue to spread and plague millions upon millions of computers and devices around the world. Even after decades of technological improvements in hardware and software, there is no such thing as an invulnerable system. Security is simply a craft that is continually being honed but will never be perfected for there will always be the inquisitive few who investigate and search for every possible way to "hack" a system.

For that reason, regardless of use case and user base, we design our software with security in mind as one of the top priorities if not the top priority. We do this to protect our users from the aforementioned threats that may cause inconveniences such as data loss, file corruption, and system crashes to name a few.

Teamwork makes the dream work

Even if it does not necessarily relate to programming, teamwork plays an extremely integral role in software development. With all the complexity and moving parts of any large project, it is impossible for only one person to develop quality software at the brisk pace of regular iteration or under the strict deadlines and time constraints of a client or any supervising entity.

This is why we have various teams of people who specialize in one of the many facets of programming. One person will never have all the skills and knowledge required to effectively and cohesively glue every facet together. One team may be responsible for UI design and accessibility while another may work on the functionality of the software itself. If all of the competencies of the various specialized teams are combined, the resulting software will have the best functionality, user experience, performance, and security it can possibly have within financial and practical constraints.

For time management and meeting deadlines, workflow organization and automation are of utmost importance. We take the time to properly configure our build tools and pipelines because doing so will save us a lot of time in the future. In general, the return on investment increases as time passes by.

Working well with others

To expound on the idea of teamwork and cooperation, we establish healthy relationships with our peers because in the end, the success of a project greatly depends on the success of the team behind it. We make it an effort to foster a supportive working environment, where experienced seniors thoughfully guide newcomers.

Since we develop software as a team, we have to be mindful of others reading our code. To keep the development cycle sustainable in the long-term, readability and maintainability are considered to be just as important as the logic and functionality of a project. We consistently write good, readable code while providing informative commit messages and documentation because these will definitely help us and others understand our code more.

Speaking of others reading our code, a code review is a great opportunity to learn more about best practices in programming. It is also another way of familiarizing ourselves with a code base and its underlying design and architecture. Although constructive criticism is unpleasant and difficult to handle on the receiving end, it is important to take it as sound advice in order for us to improve as programmers.

Programming is hard

Programming encompasses many aspects beyond functionality such as user experience, performance, security, and teamwork. It is not enough to strictly focus on one aspect alone while omitting the others. For projects of notable size and significance, it is not as simple as typing a few lines of code. It requires a lot of careful planning, designing, consideration, and team cooperation to be successful. In fact, more time is spent thinking than typing when programming, especially during long sessions of debugging.

In the end, programming is really about continuous, nonstop learning. Adaptability and constant learning are the keys to surviving this industry. We cannot expect to stay relevant if we do not do our part to keep learning. In such a volatile industry of exponential technological improvement, we have to keep up with its fast pace lest we end up in the dust.

I want to conclude this article by recognizing the hard work of all the developers around the world. To write this article, I had to reflect on the daily workflow of a team of developers. I had to look into the many aspects of programming and software development that usually go unnoticed. Since then, I have had a greater appreciation for all the software installed in my computer. To that end, I encourage everyone to thank a programmer today, regardless of experience. Where would we be without them?

Never take their hard work for granted.

Posted on by:

somedood profile

Basti Ortiz (Some Dood)

@somedood

Just some dood trying to make code work without bringing the Universe to its demise.

Discussion

markdown guide
 

I often use the analogy with writing a story. Learning to write code is easy, just like writing a story.
But programming/software development is more like write a good book. I'm not even talking about a Lord of the Rings, or War and Peace. Although that it quite often what others expect.

 

People nowadays constantly spew out the narrative that anyone can code and coding is easy, but the truth is it takes a truly fantastic mind to be a good programmer. Which is why it is such a demanding job and why so many people leave the profession or never enter it at all even if they have qualifications. I can tell you now that a Computer Science degree does not prepare you for the profession in the slightest...

I constantly have people asking me: 'How do I learn to code?' My answer is usually something along the lines of, 'You just start by doing it.'

When people ask me whether I think they should learn to code, I usually shrug and say, 'Do you really want to learn to code?' If they say yes, my response is usually, 'Then start programming.'

And finally, yes I know people are going to hate me for saying this, but saying programming is easy really undermines the accomplishment of all the wonderful pioneers of the industry that got us to where we are today. I just wanted to get that off my chest. No hate. (No, I don't think of myself as a good programmer, but I'm passionate and it's hard to match my drive and motivation.)

Good, now that that is out of the way. Fantastic article! Keep it up.

 
 

This comment made my day even better!

 

Thank you.Great writing. One of the reasons: no jargon.

 

I think that this is the most accurate and insightful article about programming that I've ever read. Thank you.

 

Thank you! That means so much to me.

 

Coding can't simply be categorized as "hard" or "easy"...

Coding (which is one component of the discipline known as software engineering), challenges us everyday; sometimes those challenges are hard and complex, sometimes easy and simple... but always doable.

We learn new lessons (and relearn old lessons) as we work thru those challenges; we learn how to avoid the new pitfalls that we just fell into; we learn new debugger features; we gain some new insight (that may or may not have been previously obvious); we begin to see more clearly how this slab of code really works (killing off any prior assumptions).

We apply known principles and our inginuity to produce the simplest and most elegant solution.

And, then we figure out how to test this; we also have determine how it wil impact the rest of the code/system. And, not only do we attempt to make this code piece better and stronger, but we give consideration to the next engineer by inserting just the right comment (no more, no less); and by writing a concise but easily understood git message; and by completing the review/pull request in the Jira ticket; and by explaining to the QA person how to get this code path to ececute so they can test it.

So, coding (SE) is not "hard"... it is "involved", same as any engineering discipline (consider what MechEng's do before they even start doing a bridge).

:)

 

This is a really great and thoughtful post. Thank you for this. This is super informative for all of those curious about what we do as programmers.

 

Dijkstra has written quite a few articles worth reading:

Two views of programming, by Edsger W. Dijkstra

In the world around us we encounter two radically different views of programming:

View A: Programming in essence is very easy.
View B: Programming is intrinsically very difficult.

Needless to say which view Dijkstra held.

 

Where's the business knowlege in your list ?
If you don't know what your target is all the other items in your list are useless 😬
Better get on board a ship w/o a compass and a sextant you would have better chances
to get to your destination...

 

Surely I couldn't write everything about what goes into programming without overbloating my article. And I believe that including business knowledge may seem too "meta" on the topic programming. In the article, the section on teamwork already seems "meta" enough due to it not exactly being "programming", per se. I didn't want to drag out the "meta"-ness, which is why I only primarily focused on the direct aspects of programming.

But besides that, thanks for adding something to my list! It always helps the knowledge base.

 

Understanding the business and how it will evolve is the hardest part to avoid
creating rigid systems.
Everything else that follows after this step is trivial.

You know what business pple complain the most about IT in general ?
That they don't understand the business and often propose solutions that suits
them but are short sighted business wise or absolutely inadequate 😬
Two lines don't 'bloat' an article...

True, but I feel like two lines don't do justice to the importance of the point you're raising.

Don't get me wrong, I completely agree with your perspective, but I think it's better if the business side of programming is discussed as a separate article of its own, and not just a skim-through in an article such as mine because, again, it wouldn't do justice to its significance in constructing an overall sustainable, future-proof business model.

What I really wanted to focus on in this article are the direct aspects of programming, not necessarily the business side of things. Programming is programming; running a business is another, which is why I feel the topic should have a whole article of its own.

Perhaps you can write an article about it? I am definitely not qualified enough to discuss such matters, and I would love to see how you could expound on it.

 

I really love the conclusion but programming is not hard: can be boring for some task or project but most of the time is exciting, fun and challenging. I am programming since the 80 and manage teams since the middle of 90 and on my experience on a team if some programmer found the task 'hard' my suggestion is that he change his job.

 

Yup, I agree with saying that programming is fun and challenging. I think that's the reason why I love it so much: it just challenges me to think and solve problems in creative (and sometimes unorthodox) ways.

However, I can't deny the fact that programming is indeed "hard". The amount of things we have to worry about every day is astonishing (as proven by the many facets of programming I mentioned).

From the outside looking in, programming is one of the most cryptic professions out there. To us, it may not be "hard", but it definitely is challenging (to the point that it is a difficult profession to be in if one can't handle the stress that comes with it).

 

The Hollywood depictions are certainly laughable, but I'm not sure that editor familiarity is a reasonable target to be included here. Sure, being familiar with one's tools is not directly about programming itself, but it does, in so many cases, have a positive correlation to being a capable and passionate programmer.

People who touch type fast and use Vim keybindings every day are far more likely to be people who are really interested in the craft of programming, so that they actually went out and spent their own spare time to learn the skills. Would you trust somebody who types very slowly with only two index fingers to be a great programmer? Very unlikely I'd say. The same goes for how you wouldn't trust a carpenter who has all his saws rusty.

This piece does a reasonable job in explaining programming to beginners but one might have gone a bit overboard here. I also remember reading from a prominent programmer that great (some say "10x") programmers for a language are great largely because they are so familiar with that language that they've internalized the API, libraries, documentation etc. Those factors are all very relevant to programmer efficiency.

 

I really enjoy the lecture, It is true that the challange in this field is very hard but the reward about it is very grateful, when you see you hard work published or running in a device etc. Many thanks for the article.

 

Great piece of work. Very insightful and valuable content which must be read by all programmers.

 

Thank you so much. In this article, I really just wanted to highlight how difficult this profession is, and how we shouldn't be taking developers for granted because of it. More often than not, people are unforgiving when they encounter a bug in an app or anything like that. In some instances, they unleash their full wrath. Though understandable, I feel that a developer is already going through a lot of stress in the workplace alone (as indicated by the many facets of programming he/she has to worry about). Sometimes, we do not give enough credit to developers, the unsung heroes of the modern world, which is why I wrote this article. I hope my message of understanding their struggles came across well.

 
 

Thanks for such stuff about programming. One piece missing in this article is the hustle and the difficulty one ought to go through to get hired. I mean the white board coding interview. Though one will not be using this stuff much in his/her daily work. Without passing this white board coding test, one will not be able to get hired. To pass this test, one must be competent in data structures and algorithms. This competence requires several hours of practice, practice and practice.

 

It really confuses me why front-end developers need to learn complex algorithms just to get hired. It is by far one of the greatest mysteries of life.

Regarding "a missing piece in this article", I didn't really want to jump into the rabbit hole of interviews because it would make my article longer than it should be. Furthermore, I only wanted to discuss what programmers do in their jobs, not before they get their jobs, because that's a whole new beast of a topic itself. If I had added interviews in my article, it would be so bloated and the main message—which are the facets of programming we have to worry about daily—would be lost.

 

Bravo! I really enjoy your style of writing, @Some-Dood.

 

I didn't really expect to be commended for my style of writing in this article. Well, that's a first. Thanks! 😀

 

Nice concise article, i thank programmers for their underappreciated contribution to our society. <3

 

Good overview! Virtually impossible to master it all, especially since it's always changing ...

 

You did a great job of capturing specifics and generalities. What specialized roles have you had? Which order should each of these things be taught to new devs?

 

I have never really been in a professional setting yet. I'm still doing my studies. The content of my article comes from experience and observations in the community if you're wondering.

And I think I could say that I have a specialized role in front-end and back-end web development, at least in my personal projects. No source of income as of yet since I'm learning the ropes, but I'll get there soon enough. 😁

For new developers, it's always best to work on your attitude first. It's hard to work with a stubborn person in a team. Once you're sure that you have a great attitude and an amazing willingness to cooperate with a team, I'd say they should learn the basics of a programming language first. Then, they apply their logic and newfound knowledge to create their own applications and algorithms. Once you have the hang around the workflow, it's time to organize and structure your app. For that, it's important to focus on readability, modularization, and maintainability. After that, I'd say they should learn how to read documentation next because that's a very important skill to have. Once achieving competence in the previous facets, I believe it's time to learn a bit about user experience and UI design. Finally, performance comes last because it's not really something a beginner should worry about for the time being. Performance and optimization are pretty advanced topics that require a substantial amount of knowledge about a programming language to be aware of all the tips, tricks, and hacks available to you.

So if I were to order each of these things, I'd say:

  1. Attitude and personality
  2. Logic and functionality
  3. Readability, modularization, and maintainability
  4. Learn how to read documentation
  5. User experience and basic UI design
  6. Performance and optimization
 
 

Thanks for the comprehensive article,programming is more than people of the outside field see it to be. I have to close my system for some hours to think well

 

lol to know someone put tracker on this page haha

 

We all start from there, my friend. I'm glad you pushed through!

 

This is Warming and encouraging. I feel more encouraged to carry-on even better. Thank you!