yield thought

it's not as hard as you think

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

with 49 comments

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!

About these ads

Written by coderoom

January 28, 2010 at 1:43 pm

49 Responses

Subscribe to comments with RSS.

  1. tongue firmly in cheek there then :P I don’t think you really needed the italic disclaimer at the bottom.

    These rules are like an Anti-pattern of programming technique.

    By these 3 rules I summarise… Superstar Developers = Technical Debt.

    Roridge

    January 28, 2010 at 3:24 pm

    • Well, you never know who might be reading! I really have seen people doing this, although I’m sure they had the best intentions at heart… fairly sure… well… ;-)

      coderoom

      January 28, 2010 at 3:29 pm

    • No sadly, the disclaimer is needed. Even sadder because it wasn’t at the top it will be the justifcation for several to behave exactly like this without knowing that it was meant in jest.

      futureturnip

      January 29, 2010 at 4:39 am

  2. I never want to work with you.

    Derek Martin

    January 28, 2010 at 4:14 pm

  3. A partial solution to this problem is good test coverage. First, it makes rewriting a piece of code more challenging (you have to adhere to the implicit specification the test cases provide). Second, if you write regression test cases, you should be able to eliminate some classes of hard to find bugs quite quickly.

    Of course, TDD comes with its own set of dangers. Test suites may become difficult maintain, and if you control the test suite, you also control the code that it is testing…

    Ryszard Szopa

    January 28, 2010 at 5:20 pm

    • surely the point here is that superstar developers don’t make time for unit tests. You aren’t going to get them to write tests first, any more than you are going to get them to comment their code!

      And certainly good developers should not have to run around after super star developers making sure there are tests for their methods.

      Roridge

      January 28, 2010 at 5:37 pm

    • I’ve never worked somewhere with a really coherent unit-testing strategy, so this might work. I’ve a feeling the wannabe superstar would simply rewrite huge sections of the tests to work with their new, restructured code though. Minimal tests, too, that don’t check a lot of the edge cases. Probably a lot of semi auto-generated ones that push up the number of tests and green lights that their code gets, because that directly improves reputation and reputation is points…

      coderoom

      January 28, 2010 at 8:54 pm

      • well yes, that is an issue, writing tests that “just pass” which do not count for other possible variations.

        Roridge

        January 29, 2010 at 8:56 am

  4. Sure, but when you inherit somebody’s very first C++ project and it contains 147 separate event loops, the jerk strategy is really the only one that’s ever going to work.

    NSD

    January 28, 2010 at 6:44 pm

    • Ah yes, first-time projects. The ones where you open a file, squint at it and then say ‘Ah, I guess he’d just got up to the chapter about templates…’

      Shortly after leaving university I was determined to use a thread for every function. It was a shame that none of the datatypes I was using turned out to be re-entrant, really.

      coderoom

      January 28, 2010 at 8:59 pm

  5. Damn fine post. So much so that I had cracked my knuckles and was starting to write the retort.

    PS FTW :-)

    Mike Wilson

    January 28, 2010 at 7:27 pm

  6. I like the bit about “refactoring other peoples code”. I dinged for that once during a performance review but I rewrote someones code when they went on vacation.

    The funny thing was that it was premeditated. I knew when the guy was going on vacation and I started the day he left…LOL

    Mike Ceranski

    January 28, 2010 at 7:39 pm

  7. [...] 3 Simple Rules That Will Make You a ‘Superstar’ Developer [...]

  8. Great. Now I am ready to become a rock star programmer. Let’s hope the other devs don’t mind.

    Maintenance Man

    January 28, 2010 at 10:01 pm

  9. I’m crying, this is so hilarious. I’m sending this everywhere.

    padraic2112

    January 28, 2010 at 10:20 pm

  10. [...] 28, 2010 Useful Satire Posted by padraic2112 under Uncategorized Leave a Comment  From Coderoom, a post [...]

  11. You are an idiot!

    Joe

    January 29, 2010 at 8:03 am

    • Heh, maybe I really should move the postscript to the top…

      coderoom

      January 29, 2010 at 8:44 am

      • lol… I say leave it at the bottom, I think the internet should learn some stability, people are too angry.

        Although, it “should” be blindingly obvious by the second paragraph you are being ironic.

        Roridge

        January 29, 2010 at 8:57 am

  12. Excellent post :D

    In Peter Seibel’s “Coders At Work” one of the interviewed, I guess it was Bernie Cosell, revealed that he actually got his “superstar programmer” reputation mainly by rewriting other developers’ code; When he was given a piece of code that was broken and he couldn’t quite understand, he would just rewrote the piece, since it was way faster than trying to familiarize himself with broken one.

    It’s always easier to find the needle from your own haystack than from someone else’s.

    Zirahvi

    January 29, 2010 at 1:50 pm

    • Fascinating – I never expected to hear of such sightings in the wild!

      coderoom

      January 29, 2010 at 1:52 pm

      • I really recommend Coders at Work, it’s a great book about software development process without being a bible for a software development process.

        Seibel just interviews a bunch of fairly well known software programmers and grills them on their techniques, what sorts of environments they wrote their most famous bit of code under, etc.

        padraic2112

        March 22, 2010 at 4:15 am

  13. [...] 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 [...] [...]

  14. Oh yes, I know this kind of guys. Sadly often the managers and sales people really think they are superstars.
    When those guys leave the company everybody fears this will be a huge loss.

    But relax. It will be a huge win. At least it was all times I experienced this.

    Joerg

    January 31, 2010 at 12:10 pm

  15. [...] is a pretty good read…and by these standards, I must be a-w-e-s-o-m-e! So you’ve read Joel’s posts about how 1% of developers are 10x as [...]

  16. You idiot, you always want to DOCUMENT YOUR CODE in a coherent manner. It’s not for you to understand BUT FOR OTHERS WHO HAVE TO READ CODE. It’s frustrating when you come into a project and try to read someone’s sh*t code b/c they don’t know how to organize/correctly label/document code.

    FFFFFFFFFFFFUUUUUUUUUU

    Kevin MacFarland

    February 1, 2010 at 3:47 pm

    • hmmmm spot the person who didn’t get the irony.

      Roridge

      February 1, 2010 at 4:12 pm

    • That is frustrating. I imagine the only thing worse would be someone who only skim-read your comments and completely misunderstood them ;-)

      coderoom

      February 1, 2010 at 8:32 pm

  17. Simple solution to all that: peer review. If every coder has to explain to another coder *why* they are rewriting giant chunks of code just to fix one small thing (and that other coder actually stops them for it if they don’t have a good reason), none of the above is possible.

    Jeremy

    February 1, 2010 at 6:02 pm

    • and what happens when the “peer” is the same…. unfortunately peer review only works if the other person isn’t the same way.

      Roridge

      February 1, 2010 at 6:10 pm

      • Even if your reviewer is a “superstar”, it won’t matter. If their boss says to them (and everyone else in the department), “I don’t want to see any more refactoring than is absolutely necessary, so if you see any in your reviews make the reviewer undo it” then they will. They have no reason not to (it’s not their code that is getting reverted).

        If you can’t even get your people to listen to their boss on something they have no personal stake in, you have much bigger institutional issues than superstar check-ins.

        Jeremy

        February 1, 2010 at 9:37 pm

  18. [...] Bonus 3: You look like a superstar without turning to the dark side. [...]

  19. Another post right on the nail.
    I just hate to read something that is supposed to be satire, but I’ve seen in the real life. Even worked with “a superstar” on a mutual project. Those memories still make me cry sometimes. :p

    John

    March 21, 2010 at 10:05 pm

  20. [...] are deliberately obscuring things just to piss you off. Actually, in the programming world this is sometimes the case. It’s easy to understand why people will go to extraordinary lengths to avoid reading and [...]

  21. [...] second post from this blog is “3 Simple Rules That Will Make You a ‘Superstar’ Developer.” It’s a “venting” post and for those frustrated very cathartic.  Let me add [...]

  22. [...] are deliberately obscuring things just to piss you off. Actually, in the programming world this is sometimes the case. It’s easy to understand why people will go to extraordinary lengths to avoid reading and [...]

  23. [...] Yield Though writes about 3 techniques that'll make you a rockstar developer [...]

  24. Nice article Thank.

    noonoob

    May 1, 2010 at 8:07 am

  25. HA, I was like “this dude has to be joking”…

    Ian

    July 18, 2010 at 5:32 pm

  26. This has been the rule rather than the exception in my experience. I never understood the mechanics of it until now, but I painfully aware of the math. Once one coder gets ahead, that coder is almost positive to stay ahead, and with increasingly *less* work as his or her domination of the code base widens.

    I’ve even had a subcontractor modify my plugin modules without notifying me. From his point of view, I should have been reading the commit log.

    I don’t think there’s any way to stop this, except perhaps in government work or on huge projects which are subject to government regulation. The payoff for the individual and for management is stupendous in the short term, promotions and bonuses for those who “make it happen,” less-than-stellar performance reviews for those unable to keep up, people who are left picking up the pieces.

    Dave

    January 23, 2011 at 6:50 pm

  27. [...] 3 Simple Rules that will make you a ‘Superstar’developer [...]

  28. I’ve seen this happen on one scale or another – but not to the point of gaming the system as envisioned. Not that it doesn’t happen, I just haven’t seen it work at that level – yet.

    That said, there *is* something to be said for aggressive refactoring (http://martinfowler.com/bliki/OpportunisticRefactoring.html), especially when your codebase is a bunch of methods that are hundreds to thousands of lines long.

    Developer Dude

    November 11, 2011 at 9:37 pm


Leave a Reply

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Follow

Get every new post delivered to your Inbox.

Join 32 other followers

%d bloggers like this: