There seems to be an established truth in programming that code reviews find a lot of bugs. An example is chapter 18 (Modern Code Review) in the book Making Software. This is however not my experience – I rarely find outright bugs when reviewing changes. But I still think code reviews are useful. Below are my thoughts on the value of code reviews, and how to make the process efficient.
I really liked A Philosophy of Software Design by John Ousterhout. It is compact and short, only 170 pages, so it is a quick read, but it contains many good ideas. The focus is on how to structure systems to make them easy to understand and work with. The author is a professor of Computer Science at Stanford, but he has also spent 14 years developing commercial software.
Microservices have gone through a complete hype cycle. From being hailed as the one true way to build systems, to a backlash where they are often considered too difficult and complex. In a way though, they are like most technology – there are trade-offs. You get some benefits and some drawbacks. Here are four features specific to microservices that I have come to appreciate.
For the past few months, I have been interviewing with several companies. In all cases, one or more coding tests were included. I have also been on the interviewing side, evaluating a coding test. Here are my thoughts on the process.
Here are more good programming quotes I have found since my last post.
“It has been said that the great scientific disciplines are examples of giants standing on the shoulders of other giants. It has also been said that the software industry is an example of midgets standing on the toes of other midgets.”
Alan Cooper
“Changing random stuff until your program works is bad coding practice, but if you do it fast enough it’s Machine Learning.”
via @manisha72617183
You have developed a new feature. The code has been reviewed, and all the tests pass. You have just deployed this new feature to production. So on to the next task, right? Wrong. Most of the time, you should check that the feature behaves as expected in production. For a simple feature it may be enough to just try it out. But many features are not easily testable. They may be just one part of a complex flow of actions. Or they deal with external data fed into the system.
In such cases, checking if the feature is working means looking at the logs. Yet another reason for checking the logs is that the feature may be working fine most of the time, but given unanticipated data, it fails. Usually when I deploy something new to production, I follow up by looking at the logs. Often I find surprising behavior or unexpected data.
To check if a program is doing what it should, you can inspect the output from a given input. But as the system grows, you also need logging to help you understand what is happening. Good log messages are crucial when troubleshooting problems. However, many developers don’t log enough information in the right places.
In the fall of 1999 I got the biggest productivity boost of my entire career as a software developer. In the October issue of IEEE Computer magazine, there was an article by Kent Beck called “Embracing change with extreme programming”. In it, he outlined Extreme Programming (XP), which includes much of what we now refer to as agile development.
By then, I had been working as a software developer for seven years. The standard development methodology at that time was waterfall: document-heavy year-long projects, frozen requirements, change control boards, manual testing at the end of the project, and so on. Software development succeeded despite the methodology, not because of it. Reading the article was a real eye-opener. I felt it was describing how I naturally worked – in short cycles, with fast feedback, and frequent redesigns.
(And yes, I meant to write this last fall for the 20th anniversary, but I didn’t get around to it then. But hey, better late than never, even if the title has 20.5 in it now)
I really like Secure by Design. The key idea is that there is a big overlap between secure code and good software design. Code that is strict, clear and focused will be easier to reason about, and will have fewer bugs. This in turn makes it less vulnerable to attacks. This is easy to say, but Secure by Design is full of techniques for how to actually do this. Here are the ideas from the book that I liked the most.
Henrik Warne's blog 
On Comments in Code
I used to think that I didn’t need comments if I wrote self-documenting code. However, I have realized that I do write comments, and that I find them really useful. To see how many comments I write, and what kind they are, I wrote a script to analyze my git commits from the last six years. In total, seven percent of my committed lines contained a comment. This blog post has details on what constitutes good and bad comments, as well as more statistics from my script.
Continue reading →
10 Comments
Posted in Programming
Tagged comments