Tag Archives: Leadership

Failing productively

I was in the Facebook offices in London recently. Very cool offices in a very nice location but what one of the things that struck me most was the signage on the walls.

I have to say that I absolutely love this.

It’s one thing to hear this at conferences (which sometimes seem to exist for the express purpose of making us aware of our own incompetence!) or from coworkers who have your back anyway. It’s another thing to have this as fundamental aspect of the culture corporate and just a million miles away from the lip service that so many companies pay to this idea. You know the sort of company, they maybe have a nice motivational picture of an eagle along with a pithy comment about attitude and altitude and think they are being daring. If you are lucky your direct boss embraces the idea that being able to fail is a good thing and if you are really lucky your boss’s boss does too but the whole company? Really?
Continue reading

Leadership is not Management!

Apologies if I’m stating the bleeding obvious yet again but my previous article, Developers: you are not the sum of your technical skills, raised a bit of comment on reddit. Not a huge amount of comment since the commentary that programmers cannot be insular is fairly obvious but one point that was raised a few times was the section that dealt with being in charge of a team.

“I really, really hate that this is taken as a given. The idea that every successful, productive programmer will eventually lead a team is just… Frustrating.”

“As to being “put in charge of a team”, leaders tend to emerge whether you christen them with a title or not.”

Now there are two points here. Firstly, I completely agree that much of the industry has a mildly insane view of the career track of a developer and secondly there is a massive difference between leadership and management and should encourage qualities of the former from everyone, not just those put in charge of a team.
Continue reading

Developers – You are not just the sum of your technical skills

I’ve been pondering the fact that when I started out on a career in development, I focussed on the technical side of it almost to the exclusion of all else. This was especially true for me since I was coming from a non CompSci background after spending years sticking electrodes in people’s heads and doing biological research. This made me painfully aware that in an industry like programming, if you don’t know your stuff you are useless to your team and your company. Worse, you run the risk of ending up a Net Negative Producing Programmer and reduce your team’s output to less that it would be if you weren’t there.

Thus the first few years of a my career as a developer were spent focusing entirely on technical matters. I fought hard for the expertise in the areas that I worked in: Java, JavaScript and C, web development, back end services and multi-threading… the list is long and mostly distinguished (EJB’s… blergh!). I wanted to be that go-to guy for all thing technical and do my part in making my team the best in the company. As a contractor, my skills were the yardstick for how I was judged for new roles so of course I was interested in keeping them up to date.

After a relatively short time it became obvious that this wasn’t enough. Being technically adept is the foundation of our job but certainly not the totality. Even before you get your first job you realise the importance of communication. Not just in communicating your skills to get that first job but then once you’ve got it, then communicating with the rest of your team including the non technical members. This is especially true in an Agile world where you have to be able to tell others what is going on in a way that they will understand.
Continue reading

Yahoo! announce that the new CEO is…a coder?!

So Yahoo! have announced that their new CEO (the third in the last year) will be Marissa Mayer, an executive from Google.

This is big news but why? It’s not just that she’s a woman or that she’s only 37 or that she’s leaving the dominating Google for the beleaguered Yahoo!. Actually it is all of these things but to me it’s also that she used to be a software engineer. For start-ups, it’s obviously common to have a techie as the CEO since they are normally the ones that kicked things off but for mature companies it’s almost unheard of. Then again, maybe this is Yahoo!’s style since they did the same with previous CEO Carol Bartz, another pure CompSci grad and former “field analyst”. Tech companies like their C-levels to have some level of CompSci but normally along with some sort of business degree. It’s just not that usual to see engineers make it to that level.

Developers are normally seen as being unable to see the bigger picture or stay hands off. They struggle to move from an individual contributor to a strategic force multiplier since there is rarely a sense of achievement at the end of the day. In strategic posts decisions may take months or even years to come to fruition, completely unlike the minutes or even seconds long cycle of code>compile>test>deploy that developers are used to.

Whatever the successes or failure of Marissa Mayer, and I hope she does better than Ms. Bartz, it shows that these attitudes are changing as people realise that developers are more then just code monkeys.

The Characteristics of a Good Developer

The recent rash of interviews have made me think a little more about what makes a good developer and more importantly, which of these qualities can you try to spot during the interview process. After having a conflab with a couple of other devs and one of the few recruiters I know that isn’t a shark, I came up with this list. Of course this is going to be a personal list but some of the points seem to intersect with some other resources out there so I don’t think I’m too far out there:

  • Polyglot in outlook
  • Able to learn quickly, and happy to learn
  •  Open to new ideas but capable of defending their own
  •  Technically able
  •  An Influencer
  •  A Producer
  •  Not too proud to ask for help
  •  Knowledge across a broad spectrum of topics
  •  Determined

