Perhaps we were raised to look for a job to live on, to work at something that would help us make a living and pay the bills at the end of the month. Perhaps, I mean, our education didn’t place enough emphasis on always looking for work that we not only like, but feel passionate about. Whether we pursue that as an employee or an employer is another matter. What I want to stress here is that excellence and quality always emerge when we love what we do more intensely than the rest of our obligations.
There is no job where every task you have to do is always enjoyable. To reach a final goal—a project with results—we have to do many different things. We may like some more than others, but if, when we finish a project, move on to its next phase, or begin an entirely new one, we don’t feel some satisfaction, personal pride, or simple joy at having finished something with quality and done the best we could under the circumstances, then we’re not devoting our working lives to what we’re truly passionate about.
In software, this has an enormous impact, though we don’t always realize the disastrous consequences it can have for a project’s successful delivery.
Granted, some people can spend eight or more hours on an activity they don’t care about. That is a virtue in its own right, and one that’s necessary in countries where the financial crisis still has a major impact. However, those of us who see our careers as something to build, taking positive, progressive steps toward success—whatever each of us means by success—couldn’t work at something we truly feel no passion for.
You’ll never be good—a highly skilled professional—if you’ve chosen to do something that doesn’t fulfill you, that you don’t enjoy. It’s that simple, and that forceful.
Likewise, in a profession where excellence is so directly tied to the lives of the software products we build, this quality in developers matters more than in any other profession.
I like my profession, with all its many facets, and I like creating products that are hugely useful to end users. Sometimes a simple but elegant refactoring that improves the quality of the code I write in some way makes me feel very good.
I also feel good when it’s easy for me to spot a problem in a client’s installation where some of our products are deployed (we’ve made enough effort to ensure the software can be debugged); when we’re presented with a new need and see that it fits perfectly within the product’s integration capabilities; when a client praises how easy it is to use the user interface without consulting the manual (user-friendly interfaces); or when they also praise how something that used to take several hours can now be done with a click, saving their company money (value for the end customer)—and so on.
Achieving that takes countless hours of work, discipline, and perseverance in writing unit and integration tests, and continually refactoring code and designs with every new feature, class, library, and so on. None of that would be possible, of course, if you hadn’t become hooked on that magical moment when you tag a new release of your product or create a new branch, knowing that the version you’re wrapping up is well made, both in its functionality and in the internal quality of its code. If that’s what we call excellence, you can’t achieve it by spending eight or more hours a day at work just waiting for your paycheck at the end of the month.
One of those moments, which I call an epiphany, came when I put my first website online back in 2008 (well, I’m not exactly proud of that work now, but it was my first foray into web environments after years spent on highly scalable and optimized applications and back-end environments).
Someone who doesn’t fit with what they do, despite spending so many hours of their life doing it, isn’t going to strive to do the best work possible. When professional software developers finish a task, they should ask themselves: can I improve this in some way? Can I extract an abstraction from this to improve the solution’s design? Could I simplify it even further?
A developer can finish their work and leave it at that. A good developer asks some or all of these questions from time to time, or at particular moments. An excellent developer asks them continually.
As a team lead, one of my responsibilities is to build a team of people who feel at ease doing what they do, who genuinely enjoy most of the development tasks they work on, and, above all, who feel happy when something is completed to a magnificent standard of quality.
We can’t innovate in areas of work we don’t enjoy, just as we can’t be as productive as possible in jobs we hate.
The first time I read about this aspect of software development was in The Passionate Programmer, by Chad Fowler. It was one of the books I discovered years ago that convinced me programming was much more than writing lines of code.
We can only program well if we truly enjoy this demanding job and profession.
That’s exactly what Ken Robinson talks about in his TED talk, the celebrated talk and his book The Element: how passion for what we do changes everything:
https://www.ted.com/talks/ken_robinson_says_schools_kill_creativity