Over time, developers realize that what cripples their progress tends to be code dependencies. For example, a class that works fine, but not only does it need its parent classes, it may not be portable to other environments, and may also use many data types specific to a particular library, framework, OS, etc. Large chunks of nice code become unreusable (or at least, not without major effort).

What's even more frustrating is that for frameworks and OSes, the vendors want it this way. There are people who are consciously trying hard to lock one's code into their system.

The same way that it's easier to destroy than create, it's easier to make code that's dependent than independent. It's possible to break free, but it takes a lot of work that really has nothing to do with the problem at hand. Developers want to be abstract purists but they're always dragged kicking and screaming into specific and conflicting API environments.

Corner/edge cases. These are less-common runtime situations which, if left unhandled, will cause problems ranging from missing behavior to incorrect behavior to crashing. They're usually unforseen and when discovered, suck the joy out of coding. Because of time pressure, a developer who can change his overall approach or hack a kludge will opt for the kludge, increasing tech debt. Sometimes additional corner cases will crop up, or a kludge will itself create a new case. One could argue that a key difference between junior and senior developers is the number of corner cases they experience, as seniors understand the ramifications of their designs better. Some cases are rare enough to slip into shipped product, and then users find them and the bad reviews demoralize the developers. Cases make code ugly because one winds up with all sorts of if-else conditional logic instead of elegant linear algorithms/codepaths.

Imperfections of hardware. Programmers would like to just code without worrying about things like cache misses, heap fragmentation, branch misprediction stalls, memory alignment, threads, etc. Some of that stuff can chew up enormous coding time that again has nothing to do with the problem at hand, and in the end what was once clean, simple beautiful code is now a long complex rewrite that defies comprehension.

Opposition of elegance to performance. A well-understood OOP system, e.g. can add overhead that is notably slower than if it were coded in a more procedural manner (e.g. switch statements instead of virtual methods). Programmers would like to have clean, elegant, highly readable and maintainable code that requires no further optimization.

Refactoring too late. This happens when some tech debt piles up enough to motivate the developer to refactor the code, only to realize that no additional changes/additions will benefit from said refactoring. Cue the angst of "If only I had refactored earlier."

One of the most frustrating things about being a coder is spending hours upon hours trying to debug a single line of code. You might think you've finally found the problem, only to realize that it's actually something completely different. It's like a never-ending game of "whack-a-mole."

Another frustrating thing is when you spend weeks or even months working on a project, only to have it scrapped or completely changed by the client or management. It can feel like all that effort and hard work was for nothing.

And let's not forget about dealing with legacy code. It's like trying to decipher ancient hieroglyphics. You might spend hours trying to figure out what the code does, only to realize that it's doing something completely irrelevant or unnecessary.

But hey, at least we have Stack Overflow, right? And nothing beats that feeling of finally getting your code to work after hours of frustration. It's like winning the lottery, except instead of cash, you get the satisfaction of a job well done.

Update:

I recommend reading the book "The Pragmatic Programmer: From Journeyman to Master" by Andrew Hunt and David Thomas. This book provides practical advice on how to become a better programmer and overcome common challenges in the field. It covers topics such as debugging, refactoring, and working with legacy code.

As an added bonus, the book is available for free on Audible with a trial membership. So, if you're an audiobook fan, you can give it a listen and see if it helps you with your coding frustrations.

Don't forget to leave an upvote if you found this answer helpful!

For me it is understanding exactly what existing code does and why it is there.

Literally, I am reading code saying “what were they thinking here?”

Because I need to know.

I can’t begin writing my code until I understand how it fits into the existing systems.

Does my code need to co-operate with existing components? Does it require changes to existing code? If so what, and where?

Will existing tests need to change either what they test, or how they test?

Will my code break an assumption relied on by old code?

Will it change a schema or protocol depended on by existing code?

And all of this is made much, much harder by low quality source code. Unpicking that stuff is horrendously taxing.

Lots of effort to sometimes end up saying ‘I see. After all that, we fetch the latest list of adverts, only there is a bug where that will not happen if the last advert was placed on Thursday which is the cut-off print date and nobody actually has done that yet.”

