After developing software for small and large teams, I’ve learned lessons I wish I knew starting out. I wrote a similar, generalized article more than a year ago, so check it out if you aren’t a programmer.
If you haven’t already, realize coding is the easy part of the job—especially with AI. It’s the planning, teamwork, and politics that gets you.
Work with legacy code. So, you want to make an impact and get recognized? Start getting with the existing program, not your new one. If you aren’t on a team dedicated to refactoring or migrating legacy code, don’t try replacing it; every time you do, you’ll likely waste time and ship nothing.
Cut yourself some slack. Stop saying “I’ll get [it] done tomorrow,” and start saying “I’ll have [it] done in a few days with an update tomorrow.” Even if you know [it]’s an easy thing to do. Best case, you’ll finish ahead of schedule because you underpromised and overdelivered.
Maintain relationships. Promotions don’t come from good work alone; they come from people vouching for you. Be helpful, and you will be helped. Maintain your network in case you need help finding a job.
Everything you build is temporary. Don’t satisfy yourself with “perfection”, only please others with “enough.” Your code isn’t your baby, it’s something people will look at in a decade and wonder why it’s still used.
Don’t be Batman. It's not cool to work in the shadows. Work publicly. Everyone should point to you as an expert in your field because of your advertisement of your work.
More small things > one big thing. Do small things. Ship small features, review small PRs, read short developer articles, write short blog posts, install smaller packages, write short emails, etc. rinse and repeat. As my friend Grug once said: “Small things mean more speed, more speed make big money, and big money means pat on back.”
Question everything. When your stuck, ask your mentor for help. If you don’t understand a design decision, question the decision, and then question why it wasn’t documented. The more you know, the better you’ll be.
But not everything. Pick your battles. There are people with more power than you, and it's in your interest not to piss those people off. Among those people are systems that you shouldn’t poke if you wanna make rent.
Certify your knowledge. Do you think you know something? Great! Confirm it by shipping code or presenting that thing. You don’t know shit unless everyone else knows you know it.
(S)cope with your work. Scoping is coping with the idea that everything sucks. Do your job, not more, not less. If you wanna do more, make it part of the scope of your work.
Don’t spike blind. For tickets you need to plan (called Spikes), don’t make assumptions. Test those assumptions, explore, and break shit then write down your findings.
Follow YAGNI. Abstract only when necessary. Start with simple solutions, until you need complex ones.
Make debugging easier. I’m not a functional programming messiah, only a guy who’s learned the pitfalls of using global variables and too many side effects. You should understand the data flow of most parts of your program.
Don’t work on the weekends. Focus your effort on workdays only. Your life is more important than any work you do. Unless you’re on call or something.
Inspiration
“Advice to the Young.” n.d. Advice to the Young. Accessed September 27, 2025. https://muratbuffalo.blogspot.com/2024/07/advice-to-young.html.
“How I Build Software Quickly.” 2025. July 8. https://evanhahn.com/how-i-build-software-quickly/.
“Lessons Learned in 35 Years of Making Software.” 2024. Jim Grey on Software Management, July 3. https://dev.jimgrey.net/2024/07/03/lessons-learned-in-35-years-of-making-software/.