Write tests that give you confidence that the system works as it should Don’t worry too much about whether a test is an integration or an end-to-end test, a unit test or a functional test. Don’t fight with others about whether you should test private methods or not. Stop worrying about whether you should hit the database in tests or not. Instead write tests that tell you the system is working the way it should. Ideally with 3 keystrokes and in less than 1 second. This one took me a long time, a lot of ultimately useless discussions, and bugs in my code to learn.
Best practices are often based on the assumption that you know what the code should do If you know exactly what you want to build then best practices and patterns can help you, by giving advice on how to build it. But if you don’t know yet what the program should do, or what it will look like in four weeks, then some best practices can make things even harder. Some practices are the best when applied to a rewrite, but the worst when you’re still exploring.
Work on a codebase with other people over a longer period of time Nothing has helped me get better at software engineering as much as working with a group of other people on the same codebase over multiple years. You’ll see how decisions play out. You’ll see what ended up mattering and what didn’t. You’ll see how extensible your code truly is when your colleague tries to modify it 3 years after you wrote it. You’ll see whether your prediction of “we have 2 of these now, but I’m sure there’ll be 5 in the future” will come true or not and can take the outcome into account when doing other predictions. You’ll regret writing some code and you’ll be happy that you wrote some other code. You’ll learn from reflecting on the difference between the two. You’ll see tooling break down just because something somewhere changed and you had nothing to do with it but you still have to fix it. You’ll say “I’ve never had to think about this in 3 years” about some pieces of software and cherish them. You’ll see what parts of the codebase new colleagues struggle to understand and which parts they immediately get productive in. You’ll see what the code you wrote looks like 4 years later.
Knowing the full stack There’s few things as motivating to me as hearing “you don’t really need to know how it works…” Sure, I might not need to, but I wouldn’t do the work I do today if I hadn’t tried to find out how a GC works, or how Unix works, or how multi-threading works, or how a database stores data, or how interpreters and compilers work. It benefits the work I do, too. I can make better technical decisions by being able to weigh trade-offs more accurately, knowing what goes on under the hood.
Not every code review is worth the effort Not every code needs a really thorough review. Sometimes, if the risk is acceptable, it’s fine to drop a quick “LGTM!”. It unblocks your colleagues, keeps momentum and, somehow, builds trust.
Glasp is a social web highlighter that people can highlight and organize quotes and thoughts from the web, and access other like-minded people’s learning.