Polyglot in outlook
One of the Java devs I work with recently coded up one of the most elegant solutions to a complex problems that I’ve ever seen. When asked how he came up with it, he mentioned that he based it around some of the structures that Make uses internally. Too many developers only live within the walls of their favourite language and never see what else is out there that they could take advantage of. As a Java house, currently I would have to say that anyone with Scala or Clojure on their CV will be seen far more favourably than someone with just Java and someone with half-a-dozen languages is almost always going to be going places. In fact during interviews I will deliberately ask questions on concepts in languages that aren’t on the candidate’s CV since I want them to at least be aware of these concepts even if they have never used them.

Able to learn quickly, and happy to learn
As a self-confessed knowledge junkie, I love learning. In fact I find it hard to comprehend what other developers do not. Given that we are in a knowledge industry, those that do not have a thirst to learn will find themselves going the way of the guys who thought that punchcards and ticker tape would last them a lifetime.

Open to new ideas but capable of defending their own ideas
What is the point of having great ideas if you don’t have the ability to defend them. Developers tend to have robust opinions about how things should be done so you have to be able to defend what you think is right. Otherwise you are condemning yourself to work on projects where you spend your time muttering to yourself “this could be done so much better”.

Technically able
You have to bring skills to the table. You can be the greatest person in the world but unless you have the technical chops to be able to develop you will just be a drag on the rest of the team. Don’t be the Net Negative Producing Programmer

An Influencer
This is the pro-active side of being able to defend your own ideas. You need to be able to change or at least shape the ideas of others and have the communication skills to do so. Especially at the level of senior developer or above, you have to start spending time educating and influencing others. If you fail to do this, all you are doing is making your job harder. You have to be able to prevent small problems blowing up into big ones and if that means you need to sell your ideas, then that is what you do. If you are a Senior Developer and above, I expect you to influence your workplace. For example, if your current employer does not use a Continuous Integration Server like Hudson/Jenkins or Bamboo, you have failed in your responsibilities if you cannot convince them that they should.

A Producer
Seeing someone’s work on something like Github gives me one of the best insights into what sort of programmer they are. Ultimately, it’s the Quarterback problem, it’s practically impossible to judge someone’s ability until you see them in action. The closest thing you can get to seeing them in action is to see the results of previous work and this is why we have a technical test as part of our interview process. And before you roll your eyes, we’ve made sure that the test is directly related to what we do and isn’t just some random logic puzzle. If you are already on a team, make sure that you take time to look at your work and check to see if there is anything your should be doing or anything you should not be doing that would improve your productivity. I knew of an Architect at a recent company who was obviously very bright but was unable to produce anything.  He literally produced nothing but ghosted around on his domain knowledge and reputation when he actually contributed nothing to the teams in his area.

Not too proud to ask for help
If you get properly stuck on something, no one will think worse of you if you ask for help. You will drive your team mates mad if you disappear off and take days with a problem, especially if one of them immediately gives you the answer that would have saved days. Your colleagues will quickly realise that the people who have to cover for you getting stuck is them.  The only time people will think less of you is when you get stuck and don’t even bother to try to figure it out yourself before you start asking for advice.

Knowledge across a broad spectrum of topics
Depth of knowledge demands breadth of knowledge. It is impossible to be an expert in one area without having a degree of expertise in others. The ability to link concepts is hugely important and if you already know something similar, even in an unrelated field, learning something else will be so much easier.

The tired old saw of ‘when the going gets tough, the tough get going’ aside, you have to have a certain cussedness to succeed in programming. Spending hours trying to pin down an elusive race condition or tracking an issue through layers of network infrastructure, web servers, caches, web services and database code means that you can’t be someone that throws in the towel early. Also, there are always going to be times when you are going to have to put in some extra work. Whether it is an approaching deadline or a sudden change in project priorities or roles, no one is going to thank you if you can’t manage your focus. If you are known to meet challenges head on, your team mates will always be there with you and will always have your back. If you have any tendency to slack off, you colleagues will leave you high and dry and I wouldn’t blame them at all.

I should also say that this also applies to situations where management are asking you to do ridiculous things. If the higher-ups have you on a Death March, I don’t want someone that meekly caves in an agrees to late nights and weekends in the office without seeing if it is the right thing to do. Determination is not the same as working insane hours and sometimes people need to remember that.

I was also going to put in something about leadership. This is a hugely important skill but you can be a very good developer without it so I felt I could leave it out without it being to big an issue.

Anyway, that’s my list. What do you think?