Tuesday, June 15, 2010

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.

Monday, June 7, 2010

Change of plan

Been busy with other books since the arrival of an amazon shipment. Busier than I was with sicp alone.

I originally set deadlines to discipline myself, but have found that it's resulted in negative behavior such as:
* Not taking the time to look into concepts I don't fully pick up on
* Going for sometimes sub-par solutions to exercises.
* An inefficient study pattern.

So I'm not going to do them any more(nor have I been for the last week or so).

Sicp is still on the menu, but with a big pile of other books to go through it may take a while.

Here's what I got. I'll do some write-ups as I finish reading them.

* Land the tech job you love. I finished this one already. Great advice for interviewing and writing a cv, As well as pitfalls to avoid. I'll be putting together a new resume soon based on its advice and posting that up.

* The pragmatic programmer. Only just got started on this one, but so far it's brilliant. Many of the concepts I have been doing... Halfheartedly. I have been applying DRY("don't repeat yourself") to most of my work, but when deadlines come close or I just want to finish something up... Out comes the copy and paste. In the end it's never worth it. Formalising these ideas in my head is sure to be a great help.

* Code complete: next in line after the pragmatic programmer. I should have read this one years ago.

* Facts and fallacies of software engineering. Good train reading as each fact is pretty snappy and to the point. However the fact that half his references are coming from himself is a matter of some concern. 25% added complexity adding 100% workload is a concept that I have experienced time and time again, and having it stated clearly really helps to be more aware of it.

* How to win friends and influence people. This one's courtesy of Joel Spolsky's reading list. I'm pretty much a geek and so I often get frustrated with non-programmers and their inability to understand what seem like simple things. This attitude is counter-productive though so I'm working on improving it. As cheesy as this book may seem, it gives some very practical advice that should be obvious but isn't.

* Rapid development. Another frequently recommended McConnell tome. I look forward to getting to this too though for now it lies in my shelf awaiting its turn.

* Head first design patterns. Another one waiting its turn.

* Out of the Crisis Next in line for more "businessy" stuff after I get done with Drucker.

More are in the mail as we speak, including peopleware.

Refinding the joy of reading has been great so far, but there is a lot of material I've waited for too long to get around to. This should be interesting.