Archive for January 2010
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!
There’s a lot of disucssion rattling around about Google’s new anti-censorship stance in China. Are they right? Should other companies be doing the same? Several commentators have asked why Google chooses to do this now; it seems a somewhat odd reaction to being hacked. There are widely-held suspicions that the ‘very sophisticated’ hack was sponsored by the Chinese government.
All of this plays right into Google’s hands. Their real purpose in refusing to play the censorship game any more? To make this about censorship and about China, every pundit’s favourite topics, and to disguise the truth they’re most afraid of gaining column inches: Google was hacked. Google lost data. Google is not 100% secure. Our data is not safe with Google.
As a company whose stated mission is ‘to look after the world’s data’, their greatest weakness is that this requires us to trust them with our data. They know as well as you or I that the more data they control, the more valuable a target they are to hackers, that the best way to data security is never to put all your eggs in one basket. But the information they can extract from our data is so valuable that they’re desperate to hide this for as long as possible.
Whatever the ultimate cost they may have to pay for their heroesque stand in China it pales into insignificance compared to the potential cost of a world of internet users starting to question whether they really can trust Google to look after all their data, or whether it wouldn’t be smarter to look after it themselves, or split it amongst several parties.
Besides, public opinion has already been turning against Google, with their “Do No Evil” looking more tarnished and cynical with every month, their once-proud war cry reduced to a “mumble mumble Evil”. Be sure they’ll milk their great ‘sacrifice’ for all the PR they can get, and while they do so take note: nobody’s asking whether giving all your data to Google is a good idea.
But if these hackers can steal data from Google’s servers, so can others. Maybe next time it’ll be my data that gets sold on the criminal markets to the highest bidders. Maybe it’ll be yours.
They’ll still have to pry my Gmail account out of my cold, dead fingers. Curse you and your seductively useful and innovative free services, Google!
When the Wolfram Alpha iPhone app was released for $50, we all laughed. iPhone apps cost $2, not $50! When the music industry complains about piracy we’re unsympathetic – they should stop trying to charge $20 for a handful of MP3s! $10 for an eBook? That’s insane! It’s just bits!
There’s a kind of background smugness in the software industry about digital distribution dropping content prices to a commodity level, but although we deny the truth of it, we’re in exactly the same situation. The days of selling software to consumers for $50 a time are numbered, and that number can be stored in 11 bits. The bright side is, everyone will be better off. Well, except for any poor fools still trying to sell software for $50, that is.
What’s driving the change? Several things. Digital content stores are springing up, with friction-free single-click purchasing and delivery of software. The iPhone App Store. Steam. WiiWare. XBox Arcade. In every case, a strong indie scene is springing up, and typical prices have dropped from $50 for consumer software or games down to $15, $5, even 99c. Are developers cutting their own throats? Will our jobs all be outsourced to the lowest bidder? Will we become minimum-wage factory workers, churning out dirt-cheap software in a 3rd world sweatshop?
No, we’re all going to become rich. Commoditization may drive the price of a loaf of bread down to the cost of making a loaf of bread, but how much does it cost to make a copy of a piece of software? Well, almost nothing. And yet people will pay $2 for it, just because it’s less buggy than the free version, because it make their lives better. It doesn’t have to be very good to make their lives $2 worth of better, either.
Last year Left 4 Dead’s developers posted some fascinating sales figures about a promotion on Steam. The cheaper their game got, the more money they made. Not just more sales, more profit. A lot more profit. Jeff Atwood discussed this in some detail in a post which is well-worth reading later.
Making more money by selling software for less hasn’t always been possible, which is perhaps why nobody’s noticed it yet. With a traditional software sale there’s the hidden cost to the customer of going to the effort of finding it on the web, evaluating it, creating an account, entering your credit card details and your address, deciding whether you really really trust this website and so on. Let’s say this was $20 worth of effort, although the real figure varies wildly between customers. Anyone trying to sell software this way for just $5 instead of $40 found it wasn’t selling 8 times as well. This is because it wasn’t 8 times cheaper to the customer – it cost them $5 + $20 in time and effort instead of $40 + $20; an overall $25 instead of $60. Sure, this is still a saving of just over 50%, but the software company is now taking $5 per copy instead of $40 on maybe half as many sales. The numbers just don’t work.
Friction-free payment and zero-cost distribution take this $20 of pain away, meaning at $5 your app doesn’t just appeal to people prepared to spend a total of $25 in time and money, but to the vastly larger group who will pay $5 for a latte if they can have it right there and then without filling in any paperwork. Soon, someone will make this work for web apps too. OpenID sign-in is a good start, but we need OpenID payment as soon as possible. I’m surprised you can’t sign in and pay with your Amazon account for more web services – after all, everyone has one of those already.
On the developer’s side of the fence, a standardized hardware platform decreases their support burden per sale dramatically. If you can test your software on half a dozen iPhone models and reasonable expect it to work on 99.9% of the iPhones out there, you drop your per-sale support costs to almost nothing. This is also necessary. In the web-app space these costs have always been low and even direct per-user costs such as compute time, data storage and bandwidth are dropping all the time.
Given the right environment a software company can make just as much money selling 1,000,000 units for $2 each as 10,000 for $200 each, only now 990,000 extra people are benefitting from the software, and the core audience of 10,000 have all saved $198 to spend on other things. Where will that money go? It won’t disappear. It’ll go elsewhere in the economy. A lot of it will be spent on more software – because there are a ton of tiny problems that would be worth solving for $2 that aren’t worth $200. Our society will start using and buying software ubiquitously. By 2020 almost all consumer software will sell for less than $10 and there’ll be more demand for software developers than ever before.