Sr Technical Writer passionate about information architecture, docs-as-code, and making complex information easier to comprehend. I write about technical documentation, UX, and mental health in tech.
After coding comes deployment, testing, user adoption, customer support, and follow-up.
... 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.
The more senior you become, the less it's about coding and the more about meetings.
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.
Sometimes I code, always I write — A simple man making his way through the galaxy, writing as I go — 📚 Author of "Street-Smart Coding in the Age of AI": bit.ly/csarag-sscai
Location
Colombia 🇨🇴 (not Columbia)
Work
Content, Courses & Training for .NET teams — Helping teams to write maintainable & performant code
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.
Sometimes I code, always I write — A simple man making his way through the galaxy, writing as I go — 📚 Author of "Street-Smart Coding in the Age of AI": bit.ly/csarag-sscai
Location
Colombia 🇨🇴 (not Columbia)
Work
Content, Courses & Training for .NET teams — Helping teams to write maintainable & performant code
the commit message and PR description are the code’s advocates — most engineers just leave them at ‘fix stuff’. the silent refactor probably had a one-liner too. narration is the missing step, not visibility luck.
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.
Sometimes I code, always I write — A simple man making his way through the galaxy, writing as I go — 📚 Author of "Street-Smart Coding in the Age of AI": bit.ly/csarag-sscai
Location
Colombia 🇨🇴 (not Columbia)
Work
Content, Courses & Training for .NET teams — Helping teams to write maintainable & performant code
Freelance fullstack developer creating fast, modern, and refined applications. I focus on simplicity, performance, and real value for users. I also write tech-related articles here.
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.
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.
Sometimes I code, always I write — A simple man making his way through the galaxy, writing as I go — 📚 Author of "Street-Smart Coding in the Age of AI": bit.ly/csarag-sscai
Location
Colombia 🇨🇴 (not Columbia)
Work
Content, Courses & Training for .NET teams — Helping teams to write maintainable & performant code
Agentic Front-End & AI Architect | 15+ years of craft. Bridging sovereign AI systems and premium reactive web architectures. 🇨🇦 Building the future of local-first agentic interfaces.
Sometimes I code, always I write — A simple man making his way through the galaxy, writing as I go — 📚 Author of "Street-Smart Coding in the Age of AI": bit.ly/csarag-sscai
Location
Colombia 🇨🇴 (not Columbia)
Work
Content, Courses & Training for .NET teams — Helping teams to write maintainable & performant code
I'm a high school student who loves coding. I'v been coding since i was 9 and have several awards on the national level. Trying to survive college entrance exams and code to at the same time.
Sometimes I code, always I write — A simple man making his way through the galaxy, writing as I go — 📚 Author of "Street-Smart Coding in the Age of AI": bit.ly/csarag-sscai
Location
Colombia 🇨🇴 (not Columbia)
Work
Content, Courses & Training for .NET teams — Helping teams to write maintainable & performant code
Sometimes I code, always I write — A simple man making his way through the galaxy, writing as I go — 📚 Author of "Street-Smart Coding in the Age of AI": bit.ly/csarag-sscai
Location
Colombia 🇨🇴 (not Columbia)
Work
Content, Courses & Training for .NET teams — Helping teams to write maintainable & performant code
Sometimes I code, always I write — A simple man making his way through the galaxy, writing as I go — 📚 Author of "Street-Smart Coding in the Age of AI": bit.ly/csarag-sscai
Location
Colombia 🇨🇴 (not Columbia)
Work
Content, Courses & Training for .NET teams — Helping teams to write maintainable & performant code
Welcome to Unified Mentor: Your Pathway to Lifelong Excellence!
We're here to guide you on an incredible journey of skill growth and career advancement. Our mission is simple yet powerful: to enhance
... 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
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.
Exaclty! And code by itself won't advocate for us.
the commit message and PR description are the code’s advocates — most engineers just leave them at ‘fix stuff’. the silent refactor probably had a one-liner too. narration is the missing step, not visibility luck.
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 :)
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.
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
So damn right!
Thanks! :P
Good.
love it. short and useful.
Thanks :)
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 :)
Totally resonate. and especially #12, 100%
Glad to know I'm not alone with #12 :)
Great work!