15th January 2011

Admit you suck

With the new year upon us I took the opportunity to reflect a little upon my career choice. What would be a good resolution for a developer? ...I decided we should all admit we suck.

Two of my recent articles made subtle reference to this. Within 'common code' I discussed the benefits of knowledge and process sharing, and during my analysis of the 11th Joel Test one of the themes was encouraging a dialog between developers who were both open and equal (i.e. not scoring points smugly).

So yeah, this is going to be a slight rant about humility, 'no man is an island', self-improvement etc but this isn't just to make the world a better place. This has tangible benefits for our careers and happiness.

Benefits?

During the latter part of last year I started collecting quotes from twitter, podcasts and the web in general that related to this idea of admitting you suck. I'll open with one by Scott Galloway:

Bad programmers are the ones who think they're already as good as they can be @scottgal

Let's be clear, we work within one of the fastest moving industries out there. You can literally be out of date on a day by day basis. If you want to get a job, work more productively or even just continue to be supported by vendors you need to stay up to date.

Don't think you're safe in your long service position not looking to move... if you work within a team and a new member joins you want them to be able to take on the work quickly. If you try and mould them to work in a way/with a technology that hasn't been used during their entire working life you are not an attractive prospect for them, and you are adding a large training overhead for yourself.

This doesn't just cover being up to date with technologies. This includes continually improving your own techniques within the existing techs you use. Because, of course, we all have legacy projects, but it's a bad sign if when we go back to these projects we also go back to our mindset at the time they were created.

The supply and demand situation where you're trying to help someone who doesn't want to be helped is not good. "I don't want be better I want to keep sucking..." let them keep sucking. Giles Bowkett

Don't be the person people avoid working with because you aren't open to new ideas or constructive criticism. Don't be precious about your baby. Give it up and open yourself to ideas from others. Acting as if you know best is a sure route to conflict within your team and will gradually isolate you. You're not making yourself a linchpin you're painting yourself into a corner.

The only people who like to hear that their code is bad are those who are trying to be better. Those are the people you want to associate with in the first place. Giles Bowkett

It's important to remember that with the huge variety of tasks/platforms/languages developers deal with every day there is always something you do not know. Length of service doesn't permit you to ignore ideas from newbies. The best quality of a senior is the ability to take something on board and change. It's neither a weakness on their part or a huge victory for you (you're not 'scoring points' by finding a minor error or suggesting a change of direction. You are simply being a good developer).

Refactor!

If you're prepared to admit you're not always right (and have the luxury of time), refactoring code can have excellent results. @jaspertandy

Clients want fast performing, cheap, flexible solutions. They want to know that you aren't stuck in your ways, that you are never resting on your laurels.

Future you wants to be able to thank past you for refactoring code in that legacy project rather than bolting on more and more half arsed patches.

The hard thing here is being willing to admit to yourself that you might have been wrong, or rather that you might now be able to do things better. Don't code in targetted islands. Be willing to reorganise and potentially even do drastic things like delete that chunk of code you just spent hours on but you now realise should be done differently.

More quotes? really?!

The trouble with programmers is that you can never tell what a programmer is doing until it's too late. Seymour Cray

If you put the blinkers on you're likely to make mistakes. The best thing you can do is open yourself up to challenges early on. Fail fast and filter out potential pitfalls by discussing approaches with colleagues or through your blog. You may find you're reinventing the wheel, or making a square one.

Asking someone a question accomplishes far more than just receiving the answer. Robert L Read

In a team dynamic encouraging a culture that doesn't fear being 'wrong' or questionning 'authority' can only be a good thing. It's a classic keep you on your toes scenario.

Ok, I'm done

We, as developers, are living in a world that becomes obsolete very quickly. There's no time for personal pride of the sort that leads you to ignore other peoples ideas or stick with a solution just because it's what you did last time. We need to be constantly checking ourselves.

So I'd say, realise you can't know everything, refactor regularly, start a blog, go to events, encourage code review, discuss your ideas openly, ask for criticism. Because, let's be honest you suck.. and so do I.