I loved listening to Get in the Ring where Axl Rose slams everyone he doesn’t like in five and half minutes of screaming cathartic vitriol. I thought Axl Rose was the new Johnny Rotten and teenage me thought he was the bollocks.

Then… the hiatus.

Axl had driven the other band members away with his perfectionism, his oil-tanker-sized ego, his self-aggrandising dick-swinging. Guns ‘n’ Roses disappeared leaving only soiled memories and rumours of Chinese Democracy – an album that took 14 years to release and, at 13 million dollars, the most expensive rock album of all time! Much anticipated, when it eventually appeared it was, well… it was shit. The architectural folly of a man to whom no-one had ever said “no”.

My Get in the Ring

I used to work with a developer as part of a small team (there were two or three devs, a project manager, a designer/uxer, and our manager). Previously, he’d been the sole developer and was clearly finding it hard to play well with others.

As lead developer, he was well within his rights to impose coding standards but he pushed his one-man-band ethos on every area – he knew everything about project management, business analysis, user experience; and woe-betide anyone who disagreed with him.

The main issue was that he didn’t communicate; simply acted petulant when he didn’t get his own way. He seemed to think that everyone else was useless and he could do their job better than they could.

This would have huge knock-on effects on everyone else; he’d build things on assumptions because he knew better than anyone who gathered requirements, he’d change design if he thought he could do it better, he didn’t need code-review because his code was golden, he didn’t even commit to repos because he was too used to no-one ever touching his code.

There’s no ego in development

He was isolationist in his approach. It could take hours to do simple tasks in his codebase because it was only “documented” in his head – and, hell, if you couldn’t figure it out without explanation, weren’t you the idiot! His code is so obviously self-explanatory(!) He understands it, why can’t you?!

Toys out of the pram

The sad truth is that we all have Axl Rose moments. I’m guilty of it and I’m sure you are too.

There are occasionally those times where we’ve been a little big-headed about our process and, especially, code. I notice it mostly when demoing things I’ve built and I get critique.

“This took ages and it’s awesome, why aren’t you happy?!”

Me, yesterday

How to be less Axl

Communication is key to everything. Some things I have taken away from my experiences include how I comment my code. I like to explain why a piece of code exists, rather than explain what it does. Well-written code should be self-explanatory in its functionality but the rationale behind using a specific method is usually abstracted away – either in a long-closed ticket or in a developer’s head. Explaining the rationale in the codebase saves anyone else working on that code, potentially, hours of digging.

For every problem, there are a million solutions – especially in code. Your solution is just one of them. Always be able to explain your solution to anyone that is interested. Other developers are not stupid for not understanding your code; it could just as easily be the other way round!

Another thing I’ve learned is that your colleagues are doing their jobs for a reason.

Here’s an all-too-common scenario at work for me; An account handler comes over to my desk and asks if I could just do this one tiny amend.

It seems like the easiest thing in the world to just pick it up but then that little task turns out to be bigger than you (or the account handler) thought – maybe you need to upgrade a library that has a knock-on effect on something else that now needs fixing and, before you know it, you’ve been working on it for five hours, it’s still not fixed and your project manager is breathing down your neck because you’ve not picked up the work you were allocated. You drop the “tiny amend” but now the account handler is breathing down your neck because you’ve not done what they want you to do!

Your project manager allocates work because they’re entrusted with making sure that jobs go to the most appropriate person to deal with them. Sure, you may have been the last person to touch the bit that needs amending, sure you may be the lead developer, but that doesn’t mean you’re the best person to deal with it right now. Heck, it might not even need dealing with right now – that’s not your call, the “when” is the PM’s call!

Part of the role of the product layer (PM’s, business analysts, tech leads, etc) is to shield developers from the crap from clients. If you’re the dev that is getting emails from clients and dealing with them yourself, you’re going to get mightily angry and resentful pretty quickly (trust me, I’ve seen it!).

Teamwork Teamwork Teamwork

As part of a development cell, you are a cog in a machine, not the be-all-and-end-all. If you want to do that, be a solo artist, don’t form a band. Teams run more smoothly when everyone is pulling in the same direction and aligned to the same goals.

If you work in a team, don’t be Axl Rose.

[He] will never have the insight to examine the part he plays in his own downfall.
~ Mike Brown, Radio Creme Brulee