Signs that you're a fantastic programmer
Signs that you're a fantastic programmer
I only wish I had these traits and I can only write about them because I've observed them in others. Every now and then I have a moment where I think I'm living one of these, but those moments are rare and cherished. They are also debilitating and brush up against the stereotypes of autistic savants, trading one kind of virtue for another: if you want greatness you have to be prepared to pay.1. Incorruptible patience
Symptoms
- Fire alarms provoke annoyance more than panic
- Cannot name any song that just played on the radio or through their headphones
- Is oblivious to how many times their cubicle-mate has gone for coffee, the bathroom, or the hospital
- Unbothered by office politics
- Can predict a bug before the code is ever run
How to acquire this trait
Distractions are a product of imagination. The day I wrote this I found myself horribly distracted and annoyed by someone at my gym singing songs in French while I sat in the sauna. The singing moved around outside the sauna and pissed me off. I wished he'd stop because I couldn't concentrate. I pictured a man without concern of others, a douchebag, someone who'd wear a pink shirt and order people around. Then I came out of the sauna and saw it was an old man, chocolate in complexion and as threatening as a worn teddy bear with button eyes. He'd started singing La Vie en rose, which is a song I that I not only loved but that made me wonder, just then, if it was me who'd long since turned into an insufferable asshole.
I don't know how to shut out distractions, but if I had to try I'd guess it'd involve a little bit of deference and so much fascination that it directs your imagination instead of being dictated by it. When I want to be like this I want to take life without taking it personally.2. A destructive pursuit of perfection
The worst optimizations favor profit over beauty, and between the two it's beauty that lasts longer. Perfection isn't the same as obsession, but they're damn close.Symptoms
- Preference for dismissal over compromise
- Contempt for delivery dates
- Substantial refactoring on the eve of a deadline
- Unwilling to accept bonuses, promotion, or stock options for expediency
- Fondness for films directed by Stanley Kubrick
How to acquire this trait
As Tyler Durden says you must know--not fear--know that someday you will die. Your nice condo with Ikea furniture is a side effect, not a reward. If you are not a unique, beautiful snowflake then what you create has to be.
It's also known as pride in one's work. Remember that emotional detachment from code is a virtue, but this doesn't mean emotional detachment from your work is, too. In fact, another way to become emotionally detached from code is to put your interest into the outcome instead. The outcome you should be thinking of is a lady who's going to get fired if she doesn't deliver the output of your program at 4:59pm sharp.
There's a legend about a marketing type who worked for Sam Walton at Wal-Mart and came up with a brilliant campaign to advertise a widget. Sam took a look at the proposal and said something to the effect of "this is great, now take the cost of the campaign and use it to lower the price of the widget instead." According to legend, the widget sold better and made more profit that way than if the campaign had been carried out.
Let the spirit of the story roll around in your head for a while and think about how it'd map to what you do at work. You boss probably isn't like Sam Walton, but perhaps there's a little bit of Sam in you. Is it better to compromise the way others want, or to make the product just a little bit better?
This could be hazardous to your income, it's risky to your stock options, but when you do a job right, when you do things properly, when you complete a project the way it ought to be, then sometimes time absolves all indulgences. Sometimes the boss calls you back to the carpet to apologize to you.3. Encyclopedic grasp of the platform
Most programmers realize the short lifespan of their tools and don't waste much of their lives memorizing what's doomed to be obsolete. But neither do most programmers appreciate how everything in this industry is a derivative of some earlier thing, sharing syntax and constraints that will live well past our own personal expiration dates. The best programmers have done what Oxford used to insist on: if you learn latin and mathematics then you can fuck all of that other modern nonsense, because you'll have the tools you need to understand anything.Symptoms
- Can recite from memory all of the includables in the C Standard Library
- Raises a knowing eyebrow when you mention the "500 mile email"
- Has a copy of the OpenDoc Programmer's Guide gathering dust on their shelf
- Can complete any sequence of dialogue from Lord of the Rings, Star Wars, Red Dwarf or Monty Python
- Rapidly identifies a synchronization bug caused by TCP's Sliding Window algorithm
- Recognizes a bug that's caused by a microcode error on the CPU you're testing on
- Has a framed personal check for $2.56 from Donald Knuth
How to acquire this trait
Encyclopedic knowledge takes decades to acquire, but every Guru in the world got there by doing roughly the same three things each day:- Struggling to solve problems they find to be difficult
- Writing about how they solved difficult problems
- Reflecting on how they solved difficult problems
Once upon a time a novice programmer was stumped by a bug that he couldn't figure out. The crash report was full of strange numbers he didn't recognize, like -32,760. Where the hell is that coming from? He hits Ctrl-F and searches all of his code files for "-32760" but it doesn't appear anywhere. Nothing makes any sense. A week goes past during which he goes back to his old college computer-science textbooks, the compiler's manual, everything, and on the last day his glazed eyes rest on a table of numbers. Through the fog of his tired mind he suddenly recognizes one of them: -32,768. He thinks about how remarkable it is that it's so similar to his problem number, and then he notices that this table of numbers is showing the ranges for various integer types and how there can be signed and unsigned versions of both. When the light comes on it's blinding.
Thrilled with his belated insight he writes a blog post about it which disappears into the global ether unread by all but a handful of buddies. That night he lies awake, thinking about that bug and about integer types and the pros and cons of compiler-checked types and so-on.
Ten years later our friend is the lead programmer at the firm, and one day he glances over the shoulder of a junior programmer who's showing evident frustration. Tucked down in the stdout window is a bunch of debugging traces and the number -32,762. The now-guru programmer taps the newbie on the shoulder and says "are you passing an unsigned int16 to code that's expecting a signed int16?"
If you're not encountering problems that are difficult for you to solve then you need a change of job or hobby or scenery or something. Look for opportunities to work with something new at your job or school, try hacking your Roomba, pick a bug in an open-source project that nobody has touched for months and fix it, try answering tumbleweed questions on StackOverflow that force you to look up something you didn't know.
If you could look inside the brain of a guru with a magic magnifying glass you might see clusters of neurons packed around the visual cortex that, like the infamous "Grandmother cells", lie dormant for months but light up when something significant comes into view such as a power of two, or a suspiciously precise delay that points to a DNS timeout, or the signature of the FDIV bug. Those "grandmother cells" can only be made the hard way.4. Thinks In Code
Symptoms
- In casual conversation their readiest metaphors come from programming constructs
- Spends the majority of their time "goofing off", but commits more bug-free code each day than their colleagues
- Glances over your shoulder and points at a bug in your code with their finger
- Correctly diagnoses bugs over the phone while drunk or in bed
- Comes up with their best code while taking a shower*
- When confronted with an obstinate bug, their instinct is to get up and go for a walk
- They suddenly pause and stare into space in the middle of a conversation, then abandon you to hurry back to their terminal with no explanation (AKA "A Columbo Moment" or "Gregory House behavior")
How to acquire this trait
Them darn kids and their cell phones, how does a 12 year-old teenage girl tap text messages on a numeric keypad so fast anyway? It can't be genetic, since all those damn brats can do it, no matter their gender or parentage. It can't be upbringing, cuz kids in every social class can do it. So you rule out this and that and what you're left with is an ancient truth: people think in the language they learned to speak. A teenager's thumbs already know where to go and they think in texting. When writing, typos feel wrong. People who learn multiple spoken languages and use them regularly tend to think in multiple languages, too, after they've practiced for so long that they no longer have to do a translation in their heads first. Rather than read a phrase in Russian and translate it to English in their minds before understanding it, they just understand it in Russian.
You cannot think "Fire rearward missile" and then translate it to Russian, you must think in Russian.
If you've heard about Sapir-Whorf or read Nineteen Eighty Four and all that jazz then you might already appreciate the implications: words convey ideas, language is thought. Whether that's a syntactic language or a visual or auditory language in your head doesn't matter, it's the way your brain deals with symbols and their rules for manipulation that matter.
The best book you can read (and perform the exercises of) to acquire this trait is Structure and Interpretation of Computer Programs by Abelson, Sussman and Sussman. It uses Scheme to present its lessons, and even if that's not the language you write programs in it's still one of the best languages to program your brain with. Remember: learn math and latin and you can understand anything.
Whether you have this book or not the key is to practice with coding until you can read and reason with it like your native tongue. You can't acquire this trick in 30 days, it may be more like 30 months. You'll know if you've got it when you begin to see in code as well.
* - Shaddap Bob, and you too, Sat.5. When In Rome, Does As Romans Do
I don't think I live up to this because I like to use MonoTouch to write iOS apps. I do know Objective-C and can write apps in it, but my heart belongs to LINQ. If I were to suppose an exception to this rule, it would be: "but when in the Roman accounting department, does as accountants do." It is not always wrong to pick a language that fits the domain, even if there's a performance or feature disadvantage from running in an interpreter or other layer. Yet great programmers will never insulate themselves from the hardware and will learn the native language anyway. Every abstraction leaks.Symptoms
- No automatic interest in cross-platform frameworks
- Contemptuous of "language wars"
- Doesn't see a strategic disadvantage in maintaining the same program in multiple languages
- Assumes their own code is the source of a bug before blaming the compiler, library or operating system
- Displays a plush Tux penguin or Android in their cubicle soon after being assigned to a project targeting that platform
- Switches brand of cell phone or tablet in the same circumstance
- Hits a stack of technical manuals before assuming a data-type like double or decimal will do what they think on a new device
How to acquire this trait
These guys are as comfortable with platform diversity as they are with having multiple vegetables on the same dinner plate. I said "thinking in code" and "emotional detachment" were virtues, and this is the bonus that comes for free. While these programmers appreciate abstraction they don't automatically appreciate generalization. If there was no advantage to be had in a new platform, then why was it ever created?
There's a thousand computer languages because there's a thousand classes of problems we can solve with software. In the 1980s, after the Macintosh debut, a hundred DOS products were ported to the new mouse-driven platform by clubbing the Alto-inspired UI over the head and brute-forcing the keyboard-driven paradigms of PCs into the Mac's visual atmosphere. Most of these were rejected by Apple or the market, and if they came back for a second try they came back because somebody flipped open the spiral-bound HIG and read it sincerely.
Maybe Excel needed to emulate Lotus 1-2-3's slash-driven menus. Maybe AutoCAD still needs to host a command line. But the designers of both never neglected the new world and that's why they're still famous today. Objective-C has Categories, C# has Extensions, but they're not quite alike and they're not quite the same. What's a Key-Value Observer to one might be like an Event to the other, which is as informative as saying an opportunity is the same as permission.
To acquire this trait you have to begin by learning a new platform through both its unique instructions and the way the user interacts with it. Much of what's out there is made to be very similar to what you already know so you can start using it quickly (radically different platforms "ahead of their time" tend to fail), but be attentive to what's different. Android phones tend to include more hardware buttons than iPhones. Maybe that's good, maybe that's not, but their users expect programs to use them. Don't disappoint them: neurons are harder to program than transistors.
New platforms either debut a new language or new conventions that are unique, and at whatever level that is you need to learn a new vocabulary. Even if it looks like they took an existing platform and "tweaked" it, the tweak in question must have significance. They say a Big Mac's Special Sauce is just Thousand Island dressing with more sweet pickle.
To manage a single product written to multiple platforms you need to abstract your product, not the platform its delivered to. You do that through elimination, by stripping platform-specific code out of your product's soul. If you can master "Eager to fix what isn't broken" then go bonkers on your code until there's only a few chunks left on the coroner's table; that's the part that stays.
The simpler it is, the easier to modularize. The easier to modularize, the easier to separate concerns. The easier to separate concerns, the less has to change to fix bugs and add features. The less has to change, the easier to translate those changes to another system. Don't rely on automatic methods--it's like relying on a cat to tie your shoelaces.6. Creates their own tools
Symptoms
- Has set up an automated build server
- Has written their own benchmark or specialized profiler
- Maintains an open-source project on GitHub
- Has re-invented LISP at least once
- Knows what a Domain Specific Language is, and has designed and written an interpreter for one
- Extends their IDE/Editor with custom macros
- There's a Radio Shack project enclosure on their desk with a bunch of 7-segment displays showing the number of issues assigned to them in the bug tracker
Signs that you're a fantastic programmer
I only wish I had these traits and I can only write about them because I've observed them in others. Every now and then I have a moment where I think I'm living one of these, but those moments are rare and cherished. They are also debilitating and brush up against the stereotypes of autistic savants, trading one kind of virtue for another: if you want greatness you have to be prepared to pay.
1. Incorruptible patience
Symptoms
- Fire alarms provoke annoyance more than panic
- Cannot name any song that just played on the radio or through their headphones
- Is oblivious to how many times their cubicle-mate has gone for coffee, the bathroom, or the hospital
- Unbothered by office politics
- Can predict a bug before the code is ever run
How to acquire this trait
Distractions are a product of imagination. The day I wrote this I found myself horribly distracted and annoyed by someone at my gym singing songs in French while I sat in the sauna. The singing moved around outside the sauna and pissed me off. I wished he'd stop because I couldn't concentrate. I pictured a man without concern of others, a douchebag, someone who'd wear a pink shirt and order people around. Then I came out of the sauna and saw it was an old man, chocolate in complexion and as threatening as a worn teddy bear with button eyes. He'd started singing La Vie en rose, which is a song I that I not only loved but that made me wonder, just then, if it was me who'd long since turned into an insufferable asshole.
I don't know how to shut out distractions, but if I had to try I'd guess it'd involve a little bit of deference and so much fascination that it directs your imagination instead of being dictated by it. When I want to be like this I want to take life without taking it personally.
2. A destructive pursuit of perfection
The worst optimizations favor profit over beauty, and between the two it's beauty that lasts longer. Perfection isn't the same as obsession, but they're damn close.
Symptoms
- Preference for dismissal over compromise
- Contempt for delivery dates
- Substantial refactoring on the eve of a deadline
- Unwilling to accept bonuses, promotion, or stock options for expediency
- Fondness for films directed by Stanley Kubrick
How to acquire this trait
As Tyler Durden says you must know--not fear--know that someday you will die. Your nice condo with Ikea furniture is a side effect, not a reward. If you are not a unique, beautiful snowflake then what you create has to be.
It's also known as pride in one's work. Remember that emotional detachment from code is a virtue, but this doesn't mean emotional detachment from your work is, too. In fact, another way to become emotionally detached from code is to put your interest into the outcome instead. The outcome you should be thinking of is a lady who's going to get fired if she doesn't deliver the output of your program at 4:59pm sharp.
There's a legend about a marketing type who worked for Sam Walton at Wal-Mart and came up with a brilliant campaign to advertise a widget. Sam took a look at the proposal and said something to the effect of "this is great, now take the cost of the campaign and use it to lower the price of the widget instead." According to legend, the widget sold better and made more profit that way than if the campaign had been carried out.
Let the spirit of the story roll around in your head for a while and think about how it'd map to what you do at work. You boss probably isn't like Sam Walton, but perhaps there's a little bit of Sam in you. Is it better to compromise the way others want, or to make the product just a little bit better?
This could be hazardous to your income, it's risky to your stock options, but when you do a job right, when you do things properly, when you complete a project the way it ought to be, then sometimes time absolves all indulgences. Sometimes the boss calls you back to the carpet to apologize to you.
3. Encyclopedic grasp of the platform
Most programmers realize the short lifespan of their tools and don't waste much of their lives memorizing what's doomed to be obsolete. But neither do most programmers appreciate how everything in this industry is a derivative of some earlier thing, sharing syntax and constraints that will live well past our own personal expiration dates. The best programmers have done what Oxford used to insist on: if you learn latin and mathematics then you can fuck all of that other modern nonsense, because you'll have the tools you need to understand anything.
Symptoms
- Can recite from memory all of the includables in the C Standard Library
- Raises a knowing eyebrow when you mention the "500 mile email"
- Has a copy of the OpenDoc Programmer's Guide gathering dust on their shelf
- Can complete any sequence of dialogue from Lord of the Rings, Star Wars, Red Dwarf or Monty Python
- Rapidly identifies a synchronization bug caused by TCP's Sliding Window algorithm
- Recognizes a bug that's caused by a microcode error on the CPU you're testing on
- Has a framed personal check for $2.56 from Donald Knuth
How to acquire this trait
Encyclopedic knowledge takes decades to acquire, but every Guru in the world got there by doing roughly the same three things each day:
- Struggling to solve problems they find to be difficult
- Writing about how they solved difficult problems
- Reflecting on how they solved difficult problems
Once upon a time a novice programmer was stumped by a bug that he couldn't figure out. The crash report was full of strange numbers he didn't recognize, like -32,760. Where the hell is that coming from? He hits Ctrl-F and searches all of his code files for "-32760" but it doesn't appear anywhere. Nothing makes any sense. A week goes past during which he goes back to his old college computer-science textbooks, the compiler's manual, everything, and on the last day his glazed eyes rest on a table of numbers. Through the fog of his tired mind he suddenly recognizes one of them: -32,768. He thinks about how remarkable it is that it's so similar to his problem number, and then he notices that this table of numbers is showing the ranges for various integer types and how there can be signed and unsigned versions of both. When the light comes on it's blinding.
Thrilled with his belated insight he writes a blog post about it which disappears into the global ether unread by all but a handful of buddies. That night he lies awake, thinking about that bug and about integer types and the pros and cons of compiler-checked types and so-on.
Ten years later our friend is the lead programmer at the firm, and one day he glances over the shoulder of a junior programmer who's showing evident frustration. Tucked down in the stdout window is a bunch of debugging traces and the number -32,762. The now-guru programmer taps the newbie on the shoulder and says "are you passing an unsigned int16 to code that's expecting a signed int16?"
If you're not encountering problems that are difficult for you to solve then you need a change of job or hobby or scenery or something. Look for opportunities to work with something new at your job or school, try hacking your Roomba, pick a bug in an open-source project that nobody has touched for months and fix it, try answering tumbleweed questions on StackOverflow that force you to look up something you didn't know.
If you could look inside the brain of a guru with a magic magnifying glass you might see clusters of neurons packed around the visual cortex that, like the infamous "Grandmother cells", lie dormant for months but light up when something significant comes into view such as a power of two, or a suspiciously precise delay that points to a DNS timeout, or the signature of the FDIV bug. Those "grandmother cells" can only be made the hard way.
4. Thinks In Code
Symptoms
- In casual conversation their readiest metaphors come from programming constructs
- Spends the majority of their time "goofing off", but commits more bug-free code each day than their colleagues
- Glances over your shoulder and points at a bug in your code with their finger
- Correctly diagnoses bugs over the phone while drunk or in bed
- Comes up with their best code while taking a shower*
- When confronted with an obstinate bug, their instinct is to get up and go for a walk
- They suddenly pause and stare into space in the middle of a conversation, then abandon you to hurry back to their terminal with no explanation (AKA "A Columbo Moment" or "Gregory House behavior")
How to acquire this trait
Them darn kids and their cell phones, how does a 12 year-old teenage girl tap text messages on a numeric keypad so fast anyway? It can't be genetic, since all those damn brats can do it, no matter their gender or parentage. It can't be upbringing, cuz kids in every social class can do it. So you rule out this and that and what you're left with is an ancient truth: people think in the language they learned to speak. A teenager's thumbs already know where to go and they think in texting. When writing, typos feel wrong. People who learn multiple spoken languages and use them regularly tend to think in multiple languages, too, after they've practiced for so long that they no longer have to do a translation in their heads first. Rather than read a phrase in Russian and translate it to English in their minds before understanding it, they just understand it in Russian.
You cannot think "Fire rearward missile" and then translate it to Russian, you must think in Russian.
If you've heard about Sapir-Whorf or read Nineteen Eighty Four and all that jazz then you might already appreciate the implications: words convey ideas, language is thought. Whether that's a syntactic language or a visual or auditory language in your head doesn't matter, it's the way your brain deals with symbols and their rules for manipulation that matter.
The best book you can read (and perform the exercises of) to acquire this trait is Structure and Interpretation of Computer Programs by Abelson, Sussman and Sussman. It uses Scheme to present its lessons, and even if that's not the language you write programs in it's still one of the best languages to program your brain with. Remember: learn math and latin and you can understand anything.
Whether you have this book or not the key is to practice with coding until you can read and reason with it like your native tongue. You can't acquire this trick in 30 days, it may be more like 30 months. You'll know if you've got it when you begin to see in code as well.
* - Shaddap Bob, and you too, Sat.
5. When In Rome, Does As Romans Do
I don't think I live up to this because I like to use MonoTouch to write iOS apps. I do know Objective-C and can write apps in it, but my heart belongs to LINQ. If I were to suppose an exception to this rule, it would be: "but when in the Roman accounting department, does as accountants do." It is not always wrong to pick a language that fits the domain, even if there's a performance or feature disadvantage from running in an interpreter or other layer. Yet great programmers will never insulate themselves from the hardware and will learn the native language anyway. Every abstraction leaks.
Symptoms
- No automatic interest in cross-platform frameworks
- Contemptuous of "language wars"
- Doesn't see a strategic disadvantage in maintaining the same program in multiple languages
- Assumes their own code is the source of a bug before blaming the compiler, library or operating system
- Displays a plush Tux penguin or Android in their cubicle soon after being assigned to a project targeting that platform
- Switches brand of cell phone or tablet in the same circumstance
- Hits a stack of technical manuals before assuming a data-type like double or decimal will do what they think on a new device
How to acquire this trait
These guys are as comfortable with platform diversity as they are with having multiple vegetables on the same dinner plate. I said "thinking in code" and "emotional detachment" were virtues, and this is the bonus that comes for free. While these programmers appreciate abstraction they don't automatically appreciate generalization. If there was no advantage to be had in a new platform, then why was it ever created?
There's a thousand computer languages because there's a thousand classes of problems we can solve with software. In the 1980s, after the Macintosh debut, a hundred DOS products were ported to the new mouse-driven platform by clubbing the Alto-inspired UI over the head and brute-forcing the keyboard-driven paradigms of PCs into the Mac's visual atmosphere. Most of these were rejected by Apple or the market, and if they came back for a second try they came back because somebody flipped open the spiral-bound HIG and read it sincerely.
Maybe Excel needed to emulate Lotus 1-2-3's slash-driven menus. Maybe AutoCAD still needs to host a command line. But the designers of both never neglected the new world and that's why they're still famous today. Objective-C has Categories, C# has Extensions, but they're not quite alike and they're not quite the same. What's a Key-Value Observer to one might be like an Event to the other, which is as informative as saying an opportunity is the same as permission.
To acquire this trait you have to begin by learning a new platform through both its unique instructions and the way the user interacts with it. Much of what's out there is made to be very similar to what you already know so you can start using it quickly (radically different platforms "ahead of their time" tend to fail), but be attentive to what's different. Android phones tend to include more hardware buttons than iPhones. Maybe that's good, maybe that's not, but their users expect programs to use them. Don't disappoint them: neurons are harder to program than transistors.
New platforms either debut a new language or new conventions that are unique, and at whatever level that is you need to learn a new vocabulary. Even if it looks like they took an existing platform and "tweaked" it, the tweak in question must have significance. They say a Big Mac's Special Sauce is just Thousand Island dressing with more sweet pickle.
To manage a single product written to multiple platforms you need to abstract your product, not the platform its delivered to. You do that through elimination, by stripping platform-specific code out of your product's soul. If you can master "Eager to fix what isn't broken" then go bonkers on your code until there's only a few chunks left on the coroner's table; that's the part that stays.
The simpler it is, the easier to modularize. The easier to modularize, the easier to separate concerns. The easier to separate concerns, the less has to change to fix bugs and add features. The less has to change, the easier to translate those changes to another system. Don't rely on automatic methods--it's like relying on a cat to tie your shoelaces.
6. Creates their own tools
Symptoms
- Has set up an automated build server
- Has written their own benchmark or specialized profiler
- Maintains an open-source project on GitHub
- Has re-invented LISP at least once
- Knows what a Domain Specific Language is, and has designed and written an interpreter for one
- Extends their IDE/Editor with custom macros
- There's a Radio Shack project enclosure on their desk with a bunch of 7-segment displays showing the number of issues assigned to them in the bug tracker