The joy of reading

As it stands I have now worked my way through the pragmatic programmer and peopleware and am at various positions in a number of other books.

I believe neither of these books can be justified by a single reading and I'm realistically going to need to refer to them frequently.

DRY(don't repeat yourself) and orthogonal design, two of the principles of the pragmatic programmer are interestingly enough two significant changes that were coming in about in my coding before reading the book, though I wasn't entirely aware of them. I think a major factor in this was simply reading more of other peoples source, especially from getting involved in open source projects(at the moment I am lightly involved in the HBase project: unfortunately mostly asking questions, but I have made a minor contribution and hope to make more in the future as time affords).

There is a vast richness of other great principles in the book, but these two put to paper affected me most. Code I just knew was not going to be easy to maintain in the future came to mind immediately. If I don't fix it now, I will take a lot more time to fix it later(or even worse someone else will have to because I didn't). The temptation to take a piece of code that does A and copy paste it editing some bits so it can do B can be massive. But later down the line, you'll come back to it, edit A, forget B, C and D, and wonder just what went wrong.


Peopleware: It's really just brilliant. I don't know where to start. I'm quite frankly just not interested in working in management. Maybe in an ideal company it would be interesting. As is, I work primarily as a programmer and my semi-official secondary task is that of team "captain", whatever that may be. Ultimately there are things that need to be done, and if no-one else is going to do them... Well fine. I won't like it, but it's better than no-one doing it.

It's clear the job a of a great manager is really tough. A poor manager can think they're doing a great "job" by bullying people into ridiculous schedules and cutting costs by reducing working space. Peopleware points the inherent flaws in such practices.

For starters, cutting costs on development environments. In a world where maybe 5% of a developers salary will get them a poor work environment and mediocre productivity, investing double that for a quieter environment where work gets done can pay huge dividends. The studies quoted in Peopleware note 2.6* productivity gain in the top quartile as opposed to the bottom. Differences in salary are less than 10% on average, with high salary workers in both quartiles. The big differences lie in sense of privacy, feeling that a working environment is too loud, and simply not having enough space.

Schedules. I don't do much overtime as a matter of personal policy. I have no concerns of productivity due to it. I think I'm getting just as much done, if not more(at least when not interrupted by a constant flow of meetings and requests for this and that). My only concern is the effect on my team. I make significant effort to try and get my team members to just go home, but often find them having worked a couple of hours after I left. Peopleware would have us believe that the cost of this is undertime, and my experience of that is that it's generally accurate.

Another significant problem I have noted with overtime is that people focus entirely on the problem at hand but don't take the time improve their processes because they are working too much overtime.

Now the following is my own crazy idea with little of the actual evidence that peopleware has plenty of:
Even if overtime actually does give a net increase in work done (lets say you can work 10 hours at 90% instead of 8 hours at 100%), there is time wasted there. While Bob doing overtime is staying late to impress managers or some such nonsense, Steve could well be studying to improve his own methods. In fact a really good workplace would probably supply Steve and Bob this time. Anyway, assuming Steve has the spare time and does it as a result, he will be constantly improving, gradually improving his efficiency and speed. Bob will meanwhile be working in the same way as before and eventually Steve's 100% is the equivalent of Bobs 120% and he is flat out plain more productive despite working less.

Are all developers like Steve? Probably not. But the best ones love programming and do work on self-improvement. They are not people any organisation serious about software would want working for them. Denying those that would improve themselves by putting them through overtime through the use of idiotic schedules not only reduces their opinion of their employer, it also increases indifference, loss of enthusiasm and the likelihood of turnover.