3 Simple Rules That Will Make You a ‘Superstar’ Developer

So you’ve read Joel’s posts about how 1% of developers are 10x as productive as the rest; the superstar developers; the only ones worth hiring. You know you can program, that you’re reasonably talented, but that’s not enough. You want to be 10x as productive as everyone else in your company? You want to be the guru everyone else comes to when they’ve got a problem, the guy who takes one glance and puts his finger on the problem right away?

You can. Just follow these 3 simple rules and within 12 months all this and more will be yours.

Rule 1: Write lots of code. Have to fix a small bug in an area someone else has written? Don’t waste time trying to understand it or their motivations for writing it that way. Just rewrite the lot as you think it ought to work. Call it refactoring if anyone asks.

Rule 2: Write your code quickly. Touch lots of files, and include every one of them in the ChangeLog. Don’t worry about accidentally introducing hard-to-find bugs; they’ll actually help you later on, as long as they’re actually hard to find. Avoid introducing trivial bugs.

Rule 3: Don’t take time to document your code, or add little comments explaining potential pitfalls in modifying some of the less clear statements you’ve introduced. You don’t need them, you wrote the code.

Dilligently following these three rules will make you the superstar in your team within 12 months. Write them out and stick them up. Not in the office! Somewhere private. Repeat them to yourself every day before you start work. They may seem controversial, but trust me, everything has a deeper underlying reason.

How do I know this works? Because I’ve done it myself and because I’ve seen others do it. Of course, I didn’t realise I was adhering to the Three Rules at the time – I was young and naive and thought I was just trying to do my best for the project. It’s only now, many years later, that I am able to reflect and draw upon the wisdom of the experience to share with you like this.

The 3-Rule Programming Supremacy system is based on one technical principle and one social principle.

Technical Principle: You’re 10x as productive when you’re working on code you wrote as on code you didn’t write.

Everyone understands their own code best. It’s part memory, part convention – that is, everything follows your convention. You expect a function to be called X and it is. You look in class Y to find the functionality and of course it’s there. It’s even at the bottom of the file, where you’d have added it. All these little things add up. You don’t need to worry so much about unintended side-effects when you modify something, because you remember the places that were somewhat risque and know instinctively where you would do careless things and where not.

In short: if you wrote the code, you have an almost perfect model of the code in your head, because that’s what you used to write it.

Social Principle: Your programming ability is judged by how much code you write, how quickly you finsh features and fix critical bugs and how often your insights are necessary to solve problems.

These two principles define the problem space – or, as we shall call it – The Game. You win The Game by improving your reputation to superstar guru levels. To improve your reputation, you need to improve the speed with which you write code, fix bugs and help others. The technical principle tells us how to achieve that – by working in our own code as much as possible. Indeed, by converting as much of the project to our own code as possible.

The 3-Rule System is a foolproof strategy for achieving that.

By following rule 1, you will quickly get to know a large amount of the codebase. Most importantly, you won’t waste time trying to understand other people’s code, which is a difficult and time-consuming process.

By following rules 2 and 3, you maximize your rate of code-conversion by avoiding the most time-consuming parts of writing good code. It’s vitally important that you are touching more code than the rest of the team combined.

There are also beneficial social aspects to working like this:

Benefit 1: Everyone will see how quickly you’re committing huge chunks of code and will start to respect you – especially your boss, who has no other metric to judge you on other than commit frequency and volume.

Benefit 2: Although you’ll introduce lots of new bugs like this, it’ll be several months before they start showing up, by which time your reputation as an expert programmer will already be assured. You can now profit a second time from them by fixing them faster than anyone else. Your colleagues will take 10x longer than you to track each one down. Increasingly, they’ll ask you for advice or help because you wrote that bit of code. Be friendly, humble, happy to help. You’ll spot the bugs very quickly. Your guru reputation will grow day by day.

You can view the process as analagous to a real-time strategy game. The world map is your project’s codebase. The regions you wrote are generating you resources; the regions owned by others are generating them resources. Your resource, here, is programming efficiency, as you’re 10x as productive when dealing with your own code as with someone else’s. Being seen to be 10x as productive gains you reputation, which is the point-scoring mechanism in The Game.

Clearly if you own very little code, you aren’t going to be gaining much reputation because most of the time you’ll be working with other people’s code at the same rate as anyone else would. Time to change that.

Rule 1 is the basis for your economy. You become a superstar by owning more code in the project than anyone else. You invest in your economy by writing new code, or converting existing code to your own, because every area of code you own generates you productivity and reputation.

Rule 2 is aggressive. Expand into other people’s areas and modify their code to make sense to you. Let people see that you’re touching a lot of code – it is good for your reputation. However, you have to be careful when going on the attack. Rewriting code carries a certain reputation penalty, but more about that later.

Rule 3 is defensive. Make it difficult for other people to work in your code or fix bugs in it – for every hour they spend fixing bugs you’ve accomplished another hour of fresh code rewrite somewhere else, thus increasing your control over the board.

Never forget that this is all about gaining reputation. It’s critical not to over-extend yourself and appear as if you’re harming the project. It’s equally important to remain on excellent terms with your opponents^H^H^Hcolleagues, always being polite, helpful and humble. Your reputation determines how much of the codebase you can convert and which parts you can convert without incurring negative reactions.

To this end, you must start small, in the most hated, ugly area of code in the project. Just go in there and rewrite it all to make sense. Don’t worry about all the bugs you’ll introduce; people will be glad that you’re brave and bold enough to take the project on and will agree that it needed doing and that bugfixing the new code will be easier than maintaining the old code.

When you’ve finished, you’ll find your reputation has increased. You’ll be able to rewrite slightly less hideous areas of code without people asking if that really needs to be done. Eventually your reputation will grow so large that you can rewrite core application functionality at will. By then, you’ll know far more about the rest of the system than anyone else and will introduce surprisingly few bugs. This will assure your guru staus as superstar of the team. This is your end-game. You have won!

Postscript for the naive: This post is a mild satire on programming in teams. These three rules, while undoubtedly effective, are evil. They harm overall project progress for your own benefit. They don’t make you a better programmer intrinsically, only compared to the rest of your team. You may, like I and countless others, have done something like this completely innocently in the past, when you didn’t know better. Now you know better.

Postscript for project managers: If your environment meets the grounds for the Two Fundamental Principles, then you will get programmers playing The Game and your project will suffer. Change the rules. Make sure that programmers are recognised for playing nicely with each other’s code, for working in small teams on larger problems. That rewriting for the sake of it is frowned upon, or that the bugs it introduces are traced back to the rewrite that caused them. I don’t know what the right way to get away from this is. If you do then please, for the love of all projects everywhere, leave a comment!

Note: Yield Thought has moved to http://yieldthought.com – check there for the latest posts!