Passion or Professionalism?
Warning, rambling statement ahead. The points offered in this post are goals. In no way am I trying to imply that I possess these qualities, or that I’m somehow not guilty of violating these principles. I am a work in progress. These are my goals, too.
Passionate about Programming?
I’ve been seeing a lot of job posts looking for someone who was “passionate about programming.” The candidates for these posts should be able to show an ongoing habit and history of open-source contributions, a deep and impressive Github profile, and would be a leader on a significant open-source project. If the candidate couldn’t show this, then that person probably wasn’t “passionate enough about programming” to succeed in the open position.
I don’t even know what that means… “Passionate about programing”? What?
“Passion,” as it is defined in modern terms, has two very different meanings. The first (and most commonly used) meaning is “a strong and barely controllable emotion.” This meaning is most appropriate when speaking within a romantic context. Taken a bit further, “passion” can refer to a “state or outburst of strong emotion,” an “intense sexual love,” a “thing arousing enthusiasm,” or “an intense desire or enthusiasm for something.” Ok, this makes a little more sense. We’ll come back to this in a minute, though.
The second meaning, primarily taken from Christianity, refers to the suffering and death of Jesus. Definitely NOT the meaning in question. Right?
Just for the sake of the word count, let’s stick with this for another minute. The root of the word “passion” is the Latin word pati which most closely means suffer. Maybe that is what the job post referenced? Someone who is willing to suffer and sacrifice for their craft? Maybe.
Are you passionate about programming?
This question is tough to answer.
Am I enthusiastic about programming? Not really. It is a vehicle for solving problems, for creating something which was previously only an idea. Writing code is a means to an end. A tool within my toolbox.
Does programming evoke strong emotions in me? Yes. You cannot call yourself a developer or engineer without being able to list at least 5 times you’ve utterly and completely succumbed to your emotions while working on a problem. And that’s just within the past week. Anyone ever felt like this after seeing passing tests?
Does programming represent a strong sexual love? No. Don’t even…
Do I have an intense desire or enthusiasm for programming? Nope. Again, it is a vehicle for solving problems and creating things.
Have I suffered because of programming? In the first-world sense, yes. I’ve lost sleep. My hairline has receded (though I blame my kids for this, too). I have more grey hair (I also blame my kids for this). I have gained weight, lost weight, and had breakdowns. I’ve gone from feeling like a genius to looking like the kid in Parenthood with the bucket on his head. My wife says I’m dead inside because I don’t really cry (she may be right), but I almost teared up the first time I got an OAuth2 server running. I also almost teared up when I once accidentally dropped a production database (don’t worry, I had a backup).
Be polite. Be professional. Have a plan.
So on balance, I am not “passionate” about programming. I enjoy what I do. I find fulfillment and purpose in my job. But I won’t use the word, “passionate.” I am a professional, though (rather, I strive to be one). To me, this is more important.
While it may sound catchy to look for someone with passion, I think this is crap. If all things are equal, I’ll take the candidate who more exemplifies professionalism than passion. Every day of the week.
Before we proceed any further, let me be clear — I love my job. I enjoy what I do. I find tremendous fulfillment in completing and shipping projects that people use. The act of creating something is deeply satisfying. Working as part of a high-performing team is addictive, challenging, and fulfilling. If this satisfies your definition of “passion,” so be it. But, this is my post, so I choose to continue on…
Here is how it works. Passion, in the modern sense of the word, is driven by emotion. It is a great motivator. A tremendous source of energy and drive. But, like all emotions, it can ebb and wane. Passion, by its very nature, is volatile. Hire someone solely because that person is passionate about modern PHP and you may find a good fit, until they decide that Python is better. Hire a professional and you’ll get consistency.
I’m lucky to work with two individuals who are, among other things, professionals. You wouldn’t know it by talking to them, but they are easily the two most competent engineers with which I’ve had the pleasure of working. One is a baseball fanatic — specifically, the Kansas City Royals. The other loves his Jeep and can break down a UFC fight like Joe Rogan. You wouldn’t guess that they are developers by just talking to them. They are multi-faceted individuals who can talk about more than just code. Neither is very heavily involved with OSS. Neither has the github profile of Phil Sturgeon. Both, however, have forgotten more about development than I know. They have different strengths, but both are frickin’ magicians at what they do. (That makes my job very easy, by the way.)
The following elements are some of the qualities that I think of when asked to describe a “professional.”
Being humble doesn’t mean you think less of yourself. It means you think of yourself, less.
— I have no idea…
I didn’t come up with that quote. I don’t know who did. But, it is true. Being humble means putting the team first, and yourself second. This is a reluctance to accept personal praise and a desire to shift acclaim to the team and the other individuals.
I struggle with this every day. I am proud of the work I do. I take it personally when QA finds a bug or when something goes wrong. I, like most people, like the feeling of accomplishment and recognition I get when finishing a tough project.
But here’s the tough part — if you think you’re humble, you aren’t. C.S Lewis was right when he said that the first step to humility is admitting that you are full of pride. Only the proud think they are humble.
Every professional that I’ve worked with, both in tech and elsewhere, had a willingness to do whatever was needed to ensure that the team succeeded. Taking out the trash, doing the grunt work, putting in the long hours when necessary — none of it was “below” them.
I’ve seen the owner of a $40M restaurant company taking out the trash on a busy Friday night during the dinner rush because it was full. I’ve seen a 3-star Army general bring bottled water to the soldiers (E-2 privates and an E-4) on the color guard during his (outgoing) change of command ceremony because it was hot. Both of these men were servant-leaders, more interested in helping others succeed rather than their own station and status.
The professionals that I hold as role models are the first to say “I’ll do it,” willing to say “I need some help,” unafraid to say “I don’t know,” and the last to say “I can’t”.
Not only are those professionals that I look up to the epitome of team players, but they are also driven self-starters. They don’t wait for permission to solve a problem — they solve it. They exercise their initiative and judgment to move the ball forward. Who would you rather work with, someone who says, “Hey, this is a problem. What should we do?” or someone who says, “Hey, this is a problem, and I think we can fix it with X. What do you think?”
The self-starting professionals who take the initiative make everyone better. Those individuals who are the first to take a break and the last to stand back up afterwards only drag the team down.
So, too, is knowing those tasks that drain us. The ones that make it tough to go to work in the morning. The tasks that we fear. Yes, I used that word.
Professionalism means understanding your strengths and weaknesses — knowing those activities that you naturally gravitate towards and those that you would rather avoid. Marcus Buckingham, has some brilliant words about the power of understanding what feeds you and what weakens you. Take a look.
There are more things in heaven and earth, Horatio,
Than are dreamt of in your philosophy.
— Hamlet, Act 1, Scene 5
I know that missing semi-colons and spelling mistakes account for more of my debugging time than I care to admit.
I know that the “n+1” problem is real and it can cripple an application’s performance.
I know that coffee, along with ambiguous requirements and poorly-defined process, will give me heartburn.
You can barely fill a pocket notebook with the things that I “know.”
I probably spend 20% of my week just trying to keep up with all the new stuff that comes out. I am continually trying to learn and improve myself. I do this not because someone is asking me to, but because that is part of who I am. I am a lifelong learner and always will be. Simultaneously, I know that I will always be behind on my reading list. (How the hell do you people keep up??)
As a leader, I need to be technically and tactically proficient (yes, this is from my days wearing green). To be technically proficient means you can accomplish the individual tasks and use the various tools in your toolbox in a proficient and competent manner. To be tactically proficient means you can integrate the various skills and employ them in the context of accomplishing the goal and solving the presented business problems.
Technical and tactical proficiency are not states. They more closely resemble balancing a broomstick on it’s end — you have to keep working at it it to keep it standing upright. Likewise, proficiency requires constantly learning and practicing. Relentless. Methodical. Consistent.
Professionals never stop learning, never stop growing, and never stop looking to improve.
Responsibility and Example
A while ago, I screwed up. I made a mistake that took down a client’s production website. In a fit of panic and caffeine, I got the site back up and running an hour later. All along the way, I kept my boss and the account team informed of what was going on and what I was doing.
Then came the time for the mea culpa. I wrote an email to the client, accepting responsibility not only for the mistake, but for the decisions that made the mistake possible. I copied my boss, and the team members that work for me.
All of our various audit trails and checks/balances are good. They serve to force us to do what we ought to do — accept responsibility for our actions, decisions, and omissions.
As a professional and as a leader, I believe that we should seek and accept responsibility. Then, in the course of executing on those responsibilities, we need to publicly set the example in how we work, how we succeed, and how we learn from failure.
Setting the example isn’t about perfectly modeling the perfect behavior. Not only is that impossible, but anyone attempting to do that will inevitably end up being an insufferable ass.
No, setting the example means you are transparent in how you work, in your successes, and in your failures. When the team wins, a professional will shift focus towards others. In failure, the professional will accept responsibility and seek to improve. Publicly. Sincerely.
Again, something that I struggle with and something of which I am frequently reminded.
Problems and Solutions
Take a stance, not a stand. The right answer is more important than your answer.
— Michael Blake.
At the end of the day, I’m paid to bring value to the organization through the application of technology to a particular problem set. I am not paid to write foreach() statements or debate the merits of strict static type hinting versus loose type hinting. I am paid to solve problems, be curious, and write documentation.
Laravel may be the right answer today. Tomorrow, the right answer may be Drupal 8. Django may be fun to work with, but Flask may be all you need without anything else.
While we all have our favorite tools, either because of previous good experiences or current proficiency, we are generally better off letting the project requirements determine the tool we use, rather than ask the leading questions.
Professionalism means setting aside your personal favorites to look at the project as it is, not as we want it to be, or think it should be. It means being methodical when you analyze a problem, dispassionate when you propose a solution, and driven to complete the task. Work with urgency, not haste.
Who do you work for?
I work at an advertising agency. The agency serves clients in the travel space. From tourism boards to visitor/convention bureaus to hotels and resorts, the clients are in a tight, fickle, and demanding market. My boss is a friend from graduate school, but I don’t work for him. Neither do I work for those paying customers.
My clients are those people who are the down-stream consumers of my code. QA, Project Management, Client Services, the other developers on the team, the anonymous, unwashed masses sitting behind their computer wondering why the site looks “weird” in IE6. My clients are those people who depend upon the code I write, and the solutions my team produces.
My job is to serve those clients, not service them. That means I need to move towards them when we are at odds. Just like fighting an insurgency, it takes restraint, a long-term commitment to the relationship, and a willingness to take risks and be uncomfortable.
A former boss of mine would relentlessly remind me that I didn’t work for him. He constantly pushed me to buld relationships with people. A polished professional, he understood that when shit breaks (and it will), and people get mad (and they will), relational equity will allow your clients to extend grace to you. As a natural misanthrope, this is difficult for me.
Projects will come and go. Mistakes will happen. Relationships endure.
So what’s my point? Good question…
I guess my point is this — Instead of looking for a passionate developer, look for a professional developer. Look for that individual who constantly looks to improve herself and the team. Look for that individual who wants to be challenged and is willing to put in the effort to rise to that challenge. Look for that individual who runs towards the chaos when shit gets crazy and says, “What do you need me to do?”
Or, keep looking for rock stars, ninjas, and unicorns.
Me? I’ll take those quiet professionals that ship without fanfare. While you’re managing egos, we’ll be building something awesome.
Credits: Big thanks to Josepha Haden, Daniel Crothers, Ben Edmunds, and Yitzchok Wilroth for taking the time to read this and offer feedback. They are smart people. You should follow them on the twitters if you don’t already.
Fixed some spelling, grammar, and typos. Thanks for not holding those against me!
One of my co-workers (and a person a look up to) said the following:
One of my work mottos is to never say “That’s not my job.” (I may say it sometimes — but I never mean it!)
He is, of course, right on the money. You don’t hear a professional saying that about a task because it is beneath them. Of course, it is acceptable to say that when the request is so out-of-band as to be preposterous. As a non-graphically inclined developer to use photoshop to design a website? Probably not the right person for the job. Even then, you’ll most often hear “Are you sure you want me to do that? My color choices are painful and awkward…”.
Josepha Haden added the following and she is, once again, spot-on.
Passion doesn’t deserve space in a job description because of the sheer nebulousness of it. Passion can’t be measured for annual reviews.
— Josepha Haden