The growing maturity of the software industry over 30 years has resulted in an increasing number of success stories. Technology and tools are maturing to a point where typical business software projects have fewer and fewer technical reasons to fail. Enterprise frameworks, databases, communication tool-kits, platform abstraction layers and drivers for commodity hardware are rock solid. And yet, software projects are often delayed, over-budget, poorly built or all of the above. In worst-case scenarios, projects turn into such massive train wrecks that they are cancelled entirely, canned and brushed under the carpet like they never happened.
In many instances, poor management practices can be squarely blamed on a failed project. Impossible schedules, inferior equipment, inadequate manpower, or half-baked requirements are all major factors affecting failed projects. But what is often overlooked is a more insidious problem – poorly trained and unmotivated developers. Hiring people who have minimal interest in the craft makes them liabilities to the rest of the team that is striving to achieve quality work and can seriously jeopardize chances of project success.
For hiring decision makers, if quality of candidates comes above quantity (as it should be, unless you are being pressured to fill up some massive, VC-backed head-count void) evaluating their technical prowess is a must-do activity during the interview. While practical tests definitely should be on the list, I find reading and side projects to be very important positive signs to look out for.
Passionate developers are often voracious readers, especially on the topics of software, programming techniques, languages and technology. We are living in a world where information is literally at our fingertips. More matter is written and published than ever before. Many writers give away their work for free online. Heck, there are lists of recommended books and essays for new programmers who don’t even know where to begin. There is no reason at all for a person to not be able to read at least one substantial book every few months other than the lack of motivation.
Quality of material is important too. A half-baked, ‘syllabus-oriented’ book, read two days before final examinations does not count for anything. Passing a platform-specific certification program might indicate a programmer’s skill on that particular platform. But since most of them are promoted by vendors with a self-serving interest in increasing the popularity of their platform, it does not speak much about their ability to adapt to new technologies.
Personally, the structure of a published book sounds much more conducive for learning something new, especially since it has been evaluated and revised for structure and content by a bunch of editors. This is usually applicable only for in-depth understanding of large frameworks, however. I don’t think I could be bothered to read much more than a few paragraphs occasionally on novelty topics that don’t relate to my daily work, such as Arduino or low-level system programming. But everyone obviously has their own preferences and styles of learning.
Unfortunately, there are too many developers who simply seek to be part of the software industry for its perceived low barrier to entry and ease of massive success. For these kinds, no amount of coercion can cause them to pick up a book and plow through it unless its contents carry a critical mark on their annual appraisal. Tom Demarco’s statement from so many years ago still rings true –
“The average software developer, for example, doesn’t own a single book on the subject of his or her work, and hasn’t ever read one. That fact is horrifying for anyone concerned about the quality of work in the field, folks like us who write books, it is positively tragic.”