For those with 10+ years in software engineering: what problems do you still deal with that juniors usually don’t see coming?
Posted by BizAlly@reddit | learnprogramming | View on Reddit | 5 comments
I’m not talking about coding itself, but the stuff that actually gets frustrating after years in the field team issues, changing tech, burnout, bad architecture decisions, management pressure, etc. curious what gets harder with experience rather than easier.
vopice@reddit
One thing that still keeps biting even after 10+ years is how often “stable” things turn out not to be stable at all.
A common pattern is: to deliver some niche business requirement quickly, the team cuts through an abstraction, bypasses architecture rules, hardcodes assumptions, or tightly couples components because “this case is unique” and “it will never change.” And for a while, it works.
Then 2 years later the business model changes, another customer needs something similar-but-different, regulations shift, or the company reorganizes. Suddenly that “temporary shortcut” became part of the core system, and realigning everything is painfully expensive.
Juniors often think the hard part is writing the code. In reality, the hard part is preserving the ability to change the system without causing a chain reaction across the entire architecture.
The older I get, the more I value flexibility, clean boundaries, and resisting “just this once” decisions - because almost nothing stays static in software.
Longjumping-Sweet818@reddit
I truly believe that all the devs who keep saying things like "dont use too many abstractions until you need them, they just complicate everything and are a waste of time" are the kinds of devs who just get a ticket, implement it and then move on to the next ticket, oblivious to the fact that their mountains of first-order code are costing the company and the team months of work to maintain. I also think they just simply don't understand what the point of abstractions are and how they should work.
Immediate_Form7831@reddit
The more senior you get, the more you realize the software engineering has very little to do with coding, and has much more to do with communication, managing expectations, understanding requirements, architecture, etc.
ElegantPoet3386@reddit
I think this is a bit general, but my friends dad who works at google for 10+ years says the one thing in his opinion he did not expect to have to learn for programming is learning how to communicate.
Considering the stereotype for coders is a sweaty dude working in a basement typing on a keyboard, this seems nonsensical. But, according to my friends dad, you have to be able to communicate the results of your work to people who think you aren’t doing shit. You have to be able to communicate to your co workers who for some reason doesn’t know how to use documentation even though they have 5+ years of experience. You have to be able to communicate to others about what and why youre coding so they can help you.
This is mostly my friends dad’s words btw. I don’t know squat about the real world of programming, I just code whatever my minds interested in at the moment. I’m curious if other programmers think if what he said sounds right though.
Western_Aardvark7505@reddit
Not in software but been managing properties for decade now and see similar patterns. The technical stuff becomes second nature but dealing with unrealistic deadlines from owners who don't understand how long things actually take never gets easier. Plus you start seeing same architectural mistakes repeated everywhere because nobody wants to spend time doing it right first time - they just want quick fixes that become your headache later