Your passion affects me

I was reading a blog article titled, Love thy coworker; thy work, not necessarily and it had a very interesting quote in it:

Perhaps you disagree with my ideas on motivation. If so, here’s an idea on boundaries that I hope is uncontroversial. Telling me how I should feel about my job infringes on my boundaries, which is to say that it’s none of your business. If however I do a shoddy job and it becomes your problem, then I’m infringing on your boundaries, so you’re absolutely entitled to complain about it.

I agree with this completely in theory, but in practice, people without passion do a shoddy job. There’s many reasons why.

Before I dive into these reasons, we have to recognize that software engineering is usually a team sport. Even if you’re siloed in your corner and are the only one who ever works on your piece of code, there’s someone who depends on that code. The quality of that siloed person’s work affects others because, all things being equal, they will get their requested feature slower if the code is poor quality. That’s because it’ll be more difficult to change.

Above I was talking about quality but the topic is about passion. So why am I bringing up quality? Because in my experience, there’s a strong correlation between a person’s passion and the quality of their work. In other words, apathetic people produce shoddy work.

Passionate people keep their skills up to date. Who’s more likely to read that new Uncle Bob article in their free time? The coworker who’s passionate about what they do, or the coworker who’s doing it for a paycheck? The affect will be higher quality code.

Passionate people are happy to learn a new technology that may make them more productive. Apathetic people prefer and influence those around them to keep using the same tools they already know. They do this because there’s a high learning curve to learning a new technology so it’s easier to keep doing what you’re doing. When these apathetic people win these arguments, the whole code base can suffer. For example, 100 lines of code in one framework may be a single line of code in another.

Passionate people prefer the company of other passionate people. If they have an opportunity to leave the company to work some place where more people are passionate, they’re likely to take it. This will have a net negative effect on code quality for the reasons mentioned above and lead to shoddy work.

The author did have a bullet point that stated:

Someone’s attitude towards work does not predict the quality of their work

But, I didn’t really see anything in the article that explained why. Anecdotally, I’m hard pressed to think of someone who was passionate but did bad work and someone who was apathetic and did great work. I’d like to hear an argument for why passion and quality aren’t linked.

Don’t ask interviewees to “speak” code over the phone

Don’t ask a potential candidate to “speak” code over the phone. I’ve had interviews like this before and they’re terrible. Any programmer worth their salt can see it’s very easy to write code like this:

But, it’s another thing to say it. “if space open parenthesis x percent five equal sign equal sign…”, you get the picture. You’d think it’d be obvious, but I’ve been asked to speak code on far too many interviews.

Continue reading

“No overtime” as a hiring marketing expense

From my perspective, companies that expect employees to work overtime are doing something wrong.  But a lot of the time, that does not get through to people.  They think “hours working = features completed”. There’s a lot of scientific evidence against this idea, but it still happens at a lot of places.  So I’ve decided to take a different approach with the argument:  You should have a “no overtime” policy at your company as a marketing expense.

Despite what some may think, developers don’t like crunch time.  That means if word gets out that your company has employees working lots of overtime, it is going to be a less appealing place to work.  All other things being equal, a developer would never choose to work at the place with frequent overtime. Continue reading

“A’s hire A’s and B’s hire C’s” is a myth

There is this saying that “A’s hire A’s and B’s hire C’s”. The idea is that the best employees (A’s) are smart and want to be smarter. They also don’t want to be babysitting a bunch of bad employees (C’s) and cleaning up their messes. That’s why you can trust A’s to hire other A’s. The problem with average employees (B’s) is they feel insecure about their position on the totem pole. They are really concerned that their job is in jeopardy. That’s why, if given the chance, B’s would hire a bad employee (C’s) because it makes them look better. That’s the theory, at least.

Continue reading

The two most important things you must do before you pay someone to build your software

Because of the nature of what I do, I often get asked to look over other people’s work.  This isn’t always under ideal conditions.  Sometimes a company hired a freelancer or employee to do a job but they are unhappy with their progress.  I always feel bad for these companies because if they came to me first, I could have saved them a lot of trouble and hardship.  To save everyone’s time in the future, I’m listing the two most important things you should arrange before you work with someone to build your software:

Continue reading