Coders At Work

Here's Leslie Johnson:

I read an interview with my former colleague Brian Kernighan in the must-read book Coders At Work where he pointed out that we spend more time debugging code than writing it. Then this (paraphrasing): If you push the limits of your understanding when you write code, when you start debugging you're already in over your head. Best to keep it simple. Besides, someone else, perhaps a junior programmer, is one day going to maintain that code. Best not to make it any more difficult than necessary.

Reading interviews with the world's top programmers is not just interesting, but essential for gaining insights on how they think, approach design, debug and other issues. There are lots of common threads in their answers. For example, understanding program problems by careful study of the code, not by using debuggers and profilers.

I thought I was the only programmer who debugs mostly by using a print statement here and there, but it turns out to be common with the best ones.

More common advice is to read other people's code - a lot - and try to understand it.

Previous Attempts at Program Design

Top Down Design

Software design and development is maturing, but still has a long way to go as a craft. Back in the early 80's "Top Down Design" was all the rage. Agile programmers later called this "One Big Design Up Front". The idea was that programmers should spend lots and lots of time thinking before writing any code, so the outcome would meet the requirements, and Viola! It would all be perfect on the first try. Except it didn't work.

The problem with Top Down Design is that you can't know all of the issues and problems that will come up until you actually start coding. In "Coders At Work", which interviewed the world's top programmers, the question was asked of each about their approach to a new design. The answer was universal: Think about the project to get a good top-level idea of what to accomplish, and then start writing low level pieces to get an understanding of what's going on. It's not Top Down, nor Bottom Up, but some of both. This has been my approach for a very long time.

Design Patterns

The next design fad was Design Patterns, from a book written by the (in)famous Gang of Four. This was at the peak of class-based object oriented programming, and they tried to come up with patterns to describe common programming idioms, like Iterators and Singletons. The problem is that the best programmers don't think that way. As one well-known programmer put it, Design Patterns are a good way of describing the deficiencies in your programming language.

Class-based Inheritance

It's pretty much agreed by everyone that Object Oriented programming is good, but though OO is usually associated with Classes it's not always true. OO languages like Go and JavaScript do fine without them without losing any functionality. (JavaScript classes are really syntactic sugar to make them look like something they're not.)

One problem with Class Inheritance is that it breaks encapsulation. Anyone who has worked on a C++ or Java project with lots of deeply nested inheritance knows how this causes problems. As the Design Patterns famously recommend: Prefer composition over inheritance. In other words, avoid class inheritance whenever possible. Best to take them out of the language as Go did.

No Silver Bullet

Contrary to fads that come and go, the book The Mythical Man Month is just as relevant today as when it was written back in 1974. Author Frederick Brooks mentions "no silver bullet" addressing software development problems, and he's still right. He describes software managers as thinking nine women can make a baby in a month, and why poring more bodies on an overdue project is a bad idea.

Functional Programming

Functional programming is becoming more popular for good reason. It's not new, having been described back in 1977 by John Backus, the author of FORTRAN. It's based on solid math developed in the 1920s and 1930s by Haskell Curry, Alonzo Church and others. It's not just a different programming style, but a whole new way of thinking about programs. Haskell is probably the best example, and worth looking into if only to understand what it's all about.

Knowledge, Experience and Lessons Learned

I've been along the sometimes bumpy road of software design for a long time, and I hope to have learned some lessons that I can apply to projects such as yours. If you agree, let me know. Perhaps together we can make good things happen for you.