Google: How to do a code review

Google is sharing “How to do a code review” as part of its engineering practices. Unlike many similar guides online, I find this document to be a lot more comprehensive. It covers both the technical bits of the process, as well as suggestions that improve overall team communications and efficiency.

A particular type of complexity is over-engineering, where developers have made the code more generic than it needs to be, or added functionality that isn’t presently needed by the system. Reviewers should be especially vigilant about over-engineering. Encourage developers to solve the problem they know needs to be solved now, not the problem that the developer speculates mightneed to be solved in the future. The future problem should be solved once it arrives and you can see its actual shape and requirements in the physical universe.

Notes to Myself on Software Engineering

I came across these “Notes to Myself on Software Engineering“, with which I agree wholeheartedly. Some of these I’ve learned “the hard way”. For most of these, I wish I knew them earlier. They would make my life a lot easier. Here a few to get you started, but make sure to read the whole list, as many of these apply to other areas of IT and life in general.

It’s okay to say no — just because someone asks for a feature doesn’t mean you should do it. Every feature has a cost that goes beyond the initial implementation: maintenance cost, documentation cost, and cognitive cost for your users. Always ask: Should we really do this? Often, the answer is simply no.

Invest in continuous integration and aim for full unit test coverage. Make sure you are in an environment where you can code with confidence; if that isn’t the case, start by focusing on building the right infrastructure.

Simple things should be simple, complex things should be possible. Don’t increase the cognitive load of common use cases for the sake of niche use cases, even minimally.

Because code is communication, naming matters — whether naming a project or a variable. Names reflect how you think about a problem. Avoid overly generic names (x, variable, parameter), avoid OverlyLongAndSpecificNamingPatterns, avoid terms that can create unnecessary friction (master, slave), and make sure you are consistent in your naming choices. Naming consistency means both internal naming consistency (don’t call “dim” what is called “axis” in other places) and consistency with established conventions for the problem domain. Before settling on a name, make sure to look up existing names used by domain experts (or other APIs).

Career progress is not how many people you manage, it is how much of an impact you make: the differential between a world with and without your work.

Software development is teamwork; it is about relationships as much as it is about technical ability. Be a good teammate. As you go on your way, stay in touch with people.

When we find ourselves in a conflict, it’s a good idea to pause to acknowledge our shared values and our shared goals, and remind ourselves that we are, almost certainly, on the same side.

Searching DynamoDB: An indexer sidecar for Elasticsearch

One thing that I like about the modern world is that large technology companies are a lot more open than they were in the previous century. Many of them contribute to the Open Source ecosystem and frequently share their wisdom on how to use and not to use a particular technology.

Have a look at the recent post from Bitbucket blog: Searching DynamoDB: An indexer sidecar for Elasticsearch, for example.

It’s not your usual marketing nonsense about introducing a new needless service or self-praising review of a product. It’s a rather deep dive into a technical topic that has been getting a lot of attention for the last few years – NoSQL databases. Not only the blog post itself is interesting, but it provides plenty of useful links to other resources. Like this one, which covers database partitioning in depth. Or this one, which lists some of the best practices for designing and using partition keys effectively.

I wish more companies shared their technical insights like this.

Logging best practices

Logging, I think, is one of the least debated subjects in the software development. Everyone does it at least to some degree. Everyone agrees that good logs are important. But beyond that, there’s enough debate on what are the best practices, tools, and options. We need more of blog posts like this one and slides like these.