Tag: learning

In my previous post, I elaborated on the importance of reading for software developers. Keeping up with new advances in technology demands that its users have a healthy appetite for the written word. However, reading is just part of the equation for engineers. Knowledge gleaned through books offers no benefit unless it can be applied efficiently in their daily work. And quality programming, like every other art form, requires continuous practice.

A person who is uninterested in programming beyond its ability to help bring in a monthly paycheck, would typically not want to spend any more time than absolutely necessary in performing this activity. I don’t always hold side projects very high up in the evaluation matrix, but it is a pretty good indicator about the candidate’s interest in programming beyond the mundane stuff. After all, most programmers only get paid to write business software. If they want to write their own stack implementation that already ships as part of their framework, their employers will not be pleased to have them attempting to roll their own. Not only will it be a very inefficient use of time, but hand-rolled implementations are going to be nowhere as performant and bug-free as the libraries that ship with mass-consumed frameworks.

However, side projects do not come under strong timeline or performance pressures, nor are there constraints about the runtime environment or language choices. Who is to object if an individual feels inspired enough to write a stack in Brainfuck?

Educators have long since accepted the importance of learning by doing, especially for scientific topics. There is only so much one can absorb about the stack data structure by reading about it. At some point, one must put down the book and let the rubber meet the road, so to speak. Side projects in languages or frameworks other than what is used at work is a great way to learn new stuff. And it is a natural progression to reading about something new. Writing one’s own implementation of the Towers of Hanoi game cements whatever knowledge the book provides about the data structure. And depending upon the type of project we are talking about, individuals can easily play their best card. Those who are visually-gifted or otherwise have access to a collection of high quality graphics, a finely polished interactive utility or game can make a great impression. Those with a less-than-perfect eye for graphic design, a programming API with accompanying documentation can make an equally compelling case for their skills.

Again, there are many avenues for programmers who want ideas on programming projects. All that is required is the will and tenacity (not to mention the skill itself to begin with) to come up with a project idea and take it through to completion.

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.”