But that might be thousands of lines of unstructured code, all with horrendous names, no conventions at all, no tests, and of course a custom implementation of some lame sort routine where the coder did not think to just call .sort()

That kind of work regularly makes me consider doing other work.

When I had my kitchen refitted, the old one was just ripped out. I was envious of being able to “just build a kitchen”. I thought how much simpler my life would be if I could do that.

Sadly it isn’t, as you need to replace all the existing functions of a five year old crufty codebase.

And it doesn’t take long for software to go past its sell-by date; about five years of active development in my experience.

Just long enough for the new team to not understand what the initial team were trying to do and the constraints they were under.

So - that. Crufty old code I must understand.

Well, unless you actually is nothing but a coder, I would say that the most frustrating part, is to be called a “coder”. I make software for a living, but I do so much more, than simply coding. Here is a (non-exhausting) list, of things you do in an average project:

• Collect user stories
• Talk to stake-holders
• Make a project time schedule
• Design a solution
• Find the appropriate technologies
• Establish the infrastructure
• Manage security and compliance requirements
• etc.

(Notice that I still haven’t gotten to the coding part)

So back to your question. It is frustrating, when people think, that all I do, is writing code. I do so much more than that. And quite often, the most difficult task, isn’t the coding part.

As a programmer, you learn a lot of interesting things and clever approaches. You may meet talented seniors or architects and learn from them. You'll develop a feeling how good software would look like, exchange with your peers, grow wise.

Then you come into another team.

You can't pick up where you left. Something is always in the way. The team, or the architect, or a manager will have a diametral opinion on “correct” software development. If that doesn't help the new framework or language will contain a restriction that just not lets you do it. Or they are with you but there's a half-finished system already.

If you're a functional duct tape guy, everything will be bloated OO. If you're an OO girl, everything will be static. If you learned to paint the Mona Lisa, you'll be required to paint white walls, if you're a minimalist, meet Mr. Monolith, if you're a designer, the other team will do that for you, and they won't talk to you. If you're used to reusable components, now it's copy paste, if you're a top down worker, you'll now work inside out.

Then you go through the five phases and adapt. You learn, exchange, appreciate and grow.

At that point the company will be sold or go bankrupt or hit by lightning or eaten by The Great Old Ones.

And you can start over.

Not necessarily in any order (except for the first item):

• Office Politics
• Time wasting meetings
• Meetings that interrupt my work flow or mind set
• Management who are clueless and egotistic
• Inadequate machinery (especially the provisioning of under-powered laptops, inadequate screen real estate and poor network services)
• Noise (especially chatter)
• Building a product I know is completely pointless and doomed to failure (aka anything at Intel but especially Digital Home and Media Stack Software)
• Travel time
• People who think programming is low stress or easy or is a 9-to-5 type of job

I really enjoyed contract work because I can let the stupidity wash over me without dragging me down. But when I work for an actual company I can’t help caring about the success of the company. Which routinely puts me at odds with ‘management’.

Allow me to use a bathroom shower analogy. A shower in the past had just a single knob. You turn it on and water will flow out of it. Then in cold places, where there was a need to have hot water come in and mix with cold water, two knobs came in. One to let hot water out and the other one for the normal water.

Over time, they added an additional wire with a faucet to have a hand shower. And then the same shower had a fourth connection to a regular tap. There are luxury ones that have various knobs and levers to let water jets massage your body at various speeds.

Thankfully the shower did not get more complicated than that.

Now imagine a CPU and memory which are like a million transistors or knobs to turn off and on. As a programmer you are exactly doing that, albeit not all the million transistors all at once, but a large number sometimes tens of thousands of them with your code.

The fact that you don’t realize it at the level of a high level language does not take away the complexity of what you are doing.

When you do complex things, they don’t get along so easily to produce the desired outcome. It takes a long time for you to tweak things until you see what you want. So real world programming is not for the faint hearted.

Software engineering looks easy on the outside when you begin to learn to program and get successful at simple ones. As you build complex code that does difficult things, you need enormous patience, perseverance to be at it and see it through.

Therefore for those who do not understand this and try to get into this field for quick money or success will soon find it very frustrating.

