Originally posted by A Flatoff:
From looking into the table of contents of the book I can guess that you are targeting IT Project Managers for your market.
Would I, as a busy programmer spending lots of time learning new technologies, benefit more from reading this book - or would I be better off studying more about the programming languages and tools I use?
Hi guys. Sorry the late entry. Looks like a busy
thread already!
The target audience of the book? We tried to put in information that could be used by developers ~and~ tech leads (or project managers). I've worked in both roles and we tried to pick out useful practices for both roles.
For instance, we talk about doing very small code reviews. Instead of large, formal code review, we suggest that you get your code reviewed in smaller chunks, several times a day. This helps to cross-train, share information, catch bugs, etc.
As a tech lead, you can make these mini-code reviews mandatory. However, as a developer on a team that doesn't code reviews, you can grab a buddy and still do your own code reviews. You will personally benefit from using this practice even if your team doesn't formally adopt them.
We tried to point out these types of dual use practices where ever we could. So the audience is both developers, testers and tech leads.
As to whether
you should take the time to learn the sorts of things in the book... What's the fastest way to chop down a tree? Do you start chopping and keep chopping until the tree falls down or do you stop and sharpen your axe first?
In our experience, investing the time to set up tools like source code management, Continuous Integration, etc will pay you back very quickly.
Quite often we encounter certain pains for so long that we think they are simply part of doing our jobs. In reality, a lot of the pain in software development is not necessary. For instance,
Integration Hell. Many people think that merging your code to the team's baseline has to be difficult. It's all they've ever seen. Put those same people in a shop using a
Continuous Integration system and they can't believe what they are seeing. It takes a while before they actually believe that everything is working right. For the first few weeks, they keep waiting for the CI system to blow up.
You ought to see these same people around release time when the code is being covered by automated tests. They are used to seeing everyone panic.
Does that answer your question?