Thorsten Ball - Professional Programming: The First 10 Years

Tags

Top Highlights

• 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.

• Using other people’s code is not as good as I thought I started my career writing Ruby and JavaScript, with package managers being available and the question “isn’t there a package that does that?” always hanging in the air. Common sense dictated: if you can, try to use a library instead of writing it yourself. Reuse code as much as you can. Don’t reinvent the wheel. Don’t copy & paste. That was what I believed for years. But there are downsides to that. Sometimes writing that one function yourself might actually be better than adding a dependency. Dependencies aren’t free. You have to keep them up to date. They increase your compile or loading times. They add strange things to your stack traces. And very often they do more than what you need them to do, which means you’re paying for more than you’re getting. When you’re glueing other people’s code together, there’s a very real danger that the glue is where complexity will accumulate. But glue code is the last place where you want your complexity to live. It hides complexity. What you want is to make complexity as visible as you can, shining a light on it with the hope that it turns into dust and disappears. Sometimes it’s better to write it yourself than to use other people’s code.

• 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.