If you find any part of software engineering frustrating, pick a different career. (I couldn’t retire from it until I was 70, because I was having too much fun.) Sure there were bugs that were absolutely maddening, but the satisfaction of solving them was probably (I can’t say “definitely”, I’ve never tried it) better than a crack high. (I still remember one Friday in 1978. I arrived at work around 8 AM. I finally left work around 4 AM Saturday. We just couldn’t figure out how to get a “who talks first” situation resolved. [No Ethernet in those days - that would have made it simple.] When we finally got it working solidly every try, there were 4 foot wide grins all around. Then we went home. [I don’t remember if we even turned everything off - we just wanted to get out of there.] I believe the system is still in operation.)

There is nothing difficult being a programmer, it is a continuous evolving and training process of a lifetime. The more you are experienced, the better you can solve a challenging problem. It is amazing, if you seek to love challenges and solve puzzles with beautiful lines of code.

These may be few list of challenges I have seen developers facing.

1. Workload : Can be managed with proper time management and decipline, you dont have to stick around in office for long hours. The peaceful and creative part of the brain solves the task and not your physical labor. Decipline in life, proper excersise, meditation and yoga can higly imporove your productivity, efficency and quality of work. Keep health as a top priority, maintain proper diet and excersise.
2. Workpressure : Most developers work away from home, and that is a big problem because, there is no way to vent out the frustruation. Build a good social network of friends and family. Sharing your thoughts with your close knits can reduce a lot of your frustruations.
3. Never Stop Learning : Technology is evolving day by day and the day you stop learning, you are out of market. Keep track of changes in the technology, be an active participant in the discussion forums and programming conferences. Keep learning new technologies. Teach others if possible.
4. Never spent everything you earned: Layoffs happens quite often when ever a technology gets outdated or out of demand in the market. Be prepared always for storm, though it may never come, but when it comes, it could be just another day in life.
5. Plan your Career for at least 10 - 15 years: Its very important to set your life goal and career goal, and plan ahead to reach those goals. If your current job is not helping you out to reach there, it is a wise decision to move to a better one.
6. Maintain a professional network : Once you are out of college and start working, Industry is your university, connect with professionals and mentors in your industry. Interact and gain insights and knowledge.

Good Luck!

Frustration.

Few people realise the ungodly amounts of frustration that go into programming, particularly in the early stages. Some people believe that’s why, until it became a mainstream job, new programmers were usually already to frustration.

What is the hardest part about being a computer programmer?

Being allowed to concentrate.

Getting the people around you to understand that every interruption, even “I just wanted you to know”, destroys the picture in your head of what the program is and does. Without that picture, you cannot alter or add to the program.

It takes me at least half an hour to create that understanding of the program. Your interruption destroys it and wipes everything I have built in my head. I have to go back to the beginning. You interrupt me twice in a morning, and I have lost half the day.

My frustration at being unable to make progress builds up till I am ready to throttle the next person that speaks to me.

Just FUCK OFF.

When you have everything laid out (the old “plan your work so you can work your plan”) for everything and your boss says: “I need this done ASAP”.

That’s right. From my point of view, the most difficult part is dealing with a boss who is unwilling to recognize and prioritize your work. You can prioritize all you want, but the boss trumps all of that. If you have a boss that just looks at the end result and not the person they are managing, you’re in trouble.

Now, the reality is that all managers need people to do unexpected work and sometimes things happen where something needs to be expedited. I realize that it happens. But a good manager manages and if the workload is too high, goes through the process to manage it.

Your job is to manage your manager as well as doing the actual work.

That’s the “deal.” You make them look good and they allow you to do your job. When they don’t protect the employees from outside influences, you won’t be able to do your job and will burn out.

I had one manager in 35+ years who didn’t do it… it was the last one who caused me to retire (probably about a year early).

Continually learning and applying new technologies.

Evaluating new technologies in light of the existing technology base.

Planning to migrate to new technologies when the old one is terminated.

Writing applications which are easy to debug once they are moved to a production environment (code instrumentation).

Aligning the needs of the client with the technology in the timeframe required.

Changing Requirements from Clients and the environment.

All of those (important) things are less important than the manager / employee relationship.

What is the hardest part about being a computer programmer?

I’ve enjoyed reading some of the other answers.

