Six tips from the book 'Coders at work'.
I thought the book 'Coders at work' was so exciting, I must have read it in one go. Every chapter is interesting and many lessons can be learned from coding heroes. Here are six of my favourite tips from the book.
Programmers are optimistic
Douglas Crockfort said in the book that when programmers estimate their work, they are optimistic. They have to be, otherwise they cannot continue to do this work.
I guess what Crockfort is saying, is that although being too optimistic might be a bad trade during estimations, it is what keeps us programmers going even when our work can be very frustrating at times.
Second system syndrome
Jamie Zawinsky talked about how a second major version of the software might result in 'Taking small, elegant, successful systems and overengineer them into bloated systems'
Focus on the good subset
In each programming language: Focus on the good subset of the language.
I think this means that some languages can have some badly designed parts that you should try to not use.
But there are also new versions of modern languages that add stuff that really no-one was asking for. This might lead to writing cryptic code that people who come from a different language, do not understand at first sight. Everyone who has used resharper to turn readable code into complex LINQ-queries, knows what I'm talking about. Just because it is in the language, does not mean it is a good idea to use it.
Douglas Crockfort said that in each meeting someone reads their code and walks the rest through it. Crockfort says it is worth two weeks of QA and is a very effective way of removing errors.
Write good, AND readable code
Closely related to the 2 previous tips: Computers are not very smart so you have to make special efforts to make sure they get it. But you also have to make sure your computer program can communicate to another human being.
Computer science vs. programming.
Jamie Zawinsky said he picked up computer science over the years and that programming to make the machine do something was the goal. In this process, computer science was a means to an end.
I think this is good to realise: that different people have different backgrounds. Some need to understand the science before writing code, some program a system based on their creativity and experience.
When communicating in the team, it is important to understand the information needs of individual programmers.