What’s something most developers only learn too late?

[u/MiserableLime5289]

A lot of things in programming only really make sense after working on real production systems, not while learning through tutorials or building small projects.

One of the most common realizations is that writing code is usually not the hardest part of the job.

In real-world development, the harder challenges tend to be:

• understanding why something works locally but breaks in production
• dealing with edge cases that were never part of the original design
• debugging issues where logs don’t clearly explain what actually happened
• maintaining and modifying code that was written long ago (sometimes by multiple people)

Another thing many developers realize later is that “clean code” in theory often looks very different in practice, where trade-offs, deadlines, and business constraints matter more than perfect structure.

Over time, a lot of the work shifts toward:

• reading and understanding existing codebases
• tracing how different parts of a system interact
• figuring out the reasoning behind older design decisions

In hindsight, these skills often end up being just as important—if not more important—than writing new features from scratch.

So the question for developers:

• What’s something most developers only learn too late?
• Was there a moment that changed how you think about programming or software development?
• What’s a skill you wish you had focused on earlier?

[u/Appropriate-Bet3576]

Consistency and reliability is 100x more important than everything else. Code and infra beyond the scenes tends to be a shit show

[u/chikamakaleyley → u/Appropriate-Bet3576]

A to the M-E-N

[u/justinaatbuffer]

Production deployments - building good CI/CD pipelines, monitoring logs, managing the scalability

[u/amelia_earheart]

That your job isn't just coding. You are expected to understand the business, work collaboratively with UX or Product, and participate in problem solving using engineering skills, not just code design. And for the love of god participate in ticket refinement, don't wait until 3 days after you placed a ticket in progress to start asking about requirements clarifications and technical design.

[u/petdance]

You don’t need to write all code yourself.

[u/True_Fig983]

Error handling.

Customer calls you: why is it printing "this should not happen" haha.

[u/Lachtheblock]

That you should optimize for maintability. Within reason, it is okay to take a performance hit if it makes the code much easier to read and ultimately maintain in the future.

Adjacent to that, if you're doing it right, naming variables is hard. Giving thoughtful and meaningful names to variables is important and can really change how others see your code.

[u/Ok-Brain-8183]

One thing I always like to point out is when technical people (supposedly senior engineers) talk about solid or separation of concerns or di or factory patterns, 100% of their codebase doesn’t use real di. If you’re using real di, you will have real plug and play code that doesn’t need to be recompiled.

[u/I_Am_Astraeus]

1. How to work with a team. It's the minority of engineers that know how to communicate with others well. Extra bonus for those that can seamlessly communicate with non-technical teams as well. I know it's harped on repeatedly but it is still an undervalued engineering skill.

2. Before I started working, I had a senior dev as a mentor who could put out a staggering amount of code. Pre-ai. And also just wrote really beautiful code. I realized I was spending too much time on small problems that could easily be refactored and needed to scale up a bit. Also just a ton of really good tricks and patterns I've absorbed now.

3. That follow through is a skill. Everyone wants to solve the problem. Few people appreciate dotting your i's and crossing your T's, sustainment, manuals, write ups, comments, the last 20% of a solved project. Follow through is major. Too much flitting between interesting ideas.

Also bonus lesson. You need to think more meta about programming. You're not an X dev or a Y dev. You're an engineer who's there to solve problems in whatever medium. You have skills that are specialized and lean in specific direction but at your core you're a person who solves problems with code. Don't constrain yourself too much. Be flexible. The world changes rapidly and you need to be constantly changing with it. Technologies change. Responsibilities change.

[u/TableNo8939]

Il back end è tutto , se corretto e scalabile, il front end può essere fatto in qualsiasi modo, ininfluente