I got fired from my first job, took down a database server with a badly written query, and was rejected from a FAANG. That all happened over the past 10 years.
But I've learned a lesson or two about coding along the way:
1. Estimates are just guesses.
The problem is when your guesses don't overlap with everybody else's guesses.
2. Showing progress is better than doing the work.
Did you guess you can finish a task in 4 days? No, no, no.
You're better off splitting it into smaller ones to show progress.
3. Proofs of concept are better than long documents nobody will read.
When was the last time you read more than 2 or 3 pages of documentation?
You're better off creating a quick and dirty Pull Request to show an idea or a prototype. "Working code over documentation."
4. The work isn't over when you finish coding.
After coding comes deployment, testing, user adoption, customer support, and follow-up.
5. The more senior you become, the less it's about coding and the more about meetings.
Did you join Software Engineering because you like coding? Forget about that.
You'll spend more time in meetings:
- 1-on-1s,
- Daily meetings,
- Retrospectives,
- Sprint planning,
- Alignment meetings,
- Brainstorming sessions,
- Poker estimation sessions,
- A few minutes with a guy from another team who needs to touch the code you wrote one year ago and you don't remember now.
And on and on...
In a perfect day, you'll have 1 or 2 hours of coding without distractions.
6. You learn to love tests when you work with a legacy app.
Call it unit, integration, end to end, TDD, BDD, or anything DD.
You're better off with anything that lets you know when you break something before shipping your code.
7. Don't start a big major refactoring if nobody asks you to.
This is what I call Massive Unrequested Refactorings.
Either you refactor as part of your tasks (honoring your current estimates. See #1) or make it official as part of your sprint planning. There's no point in between.
8. Don't waste time on pointless discussions about tools or tech.
β "Entity Framework is the best."
β "No, it's painfully slow."
β "Nooo, stored procedures are the best"
Arrggg!
Tools are just tools.
That's why we, coders, have the reputation of being opinionated and grumpy.
And please, let's not talk about clean code and best practices. That's a subject I changed my mind about.
9. Always automate code style and best practices.
Don't ask a human to do the work of a machine.
Code style perfectly matches the type of work for machines.
10. Projects fail because of communication problems.
The same thing I've heard about marriages.
At a past job, I was engaged in 3- or 6-month projects.
We used the shiniest and brightest tools and frameworks.
But some projects ended up off the rails.
The only moving variable?
Our communication patterns:
Failing to communicate expectations, project goals and scope, action plans, and technical issues on time.
11. Every tech problem is a communication problem.
It's a corollary of #10.
At a past job, I was new to ASP.NET Core and when trying to test my code, I changed a connection string in a settings file and ended up deleting another environment database. Ooops!
I used the wrong settings file in the wrong environment.
I didn't ask, nobody told me, and there wasn't any restrictions or guards in the code.
It was a communication problem.
12. Solve the problem you have today.
Premature optimization or just being lazy, don't solve and optimize for a problem you don't have yet. Avoid writing just-in-case code.
If any of that resonates, check out StreetβSmart Coding, the roadmap with 30 practical lessons I wish I had starting out my coding journey.
Top comments (16)
... and the documentation you skipped in point 3 π A product needs documentation for someone who will use it and doesn't have all the context that you have.
This is also painfully true... that's why I tend to start looking for a new job when this happens. There's nothing wrong with sharing experience and teaching juniors, but when the work starts to be an endless loop of meetings, I simply lose interest.
Right!
Same around here. Just crossing my fingers waiting AI to kill meetings and Scrum
Hey,
Reading this felt like looking into a mirror β especially points #2, #4, and #12.
I've been building SHALA (Supportive Help Agent and Lifeline Assistant) and working on an LLM Security Audit tool, and honestly? The gap between "code works on my machine" and "code works for real users globally" is where most of the hard lessons live.
4 (The work isn't over when you finish coding) β yes. Deployment, monitoring, user trust, security follow-upsβ¦ that's 80% of the actual job.
And #12 (Solve the problem you have today) is something I constantly have to remind myself. With LLM security especially, it's tempting to over-engineer for threats that don't exist yet. But shipping something solid now > planning for every edge case.
10 and #11 about communication problems β couldn't agree more. The worst bugs I've seen weren't about bad logic. They were about assumptions nobody wrote down.
Anyway, appreciate you sharing this. It's a good reality check for anyone who thinks 10+ years means "easy mode." Would love to connect if you're open to chatting about building ambitious, global-scale products β lessons like these are gold for teams trying to move fast without breaking everything.
Cheers,
Jack
That's when the job starts :)
Totally agree! And thinking to Agile Principle... you reported many of them here... this experience is the one every senior coder face during their experience...
May be the one missing is: Simplicity--the art of maximizing the amount
of work not done--is essential.
The more code, the more problems :P
Great read. These hard truths really resonate. I especially agree with the emphasis on showing progress over perfect estimates, the importance of testing and deployment, and how communication often makes or breaks a project. As you said, senior roles bring more meetings, so protecting focused coding time and automating what machines can do are practical ways to stay effective. Thanks for sharing such honest, actionable lessons.
Very true. Unless nobody is going to use it. Apart from yourself, that is. ;-)
Good point! Well, in that case, we are our own end user and main dev team :)
love it. short and useful.
Thanks :)
So damn right!
Thanks! :P
Totally resonate. and especially #12, 100%
Glad to know I'm not alone with #12 :)
the visibility one is the hardest to internalize. shipped a clean refactor with zero communication, watched a messier feature with daily updates get more org credit. the work and the signal about the work are separate jobs.
Some comments may only be visible to logged-in visitors. Sign in to view all comments.