Signs that you're a good programmer

Signs that you're a good programmer

The most frequently viewed page on this site is Signs you're a bad programmer, which has also now been published on dead trees by Hacker Monthly, and I think that behoves me to write its antithesis. "Bad programmer" is also considered inflammatory by some who think I'm speaking down to them. Not so; it was personal catharsis from an author who exhibited many of those problems himself. And what I think made the article popular was the "remedies"--I didn't want someone to get depressed when they recognized themselves, I wanted to be constructive. Therefore if you think you're missing any of the qualities below, don't be offended. I didn't pick these up for a while, either, and many of them came from watching other programmers or reading their code. 1. The instinct to experiment first The compiler and runtime can often answer a question faster than a human can. Rather than seek out a senior programmer and ask them "will it work if I do this?", a good programmer will just try it and see if it works before bringing their problem to someone else. Symptoms Side projects Dabbling in other programming languages, especially ones from a different "family" (procedural, stack-based, concurrent, etc.) Knows what you're talking about when you mention "Arduino" Old, uncommitted code that duplicates other code's functionality but isn't referenced elsewhere in the project A tendency to suggest wacky and unrealistic solutions in meetings A cubicle or desk populated with toys that came from ThinkGeek How to acquire this trait Are you excessively cautious? Are you only comfortable when you have permission? Has anyone ever said that you were passive aggressive? You might consider inviting some friends to visit the local Six Flags or some other roller-coaster park. If you want baptism by fire, then make your first ride the scariest (for me, it was the "Drop Zone" at King's Dominion, with some reinforcement a few years later on the Kingda Ka at Six Flags). If you consider yourself ready to get off the kiddie rides you might try your hand at hang gliding and windsurfing, which have the benefit of teaching you what you can and cannot control. Much of what makes people timid to experiment is chemical--your brain has a small number of adrenergic receptors, so a little bit of adrenaline excites your fight-or-flight reflexes too much. But consider why people grow tolerant to coffee: the caffeine's byproducts force their brain to grow more adenosine receptors. So if you force your brain to grow more adrenaline receptors then the same amount of "fear juice" will trigger a lower percentage of them. Find some experience that scares the shit out of you, do it a few times, and you will lose your fear of venture on a physical level. Note: A programmer who "suggests wacky and unrealistic solutions" is not always a bad programmer. It can be a sign of creative thinking from someone who assumes confirmation or correction will come from somewhere else down the line.  2. Emotional detachment from code and design Code is like kleenex: you use it when it's useful and throw it away when it no longer serves. We all like to think that code-reuse is important, and while it is, it's not meant to be about raising a child. Code doesn't feel. Code doesn't care. Code will turn on you like a Frankenstein monster. Code is just bytes. Code is a liability. Symptoms Almost no committed code that is commented out Willingly throws away weeks or months of work in order to adopt another programmer's superior code Puts finger to lips, furrows brow and says "hmm" when faults in their work are pointed out, while looking at the code and not the critic Indifferent to the way the IDE wants to auto-format code, uninterested in "tabs-vs-spaces" arguments Refers to it as "the code" rather than "my code", unless accepting blame Has abandoned a design of theirs that was previously used in a successful product Doesn't become defensive when the boss mentions that they're looking for an off-the-shelf alternative to what they've been writing for the past few years How to acquire this trait Konrad Lorenz, the author of On Aggression, suggested that a scientist should begin each day by throwing out one of his pet theories in order to remain sharp. Consider throwing out one of your pet algorithms or design patterns or exquisite one-line Sodoku solvers every morning to remind yourself that it's you who controls the idea, not the idea that controls you. Find the code that you're the most proud of and delete it, now re-write it from scratch in a different way. Use a "design pattern" that confuses you, or that you hate (e.g.: the Singleton) and figure out how to make it work. If necessary, delete that after you've got it working and try again with a new pattern or language. Not only will you learn that there's More Than One Way To Do It, but you'll learn that your code is transitory. Code, by its nature, is not just inextricably glued to its language, platform, and the APIs it consumes, but written in the form of ephemeral static charges, orientations of magnetic particles, subject to the whims of the market, Moore's Law, and your employer. Other techniques to break the abusive relationship: Maintain somebody else's code Experience, either by accident or bloody intention, what it's like to lose a week's work to a failed backup or a botched commit and have to re-write it all over again Work for start-ups where you'll get laid-off when the second or third round of financing doesn't come through Be stupid enough to post your best code on Reddit Read the bit about "Destructive pursuit of perfection" further down in this article 3. Eager to fix what isn't broken Programs are infrastructure: they're built to serve a specific need, but needs always change. Good programmers realize that hard-coded values buried in code are bad, that a destoryBaghdad() function is immoral, and that it's a priority to eliminate "code smells". Not for pride. Not for backslapping attaboys from your peers or the authors of methodology books. But because you will itch until it is fixed. Symptoms Doesn't take the spec by its word and tries to find out who wrote it and what they were thinking Hunts down and talks to the people who will use the program each day Owns a book written by a guy called Martin Fowler Tends to express extreme like or dislike for popular technologies such as XML, ORM and REST, and has also switched positions on one or more of these in the past Likes to use abstraction layers, but doesn't like to add more than one layer on top of what's already in the language or platform Talks about "low cohesion" At least 10% or more of their commits reduce the line-count of the project without adding new functionality Before adding a new feature, checks to see if an existing one can be re-designed to perform both tasks or replaced entirely with a better method How to acquire this trait The first attempt to solve a program in code will always bear the artifacts of discovery: discovering the true nature of the problem, discovering the features of the platform, and discovering the best way to solve it. The second attempt will be more stable, but might inherit too much cautionary baggage and become a nightmare to extend. And so many programs today are like the Firth of Forth Bridge: disgustingly over-engineered. Sometimes it's the developer's first crack at the problem and looks like a lawn mowed by a dog, sometimes it's their second attempt and looks like the dog installed grass-cutting laser turrets every 2 feet. It can take a third try before the designer understands the problem completely and knows how much, or how little they need to do. Code lets you learn in stages where you don't need to re-write everything from scratch. You re-write pieces after you understand what they need to do and what they'll never need to do, make them simpler, shorter and beautiful. Go through your home and repair all the annoying things you've been putting off; fix the crooked picture on the wall, unclog the slow draining sink, repair that gutter drainpipe so your basement doesn't flood, buy a UPS and backup drive for your computer and configure them to shut-down/back-up automatically, replace all the incandescents with efficient bulbs, replace that ethernet cable draped down the hallway with WiFi or some proper wall-jacks and conduit, get a real food-dish for your cat instead of that old cheese-dip container. Next you should go to your last project and read through the code. Think about what each piece does. There's a loop here, some sorting there, a bit of number crunching, screen updates, HTML generation, database CRUD, that sort of thing. Now replace the hard-coded HTML with a templating system, get the database CRUD out of your business objects and re-write it to use proper parameterized queries instead of string concatenation, replace all the "writelns" and "MessageBoxes" in your error handlers with a logging framework, refactor code that's trying to borrow methods from other classes, use locale-aware string formatting, stop guessing how big an array should be and use a dynamic collection, delete orphaned code. Aim for these, in increasing order of importance: Code that does the same thing, but is shorter or more efficient Code that does the same thing, but uses an appropriate "wheel" built-into the platform instead of reinventing its own Code that does the same thing, but is easier to modify for similar needs Code that does the same thing, but is easier to read and understand Code that doesn't exist Hit #5 and you can call yourself a Zen Apprentice. Do it for a decade until you do it instinctively and you can call yourself a Zen Master. 4. Fascinated by the incomprehensible I am only just beginning to understand what a Fourier Transform does, but I've been studying them because I have the damn persistent feeling that I could be using them somehow. I don't know what I would use them for yet, but maybe I will someday. What I do know is that what I don't know will cost me in useless labor.  Symptoms Visits Lambda The Ultimate on a regular basis Knows what ATP synthase is. Has extracted DNA from a banana in their kitchen Owns a book with a dragon on the cover, especially if they don't write compilers Giggles when someone says the phrase "This is recorded on sticky-tape and rust" Shoves through a crowd at a party to get near someone who just used the word "Bayesian" Buys drinks for people who work in other industries and seem willing to talk shop when drunk Has a habit of boring people to tears explaining something tangentially related to the news, such as the cockpit layout of the Airbus 330 Has foreign-language versions of popular songs on their iPod Envies but doesn't resent people with degrees in something they don't know How to acquire this trait This tends to start in childhood but can be cultivated in adulthood if you can commit to exploring your horizons. Friends are a major gateway: seek social occasions where you'll bump into people you don't know under circumstances where they'll be unhurried and at ease. This may involve alcohol. Don't try to impress them, don't compete with them, but display your ignorance willingly to see if they lean forward to correct and enlighten you. Then shut your fool trap and listen. When you hear or read something you don't recognize then Google it or hit Wikipedia. For a programmer an equally superior resource is Ward Cunningham's Wiki, which deserves weeks of your life. Computer programming has annexed all of the sciences and the feedback loop is so wide it stuns gods. From biology we took Genetic Algorithms. From climatology we took chaos theory. Biologists now use our work to fold proteins. Climatologists now use our simulations to predict armageddon. Everything informs us, and we inform everything. Either probe the unfathomable or retire on a "blub" programmer's salary.  5. Compelled to teach I once knew someone who thought it was good advice to "never teach everything you know" because they once lost a job after bringing a co-worker up to speed with all their skills. I stared at them with genuine incomprehension. A good manager would never get rid of someone who's not only capable of all their tasks but also demonstrates ability to train new workers. It would be like shooting the goose that lays golden eggs. If you get fired, it's probably for some other reason. Symptoms Blogs about their work Has an active Wikipedia account Unhesitant to pick up a marker and approach a whiteboard Commits changes to the repository that consist only of comments Lets new hires borrow books that cost them $100 to buy Pauses "The Andromeda Strain" at the part about the sliver of paper getting between the bell and the ringer and grins like a madman How to acquire this trait I can only do this when I'm inspired or "in the mood", and I think that this mood is a product of circumstance, one that's made up of confidence, space, opportunity and provocation. When you're in school your teacher has the space and opportunity already supplied for them and their confidence is hopefully given by their training, but the inspiration is tricky; it's the difference between a good lesson that both the teacher and the student enjoys and a laborious exercise in rote memorization. Novices in computer programming aren't usually novices in general, because they have lives and friends and family and hobbies and interests that have been going on for even longer. Maybe you do need to bore someone to tears by explaining something that's cool to you, even if it has nothing to do with programming. Maybe you have a younger sibling you can teach the guitar, or your favorite recipe, or how to balance on a pogo stick. Maybe you have a coworker who doesn't know how to ski. It doesn't matter the subject, just that you get a taste of what it's like to program someone else's brain in a positive way. If you've never taught anything before you will discover, to an embarrassing degree, just how many times you can say "um" and "er" per minute, how badly you're prepared, and how easily you can forget that the student doesn't know details you haven't explained yet. One of the tricks that worked for me was to volunteer for an opportunity to teach a complex subject (microbiology) to laymen. The first time I tried it I used a Post-It easel and a bunch of markers and tried to draw everything. I was all over the place. It was humiliating. But the audience, fortunately, was friendly. The next year I tried again, but this time I had an iPad and used Keynote to put together a presentation, which was a lot of fun in itself, but this time the lesson went overwhelmingly more smoothly. I used lots of pictures, very little text, almost no bullet points, a handful of jokes, and just relied on my memory to talk about slides I had designed to provoke my memory more than illustrate anything to the audience. The experience of doing an awful job the first time informed my next attempt, and now that I've done it three or four more times I find I'm getting slightly better. Not only that, I now know ten times more about the subject because I studied like crazy to help temper my fear of being asked a difficult question. Teaching teaches the teacher.