Passionate Programming versus Caring Programming
Passionate Programming versus Caring Programming
Join the DZone community and get the full member experience.Join For Free
How do you break a Monolith into Microservices at Scale? This ebook shows strategies and techniques for building scalable and resilient microservices.
Oren Eini (aka Ayende @ Rahien) replies to a job seeker who doesn’t have any source code outside of work:
Put simply, we are looking for a .NET developer and one of the most important things that we look for is passion. In general, we have found that people that care and are interested in what they are doing tend to do other stuff rather than just their work assignments.
In other words, they have their own pet projects, it can be a personal site, a project for a friend, or just some code written to get familiar with some technology.
When you tell me that your only projects outside of work are 5+ years old, that is a bad indication for us.
While I think there is a strong correlation between programming skill and having pet projects, it has less to do with passion than other objective measures, such as:
- A programmer with a toy project will spend several hours extra doing programming. Even 1 hour per day is over 9 weeks extra programming experience every year. Over time, that adds up.
- The time spent is usually entire programming as opposed to meetings, documentation, fielding calls, etc. Also likely fewer interruptions and more time to think through the design than a deadline-driven work environment.
- Such a programmer has a greater opportunity for challenging programming tasks compared to work, where if you belong in a team, things get divided up.
- There is more scope for experimenting with third party software tools, especially open source that are sometimes not allowed in companies because of the legal implications. Sometimes the tool of choice of a software firm may be outdated in the market, but they are still using it because of the investment.
The number of hours spent is the key measure. Or perhaps number of hours per toy project. If a programmer has several toy projects, each taking a few hours, they haven’t learnt as much as someone who has spent weeks on a single project, because they wouldn’t have been able to explore different dimensions of programming such as performance, security, etc.
But let us go back to hiring. Oren is a little misguided when he cites passion as the necessary criterion for hiring. A programmer may have a lot of passion for programming in general, but could have little passion for a specific project or for working in a specific language or tool set. Sometimes, he or she may be more passionate and involved in the pet project than in the day job. For an employee to care about the project is just as much in the hands of the employer as it is in those of the employee. The employer has to make the work rewarding and challenging, as well as provide a good working environment.
Actually it is not even “passion” because what Oren is interested in is “caring for doing the appropriate thing“. But passion and caring are two different things, even though sometimes they are both manifested in the same person. Passion is about solving problems and it is short-term. Caring is about ensuring good health (of the project) and it is long-term. A passionate programmer can be great for solving challenging technical issues. But the solutions of a caring programmer are more thought through and will be less brittle. Passion implies enthusiasm; caring implies thoughtfulness. This may seem quibbling between two words, but there are real-world consequences.
For example, a caring programmer may decide *not* to take on a technical problem, even though it seems exciting, because the implications for the product in the long-term can be negative. It is possible to come up with an elegant solution that sometimes minimizes the impact of a programming addition, but the effects on future program analysis and design can be huge. This is not to choose between either style of programmer. You need the passionate type because you want some team members ready to jump on solving challenges (even if they seem frightening). You also need thinking developers who can understand the long-term vision of the product.
Reading Oren’s post, I am not sure if he is looking for one of those types or somebody who embodies both attributes. But if it is the caring type, he really should look for senior programmers who have a track history of working with projects over several releases to different customers. Such a developer would have lived through mistakes of wrongly selected or implemented features, and understood what customers look for. The life of a software product is such that it spends most of its time in maintenance and the caring programmer makes that time easier.
Opinions expressed by DZone contributors are their own.