Coders at Work – a book review

So here I finished this work. While being sometimes entertaining, sometimes delivering useful thoughts and sometimes being boring ass stories I found it overall… decent. Just as the last book –  by Robert Glass –  this one falls a little bit after it.

As for now I want to give you a more scientifig approach on rating book if it please you – an idea I grabbed from one of other book’s publisher. I will rate the usefullness of the ideas. How will I perform such a task? Well, clearly subjective, but nevertheless I will try to mark every interesting idea, then divide the amount of pages by the number of interesting ideas. An ideal book may reach far beyond 100% by having multiple impressive text passages… but this percentage rate appears rather imaginary. I guess some values above 20% will indicate a lecture worth your time and thus, reading.

The most appealing thoughs and ideas I will quote directly so you can make a clear picture rather to believe and agree with my view or not. Let’s start with “Coders at Work”.

Short opinion

As with Fallacies by Robert Glass this book comes a bit… outdated. Yes, one should never judge by youth and appear but only by inner values, however reading every chapter (as the author asks almost same questions) about PDP-10, DECsystem-10, IBM 1130 and so on and so forth

Calculating the worth

I started to mark worthy ideas by page number 280. Given the total amount of pages to be 525 it makes 245 pages difference. I counted 13 useful text passages. This leads to 0,0531 or about 5.3%. It may not seem to be very much, thus, leading to a bad overall rate, on the other side, in turn, I liked the thoughts that much, you could easily double the value if you find them impressive too. Since 13 is a good number and not a big one, following you can find all of the parts at once.

Job interviews – seeing the spark

Important on job interviews – it’s not nessesary a good sign if a person can solve logical puzzles. It just shows that they can solve logical puzzles. What is however more important – how attendants deal with technical problems. How do they think? How do they work with someone? Did they do their homework – are the basics on an acceptable level? Can they say “To solve this problem, I need A, B and C. This is how I would use those approaches together (explains it). Maybe I should look up about part C more, but I’m sure this leads us towards a right solution”. Until now you should get a rough idea about the interviewer as a technical specialist. And of course you should ask him or her to write down code on a peace of paper or blackboard. They should know their ABC without Googleing it every time. Additionally they should be – of course – able to work in a team.

Ask people about what they’ve done, what they’re mostly proud about. If they truly went through hell and back for a project they will be passionate about telling you such a story. Let them take the wheel, be initiative. The most important part here is not only letting them tell you what they’ve done, but although how.

If interviewers can’t tell you anything they’re interested in (it has not to be only about professional treats) they probably won’t show any performance in your project either.


The ability to think stepwise makes us more adaptable to the outer world. And you don’t need any programming skills for that. There is a difference between – “Oh, our cabinet door won’t close. Let’s take a look – here, a screw is missing” and “Door won’t close. Let’s call someone!”.

Project leading

A good project leader should know the goal – if you are self-confident about what you’re doing it will fall easier for others to accept you and to follow you. This self-confidence widens out to the whole team, whole project which leads to a complete win-win situation for everybody. However be alarmed not to take too much care of everything as it may drive away the motivation – why put any effort in this if it’s all clear anyway – just sit back, relax the reigns in such case.

To put it short – know what you’re doing, don’t interfere, but be technically educated so you can give adequate feedback.

In chapter 14 I encountered again same thoughts. Additionally there was this one – project revisions. Each team member has had to present their part of work. And the goal was to get the part where the declarator wasn’t sure about. Sure, it sounds like an examination at the university, but the clever trick behind it – get company’s best minds to review your work. This is turbo mode help.


The bigger your programs are, the more you need to care about interfaces. How will this connecting link between those two program parts look like? What’s the input? What’s the output? Which part of the task should be solved by which part of the program?


Proper documentation should be regarded as the same kind of art as programming itself. Most of the time it’s either too sparse or too filled with unnecessary details. Bringing together right amount of information and in right form takes a lot of time and invested time should be considered same as for writing code.

Good code, bad code

Thrifty definition of good code – if you need to add some functionality, you do it in just one place, while bad code leads you to changing dozens of places.

A bit about talent

In the middle aged reading and writing were regarding as special talents granted only to the chosen. In the beginning of the 20th century same could be said about art – creating films, writing books, making music was a prerogative for selected people. This is why learning about informational technology is important for everyone – like reading and writing earlier. Computers just extend our creational possibilities, enabling more and more people concentrate on what they really like to do.


Don’t be too clever. Sounds harsh? Do not spend weeks or months to increase some algorithm efficiency if this algorithm will only trigger once in a while in your program. You may even do worse by trying your best, since your program will become more and more difficult.