Over my time reading about and being a Software Engineer, I’ve gathered a small collection of
tips and learnings that I thought would be nice to record in writing for future me, or others.
This list is a living document, so I may come back to update it from time to time as I learn
more. Also, each bullet in this list is in no particular order and is purposely concise;
each bullet could (and may in the future) be its own blog post, but this list is supposed to
stay as snappy as possible.
The list:
- Without actionable insights (aka metrics), no timely strategic decisions can be made
- Don’t optimize too early; YAGNI
- Move fast when you need (for business survival reasons, generally), address tech debt when you can
- CI/CD lets you move fast with confidence
- Good (or any) code architecture may not be necessary early on for small teams, but will become increasingly important as the team grows
- Consider ease of deployment when designing a code architecture
- The flexibility of your code is more important than the functionality of your code (flexible code with bugs in it can be changed)
- Code duplication is ok if the use cases of the duplicated code may diverge; only unify duplicated code if it would always change at the same time anyway
- Code architecture should try to be agnostic; put off making decisions until you know what your needs are (this also incurs greater code flexibility)
Edit 9/14/22
- Monitoring lets you know about code stability after release
- A little operational excellence can go long way for team agility
- Follow semantic versioning (at least mostly)! It will help you/clients avoid dependency hell
- Version pinning (for deps and/or network end-points) helps prevent breaking changes (including to previously released versions, in the case of end-point version pinning)
- Use the Humble Object pattern to improve testability + flexibility
- Tests that are strongly coupled to implementation (i.e. testing UI string values) are rigid, fragile and basically worthless; they can only tell you that your code has changed
- Design your systems for testability
- As much as possible, don’t depend on volatile code
- When building something: 1) Make it work. 2) Make it right (refactor for flex/readability). 3) Make it fast (only as much as needed though).
- Manage up, don’t manage down
- If you wish there was documentation for something on your team, make it yourself while you figure out the information you needed
- Communication! Yes, this is just as important for devs as it is for anyone else.
- Don’t say “yes” to everything (you have a limit, you will reach it), say “yes, but…”. Explain the trade-off you will have to make if you accept extra tasks
- Keep on the same page after meetings by sending an email with the agreed action items (doubles as receipts against managers re-writing history)
- Code is a liability; opt for Taco Bell programming!
Edit 4/12/23
- The art of software engineering isn’t the coding, it is asking enough questions to know what the actual problem to be solved is.
Edit 12/6/24
- Don’t silo your teams; trusting and empowering everyone to do anything in the system will make everyone faster and happier. Cooperation > Parallelization. Egoless Engineering
Edit 12/30/24
- Be friendly. Software development is a team sport; if no one wants to work with you, it doesn’t matter how big your brain is.
- Human connections (either a personal network or via recruiters) are a much more efficient way of landing a job than using online application portals (at least today). With increasing amounts of AI generated applications, even qualified applicants can be buried or filtered out.
Edit 1/14/25
- “A complex system that works is invariably found to have evolved from a simple system that worked. The inverse proposition also appears to be true: a complex system designed from scratch never works and cannot be made to work. You have to start over, beginning with a simple system.” - Gall’s Law. Which I find reminiscent of the concept of a Steel Thread.
Edit 6/24/25
- Focus on building a small set of really good features than a moutain of features for every possible use-case. Every feature you add costs to maintain, makes your product harder to use (via complexity), and introduces more opportunity for failure. Only build more features if they will 10x your core value or double your revenue.