What does passion mean for a Software Engineer? Depends on the context. First, and that’s what start-up companies usually expect from their employes, it means you love the company, the business idea and the team you work with. Some people are also passionate about their Apple computer/phone/tablet in a similar way (the term “Fanboy” is frequently used in Web forums to describe this behavior). *
Second, it can mean that you stay ahead of the curve and have strong opinions about how to do your job (independent from the company you’re currently working for): For example, I’m obsessed with clean code and unit tests. When I’m using a component library and come across a class that does not work for my project (too slow, too many bugs, too complex or does too many things at once,…), I insist on looking for an alternative from another library or even write my own code to replace it. When I see the need for a refactoring, I will do it. Although this is a certain effort and not the “easy way”, I am more than happy to do it because it is better than producing a mess in the long run. It’s not good enough to have a halfway working solution and collect technical debt, just because you are too lazy, somebody insists on using the “standard library” or says “there is no time for refactoring”. It’s also not good enough to omit unit tests because “the class can not be tested”. Passionate developers commonly contribute to one or more open-source projects.
So, in the first case, the concept of passion is used by others to either convince you to put a lot of energy & time in a low paying job at a start-up company or to increase Apple’s revenue. Either way, you tend to give more than you normally would. While this can be fun and create a shared identity it is also unprofessional, because it makes you blind for other opinions or criticism. Note that I’m not saying you must be professional at all times.
In the second case, you have the passion to do whatever you are convinced leads to desirable work results. This can surely be seen as arrogant behavior when you try to enforce something within a system that not everyone agrees with. On the other hand, your opinion is usually based on solid professional experience and it would be strange to make the same mistake twice just to avoid a discussion and conflicts. The Challenger explosion is an interesting, although extreme example. Let me quote a few lines from the preface of The Clean Coder:
“Certainly the engineers did what they were supposed to do. They informed their managers and fought hard for their position. They went through the appropriate channels and invoked all the right protocols. They did what they could, within the system—and still the managers overrode them. So it would seem that the engineers can walk away without blame.
But sometimes I wonder whether any of those engineers lay awake at night, haunted by that image of Christa McAuliffe’s mother, and wishing they’d called Dan Rather.”