MacKenzie Software

Managing programmers and the programming mother******* mentality

Posted by MacKenzie Software on January 29, 2015

Disclaimer - obscene language is used in this post - not for the easily offended!

I came across the following great site on Stumbleupon programming-motherfucker.com and as a developer had a great laugh before realising that in my day job I'm really the guy the site is having a swipe at!

The site aims it's gun firmly at the door of managers, whether they practice agile, XP, Scrum, waterfall etc and pokes fun at the agile manifesto:

Programming Motherfucker Screenshot of the alternative manifesto from programming-motherfucker.com

Whilst the site may be a bit tongue in cheek (obviously taking inspiration from Pulp Fiction), a huge challenge of managing developers can be the fact they can see you as a roadblock in the way of them producing code. Ultimately you are responsible for the success or failure of a project and as a result you have probably applied a process to the team to help you ensure your team are progressing in the correct direction. So how, as a manager, can you break down this perception from members of your team who have this mentality?

Before I start, I'll confess when I started my first programming job I agree 100% with the sentiment of this site - I thought the people managing me had crazy processes which did nothing but slow me down. Over time and as I progressed through the ranks, I guess my mentality has changed - that or I've been broken by managers ;-)

Firstly put your cards on the table and explain why a certain process is in place. If you are transparent and can explain why you have a process - truthfully - then you will gain respect. If you use a tool like JIRA or Rally to manage workload, explaining that its really to help you manage people's workload and help plan releases and how their use of these tools allow you to do that will at least help them understand. The key here is to ensure that firstly the admin they are required to do is as little and efficient as possible, and secondly to get their input into the process and how they think it could change to make their work easier. At the end of the day a business and jobs survives because it makes money, if someone cannot accept that then you shouldn't employ them anyway.

The second thing which really really helps, is to be good technically in the first place. If you are not only a manager, but a good programmer (mother******) then they wont feel like you are bullshitting them. I talk about this in my post can someone from a non-technical background manage a team of programmers?

You have to accept that you can't force people to do something, if you want them to do it well. Unit tests are a great example; you can force people to do them but they'll end up writing rubbish tests. If the programmers are engaged in why the team wants unit tests, then they'll write good tests.

The last thing you should do, is look at the table above and work out where you currently sit - are you closer to the "They Claim to value" column or the "They Really Value" column. If you are to the right, you should look at what you can do to move to the left. Have you gone too far in trying to manage the team that you have actually moved away from the basic principles?

It's an interesting topic - how do you deal with programmers who have this attitude? If you are a programmer what do you think managers can do to be more effective?