Do programmers take advantage of managers that don’t understand code?

How many programmers out there are being measured for the time they contribute to a project, rather than the value that project provides? You took ages to write the code, so it must be super complicated and awesome, yeah?

I was recently trawling Reddit and found that an old parable had been making the rounds once again – The Parable of Two Programmers. This got me thinking about the measurement of value that managers place on programmers in the workplace, and how this value is perceived.

We’ll always hear horror stories from under-appreciated developers about managers who assume that x lines of code equals y amounts of productivity and ‘work’. Remember the -2000 Lines of Code tale? The moral of that story reminds us that lines of code is a silly measure of software productivity.

So how are managers assessing the amount of work you’re doing and what is the measure of assessment they’re using?

Time spent vs. work produced

The main question that the headline of this article presents is about programmers taking advantage of managers who don’t know code. If you’re some kind of hierarchy junkie and assume this doesn’t actually happen, then help yourself to a reality check as you make your way out.

Let’s go back to our parable for a minute. At the end of the story, both programmers (Alan and Charles) were able to produce what management had asked for, however took different approaches which influenced the way the managers perceived their work ethic and commitment to the project.

Alan, the gun-for-hire programmer-analyst, gets the job done via the PQR structured design methodology and a programming team. In about five months, the team creates a product consisting of 2,500 lines of code and have clearly documented every planning meeting and problem-analysis. There are a couple of missing features that eventually get handled, and the system is considered somewhat fussy, but nevertheless Alan is congratulated on his achievement, given a hefty raise and promoted for his troubles. What a guy.

Our mate Charles, on the other hand, is observed as “goofing off” for the initial two months. Before his boss can confront him about his work ethic, he’s seen to be writing code, like, all the time. He’s even shelving lunch and working late a couple of days a week. By the end of the month, he’s finished the project and produces 500 lines of code. The work is impressive, concise and well-written. It’s exactly what the company wants, so Charles gets a bit of a raise despite his “goofing off” period. Eventually, Charles heads for greener pastures and leaves the company.

What exactly are we seeing here? While I don’t want to re-quote the whole parable, Mr. Alan gets more recognition and respect for his work because it looks complicated and he’s found to be actively working the whole time. It’s decided that the company’s resources have been put to good use because other than the work produced, the quality of the work can be measured against the time it took to complete.

Charles’ use of time has clearly worked against him at the end of the project, despite producing a somewhat better product in a more efficient manner, using less resources, and highlighting the simplicity of the issue. Charles’ supervisor comes to the conclusion that the undertaking wasn’t that difficult and anyway, the kid messed about for six weeks, you know?

In the examples above we can clearly see that both instances were ruled by a system where the programmers were paid and rewarded for their time, and not for their contributed value. Are you still with me?

Adding delays to increase perceived value

Harry Brignull drudged up the issue of adding delays to increase perceived value via an old locksmith story published on Hacker News. This idea is connected to the concept that time is a representation of value, separate from the end result or product created.

When talk turned to UI’s, user kareemm shared this gem about Blogger.com and the addition of a delay in their service:

I attended a “Redesigning Blogger” workshop in 2004, when Jeff Veen at Adaptive Path and Douglas Bowman (of stopdesign.com, now with Twitter) talked about their experiences redesigning Blogger.

One of the things they found in user testing was that when new users clicked “Create my Blog” on the last step of the setup process, they were confused at how quickly their blog was created. “That’s it? Is something wrong?” were the types of things people said.

So they added an interstitial “Creating your blog…” type page that did nothing but spin a little animated gif and wait a few seconds before sending new users to the “Yay, your blog is created! page”. Users were far more satisfied with the new experience that took longer.

Why is it that more pleasure and satisfaction is derived from an experience that takes longer, but achieves the same thing? In the locksmith story, people felt cheated if they had to give up their hard earned cash for a service that took approximately 3 minutes to execute. The speed of the process somehow translates to the task being ‘easy’ and ‘not worth it’.

What those grumpy bastards don’t understand is that while you’re paying for a service, you’re also paying for the contributed experience and time spent plying the trade in order to deliver better, faster and more efficient work. Enter famous story-telling version here.

In a programming scenario, the perception of time spent vs. contributed value translates in a similar way. Our buddy Charles looked like he wasn’t really doing anything, but if he was documenting the time he spent thinking about the problem for the first two months, maybe putting together super small prototypes as a way of recording the thinking process, then perhaps his boss would have valued the end result more.

Answering the question

So, lots to think about when trying to answer this conundrum. How can managers “see” or document the time it takes programmers to think about an issue, and how can this be understood against their own perception of what time spent means?

Programmers can usually tell early on if their supervisor understands code. A good programmer will be able to make their boss understand (or grasp) a project by truly understanding the problem and then expressing their solution clearly. Of course, in Charles’ case, this can backfire by making the task look too ‘simple’. A guy (who is not a singer) called Michael Jackson gives us a great example of this:

‘But what about Jane?’ I said. ‘I thought Jane was very good. She picked up the program design ideas very fast.’

‘Yes,’ said the DP Manager. ‘Jane came to us with a great reputation. We thought she was going to be as brilliant as Fred. But she hasn’t really proved herself yet. We’ve given her a few problems that we thought were going to be really tough, but when she finished it turned out they weren’t really difficult at all. Most of them turned out pretty simple. She hasn’t really proved herself yet — if you see what I mean?’

I see what he means – the lovely Jane was able to make him understand a problem that, without her input, looked complex and tough. This is the kind of manager that a disgruntled programmer is going to take advantage of.

In my opinion, if a programmer is basically deceiving their boss to adhere to some wacky measurement of value, then ya’ll need to take a leaf out of Charles’ book and look elsewhere job-wise. Of course, you could always take the “Add Eggs and Milk” approach, but isn’t that just another form of duplicity? (Making the error look more complex and that they’re involved in the process of resolving it).

According to Brignull, adding a delay to a UI (or anywhere) just seems plain wrong. It involves “pandering to consumers’ incorrect mental models rather than helping them understand the reality of the situation”, which is exactly what can happen in the developer’s workplace, too.

Being honest about your efficiency and method is a great way to get code-noob managers to understand the way you work and to appreciate and value your technique and thought-process. Just because you’re not typing 8 hours straight, doesn’t mean you’re not working on an end result.