This is a direct response to this blog post.

Dear project managers,

Your job is not to tell us how to do our job.

I know you think you were hired in a management role, infact, your whole interview process was probably focussed around management of a project, and I’m sure you do it well.

But managing us is not your job.

Your job is to manage the project and manage client expectations and let us do what we do best. Develop the best user experience we can to the guidelines provided from all stakeholders. This will keep us in coffee tokens and spare money to throw away on endless Raspberry Pi’s which I’m sure we’ll find a use for at some point. We will always adhere to the standards of the target audience and will always strive to deliver the best product that we can. But let’s face it, we’re not fucking magicians.

I know we might run on high spec hardware to make our development process so much quicker and easier, but have you delivered us the requirements for browser compatibility? Don’t just say it needs to work on “IE on 4 year old laptops,” show us the metrics. Does 2% of our user base use IE8 on Windows XP and the expected revenue from those sources is less than the cost of supporting that platform? Then I’m sorry, but they can fuck right off. That’s not worth the time it takes to support. My job is to deliver robust solutions for the target users in the quickest time possible, and if that means dropping support for a barely used browser or something that’s not financially viable, then I will argue tooth and nail to drop it.

We will performance and load test our software, we will meet the required targets and, just for shits and giggles, we will push it further than that because we want to deliver a faster, cleaner, quicker and more efficient site because, y’know what, we take pride in that kind of shit. We don’t want to deliver bloatware.

And thanks for reminding me that my code needs to run in production, I was aware of this. But why in the everloving fuck would I check that it works in production? There’s two things wrong with this. Firstly, I’m not QA. I will make sure it runs locally and make sure it’s written with the required browser support, ontop of that I’ll make sure that it doesn’t fall over on unsupported browsers as a freebie because, well, why not? But we have a whole QA department that makes sure that it works on all platforms within a controlled testing environment that mirrors the production environment. If you’re checking your changes in a production environment and that’s beyond automation, regression or smoke tests, then you’ve probably fucked up along the way. Doubly so if you’re asking developers to do that work too.

And thanks for making sure we push and merge our code “into production” (sorry, feature/bugfix/hotfix branch, into develop, through QA in test environment, into a release branch from there, into UAT environments, from the release branch at EOL into master for deployment), but who is this message directed out. I would be worried if your developers were not au fait with simple version control workflows and just “pushed into production,” but the rest of us are more familiar with more robust and risk-averse release workflows.

It’s worth reiterating that fact that if you’re pushing your changes “into production” in such a simple step, you have a huge clusterfuck on your hands as a product manager, so I wouldn’t really suggest that.

And we know users do surprising things. Infact, we know more than you do because I can guaran-fucking-tee you that we’ve had to fix a bug in the past where a user has created an account, pressed back, created another account with a misspelled email, pressed back, pressed forward, opened another browser, done the same thing and called our support because the forgot password form doesn’t know the user account when they’ve spelled it wrong a third time and then put a space on the end for good measure. Rest assured that we have seen some of the most asinine bug reports which would erode your faith in the future of humanity if you had to fix them. Sure, the Jira ticket might say “password forgot form broken,” but we have just subconsciously added that ridiculous bugfix into our mental toolbox for future development.

And yeah, we know you guys have metrics to provide the business and we could probably be a bit better about tracking actuals and making sure our task tickets and burndown charts are up-to-date, but sometimes, when you’re 3 days into a bugfix that is entirely environment specific and can only be replicated by one version of an archaic browser (IE8 on XP differs from IE8 on Win7, for example!) after following a bookflow that takes 5-10 minutes each time, bugging us every half hour for progress only serves to slow us down and slow you down by proxy, so cut us some slack.

And I don’t think you’re picking on us. I think that you’re missing the point of our job entirely. We’re not management worker bees to push around and dictate to. We are specialists. We have toiled and trained for years to get to where we are, to learn what we know and focus on what we do best. We deliver software to the requirements you provide and we will make sure that we do that to the best of our ability. We will question the stakeholder’s requirements, we will question the product’s motives and don’t for a second believe this is because we’re lazy or obstructive or just trying to be antisocial, it’s because, funnily enough, in our own ways, we know the methods we need to take to deliver the best user experience from our point of view and if you want to hamper our ability, then go for it, but don’t be surprised if we just ignore your attempts to control us.

No matter what our job title, if you want to tell us how to do our job, and you’re a fucking project manager, we will tell you to fuck off because it’s goddamned insulting to think that you don’t trust that we are doing what we can to deliver the best product we can.

Thank you,

Your developer.