For my part, the hardest part is explaining to management just how much work its going to take to finish, and that it is IMPOSSIBLE to predict exactly how much time something will take, so that they can know how much it will cost.

Most budgets for software are set by an organisations accountant.

“We can spend this much to do that”

Then they get some poor contractor to agree to the price, for a vague statement of requirements, and start paying in installments.

What the programmer really needs to start is a complete discovery and analysis of current business operations, but no, the first thing to “they” ask for is “An input screen we can show the Managing Director to prove that things are progressing”

Then the game of “variations” comes into play. The Customer says “Oh, we got that wrong in the contract”

The programmer says “Oooh, that's going to be expensive”, and ratchets up the price to cover the fact that they didnt do all the business design first.

So all contracts end up 5 times the budgeted cost, 4 times the planned time, and everyone walks away upset and frustrated.

THAT'S the hardest bit of being a programmer.

Q: What is the most difficult part about being a programmer? Why?

Thx for the A2A.

IMHO, the following tasks are example that belong to the most difficult part of being a programmer:

• Fully understand the needs and how they expressed as requirements/user stories so that you can define the problem and prioritize properly as well as have a meaningful dialogue with stakeholders. Why, well, a lot of shelfware is developed in the world, see, for example, The hidden cost of wasted software budgets,
• When critical details in complex frameworks work against you to implement trivial functionality. In particular, the JavaScript eco system is an endless source of meaningless conflicts where functionality can work well for all elements but for some weird reason not for another. See Thou Shalt Not Depend on Me
• Estimating resource requirements, risks etc. For example, Barriers to Refactoring is critical, one major issue that we lack tools to estimate consequences of refactoring. Refactoring is typically necessary to reuse solutions or prepare for future changes.
• Designing for quality which is always a trade-off between dependability attributes, security, productivity, reusability, flexibility etc. in such a way that you make full use of the eco systems and handle interaction with legacy systems.

Complexity,

Programming involves a huge number of bits and pieces, each of which are individually quite easy, or sometimes very easy. People who have just learned programming are sometimes surprised how easy the better programming languages are, and wonder what the fuss is all about.

The fuss is because all the easy stuff was done decades ago. What programmers do is solve complex problems involving, for example, the equipment that can fail, but must not be allowed to corrupt the results, working with networks (including the internet) which are unreliable, and take time for information to propagate, working with laws designed for humans not computers, working in an environment where criminals are trying to read and corrupt your systems, working with forty years work of other software engineers , some of whom were not competent, many of whom had different goals and world models from you.

No particular bit of programing is hard. What is hard is keeping all the different bits in your brain at a time. Which is why we keep trying to produce new languages, frameworks, libraries and so on to simplify them. Unfortunately, most simplifications lose information, so there is a kickback by complexity to preserve this information. There is a constant struggle between simple, elegant, easy to use systems, and the real world.

I believe this has been answered before, better, and more eloquently- but I’ll take a stab at it.

My annoyances (as are many of those of my peers) are grounded in the expectations and demands of the business people.

They seem to think that because one problem was solved in a project-cycle, all of them can be. Later, one that would tax a commune of Einsteins working in concert is considered a black mark against you (alone) when it goes beyond the allotted window by several days.

If THEY (you know — THEM) sense that the timeline is slipping, they will foolishly ask if you need more people on it.

This never helps, because you then have to split your time between the problem and bringing the other person(s) up to speed, making your effort even less effective — and at the same time making your helpful colleagues even less successful in their own endeavors.

The managers do expect you to push back if you anticipate difficulties during planning, but they typically expect you to see all the way to the deepest nuances of the problem within the few hours between the morning planning session and the afternoon retrospective. These problems have typically never been solved before, and frequently are the sort previously considered unsolvable.

The other annoyance-in-chief is a project lead on another team (a former CS major) who invented a framework we use.

It is quite clever, but tricky to maintain to the degree that doing so consumes the bulk of our time. This person naturally has a proprietary interest in it, and reserves the right to inspect our code before approving it for a build. Being a busy sort of person this can take weeks, which plays merry hob with our schedules.

Those are the only scenarios that I find annoying in my current situation, but I will vouch for the authenticity of those cited by others earlier.