Posts Tagged ‘superstar’
Incompetence is the cause of many ills in the software world, but increasingly I’m seeing a certain kind of competence as being just as destructive. You see, there are a lot of programmers who care deeply about their code. I did, but it turns out there are good reasons we shouldn’t do that; reasons why we should hate our code…
Reason 1: It keeps you open to change
The most productive way to write software is to release early and iterate quickly with feedback from real users, right? It saves us from implementing the wrong features, that it helps build a community and so on. What’s people don’t talk about as often is the impact it has on our relationship with the code. Putting a program in front of users is terrifying because they might not like it. The more lovingly we craft and polish every class before release, the more carefully we plan our abstractions and structures, the more emotionally attached we are to the way we have made it.
The result is that we instinctively resist making significant changes to the code based on early feedback, even though this was the whole point. It’s an unconscious, emotional reaction that we rationalize away to ourselves by claiming the users just don’t understand the feature, or that it just needs a bit more polish when, seen objectively, the best thing to do might be to restructure it completely do do something rather different.
In fact, the best way to remain responsive to your users is to hate your code.
Reason 2: Jeff Atwood says that you should
You can tell a competent software developer from an incompetent one with a single interview question: “What’s the worst code you’ve seen recently?”
If their answer isn’t immediately and without any hesitation these two words: “My own,” then you should end the interview.
— Jeff Atwood
Every now and again people attack Jeff for his assertion that we write bad code, for his arms-wide-open group humility. I think people misunderstand him. The message is not you are a bad programmer, it’s that part of being – of becoming – a great programmer is writing code that you’re ashamed of. If you think all the code you write is wonderful, you’re probably not learning anything.
Reason 3: If you don’t hate your code, you’re wasting too much time on it
Andy Brice famously wrote that if you aren’t embarrassed by v1.0 you didn’t release it early enough – you spent too much time polishing it to meet your expectations instead of giving it to the user and finding out what they think of it. A corollary of this is that if you aren’t embarrassed by your own code then you spent time crafting and reworking it until you loved it. This is time that you should have spent trying to make a product the user will love.
Nobody cares if you refactor to use the Chain of Responsibility pattern or not; they want simple, elegant features that work first time. We should spend our time delivering that, instead.
Reason 4: It’s what Jesus would do
No one can serve two masters. For you will hate one and love the other; you will be devoted to one and despise the other. You cannot love both your code and your users.
— Matthew 6:24 (lightly paraphrased)
Reason 5: Loving your code for its own sake will make your product suck
Loving your own code is a kind of hubris. It presumes that you’re writing the code so that you can work on it in the future, or can show off a neat trick to your colleagues.
This love is misplaced; your code isn’t going to be judged on its internal beauty and consistency. It’s going to be judged by people who just want to get their work done. They’ll love it if it makes that easier and they’ll hate it if it distracts them from that task, if it makes their lives harder.
Creator: I love the power of Unix/AJAX/C#/whatever.
Customer: I want to finish my work and go play outside.
— Scott Belkun
I once spent six months crafting a beautifully-constructed version 2.0 of our company’s product. We’d started again so we could use unit tests throughout, the code was completely modular and pleasant to work on. There was none of the spaghetti-code complexity that dogged the first version.
We demoed an early prototype to management and marketing who said:
Great, so it’ll be ready next month?
Aghast I pointed out we still had to add a whole bunch of features and do a ton of testing. Their faces fell, and at that point I realized that it didn’t matter how beautiful the new codebase was. It would cost too much to bring it up to the feature level of the old one.
Its intrinsic beauty wasn’t worth anything; only user-visible features weighed in the balance. The project was cancelled, and rightly so.
To worry about code aesthetics more than the aesthetics of the product itself… is akin to a song writer worrying about the aesthetics of the sheet music instead of the quality of sounds people hear when the band actually plays
— Scott Belkun
Reason 6: Gandhi would want you to
Hate the User class, love the user.
— Mahatma Gandhi (lightly paraphrased)
Reason 7: It will make you a better developer
Like most people, I got into programming because I wanted to write things for myself and for my friends. During this enthusiastic newbie phase I was a happy user and a happy developer. My code sucked but I didn’t know that yet.
Later on I got into programming for its own sake, I ended up caring deeply about the kind of design patterns I was applying and whether this for loop could be refactored a third time. Eventually this abstraction freak phase left me almost incapable of creating any real value because I invariably got lost in the upper echelons of the software design and never finished any useful features.
Of course, when I started writing professionally I had to care about the features, and had to see my beautiful code mutilated again and again in the name of profit, of getting this feature out in time for the next release. This is enough to make anyone into a bitter veteran.
Eventually I started discovering the joy of programming again, via dynamic languages and web frameworks that made it possible to get useful programs out of the door on day one. I started writing side projects I actually wanted to use. I became free to write the minimum necessary to make something useful. I’d become the ‘guru’, who mistakenly believes he’s better than everyone else because he’s finally become productive again.
But I haven’t become great yet. What might the next step be? I don’t know. Reading more code? Writing less code? Perhaps. But at the moment I have a feeling that to grow in another dimension – creating awesome software – I need to sacrifice the pride I’ve built up in my art:
The seventh step of humility is that a monk not only admits with his tongue but is also convinced in his heart that he is inferior to all and of less value, humbling himself and saying with the Prophet: I was exalted, then I was humbled and overwhelmed with confusion and again, It is a blessing that you have humbled me so that I can learn your commandments.
— The Rule of St Benedict 7.51-54
Until today I found this quote somehow ridiculous or inhuman, yet now I’m beginning to believe that overcoming our egos and admitting that we are writing unworthy code but writing it anyway is a vital step in becoming truly great programmers. Perhaps we can let go and accept that, ultimately, the code never really mattered at all.
Postscript: I’m not saying we should set out to write bad code. It’s vitally important to have an idea of how the code should end up, but instead of working and working until we achieve that and then shipping the product we must write the least we can get away with while gradually approaching the ideal. Understanding this distinction is crucial.
Note: Yield Thought has moved to http://yieldthought.com – check there for the latest posts!
So the other day, coffee in hand, I opened up one of our bug tickets about some unusual error messages in our C++, GUI-based desktop application and was confronted with this little gem from another dev:
The code does this:
2f0: 48 81 ec e8 01 00 00 sub $0x1e8,%rsp
2f7: 48 89 5c 24 18 mov %rbx,0x18(%rsp)
2fc: 48 89 f3 mov %rsi,%rbx
2ff: 48 89 6c 24 10 mov %rbp,0x10(%rsp)
but the compiler doesn’t emit the correct FDE. It claims %rbp is not
stored on the stack frame, even though it’s stored at 0x10(%sp) by the code.
00000038 0000001c 00000000 FDE cie=00000000 pc=000002f0..00000add
DW_CFA_advance_loc: 7 to 000002f7
(r6 = %rbp)
I responded instinctively by spraying my keyboard with droplets of delicious dark caffeine. “Kr-ala-fskwag-yak,” I spluttered, “Uh wha?”
I shouldn’t have been surprised – this kind of bug resolution isn’t all that uncommon from the developer in question, although this was a particularly fine example at a sensitive time of the morning. The developer is, I somewhat grudgingly admit, the best I’ve ever worked with. She* is also prone to patch the windowing system we work with, or indeed any other open source API we have to use.
(* The sex of the developer in question has been changed to protect the innocent)
You might argue that tracking a bug all the way from the GUI symptoms down through assembler and DWARF output is overkill, a waste of time that could better have been spent elsewhere, but you’d be wrong, wrong, wrong. The amount of time it took Janine* to do this? 54 minutes.
(* Yes, the name has been changed as well – there’s no such thing as overkill, after all)
Fifty. Four. Minutes. From start to end. I couldn’t have done that. More to the point, I wouldn’t have. I cut my coding teeth on the Windows API and I’m used to finding what appears to be a bug^H^H^Hundocumented API behaviour and thinking “fine, let’s not waste any more time there, I’ll find another way around.”
Everyone does that, right? Sometimes things just don’t work. The universe just says ‘no’. But the other way of looking at it – Janine’s way – is that computers are logical systems that follow simple instructions. There’s *always* a reason they’re doing what they’re doing. If you keep looking, you can find it.
Having watched Janine at work for a while now, I can see three sweet bonuses for doing this regularly.
Bonus 1: You actually fix the bug, resulting in more elegant application code, free of awkward workarounds.
Bonus 2: You build up a set of tools and techniques for following bugs right down to the assembly level, which makes tracking down problems in the future easier and faster every time. Eventually it takes even less time than getting a cup of coffee and complaining about the API to anyone who can’t get away fast enough.
Bonus 3: You look like a superstar without turning to the dark side.
But these are all just bonuses compared to the best reason to hunt bugs relentlessly through the layers of API right down to their source:
Superstar bonus: You understand your software stack at many levels of abstraction.
Let me explain why this is awesome, because I know it sounds, well, dull. Abstraction is such a Java word. I know.
It’s like this: when you learn to drive a car, you’re told that one pedal makes it go faster, one slower and the wheel turns. Maybe you learn to change gears. That’s pretty much enough to be able to drive a car from A to B.
A racing driver, on the other hand, knows – even groks – that pushing the accelerator increases the flow of fuel through the injectors. He knows that the exhaust gases produce back-pressure on the engine while the turbo is still spinning up, before the boost effect starts to kick in. He knows that his suspension setup distributes this amount of pressure on the tyres during a tight corner, which is just below the coefficient of friction with this road surface.
To put it another way, he understands driving a car at a deeper level; he sees behind the first layer of abstraction and this makes him a much better driver.
In the same way, Guido van Rossum is a much better Python programmer than I’ll ever be, because he knows the system literally inside out. Sure, I have this idea that the garbage collection system uses reference counting rather than the more modern generational systems, but I don’t know that it’ll need to do some cleaning up exactly here, or that using tuples instead of lists just there will result in two fewer indirections per loop in the bytecode.
Although I don’t believe in Joel and friends’ concept of ‘superstar’ programmers (a subject for a whole post on its own), it seems clear to me that you can be 10x as productive in a particular domain that you understand deeply, thoroughly.
That’s why I’m convinced that anyone who wants to become great should take the extra time to peel back that comfortable layer of abstraction and learn about the unseen world beneath.
It’s the only honest way I know to become a superstar.
Disclaimer: I didn’t write this and take no credit for it whatsoever. edw519 wrote it as a comment on Hacker News, which you can see here: 3 Simple Rules That Will Make You a ‘Superstar’ Developer – or at the time of writing on the wonderful HN Best Comments page. However, I’m terrified that this zen-like jewel will become lost in comment-page obscurity. Also I want an easy way to link to it, so here it is without further commentary:
A smart accountant once told me that the answer to “How much money did you make?” is always, “Who wants to know?” If it’s an investor, the answer is “A lot.” If it’s a customer, the answer is “A little.” If it’s the IRS, the answer is “None.”
Same thing here. The answer to “Who is a superstar developer?” is always, “Who wants to know?”
To a project manager, the programmer who hits every deadline (regardless of quality) is a superstar.
To a customer, the programmer who solves their problem quickest is a superstar.
To a business owner, the programmer who makes them the most money is a superstar.
To a PHB, the programmer who makes them look the best is the superstar.
To a journalist, the programmer who tells the best stories is the superstar.
To a junior programmer, the best mentor is the superstar.
To another programmer, the programmer they are most likely to want to go into battle with is the superstar.
— edw519, writing an incredible comment on an otherwise unworthy Hacker News story.