7 Ways to be a Better Programmer in 2014

Great tips to help you sharpen your skills

Coders make resolutions, no? If your to-do-better list is still empty, consider these ideas from other programmers to put to use in the New Year. Even the smartest folks have room to grow. The following excerpts are contained in the book 97 Things Every Programmer Should Know edited by Kevlin Henney.

  1. Check Your Code First Before Looking to Blame Others
  2. Continuous Learning
  3. Don’t Be Afraid to Break Things
  4. The Professional Programmer
  5. Take Advantage of Code Analysis Tools
  6. Ubuntu Coding for Your Friends
  7. You Gotta Care About the Code

1. Check Your Code First Before Looking to Blame Others

Question your own assumptions and the assumptions of others. Tools from different vendors might have different assumptions built into them so too might different tools from the same vendor.

When someone else is reporting a problem you cannot duplicate, go and see what they are doing. They may be doing something you never thought of or are doing something in a different order.

My personal rule is that if I have a bug I can’t pin down, and I’m starting to think it’s the compiler, then it’s time to look for stack corruption. This is especially true if adding trace code makes the problem move around. Multithreaded problems are another source of bugs that turn hair gray and induce screaming at the machine. All the recommendations to favor simple code are multiplied when a system is multithreaded. Debugging and unit tests cannot be relied on to find such bugs with any consistency, so simplicity of design is paramount.

So, before you rush to blame the compiler, remember Sherlock Holmes’s advice, “Once you eliminate the impossible, whatever remains, no matter how improbable, must be the truth,” and opt for it over Dirk Gently’s, “Once you eliminate the improbable, whatever remains, no matter how impossible, must be the truth.”

—Allan Kelly

2. Continuous Learning

We live in interesting times. As development gets distributed across the globe, you learn there are lots of people capable of doing your job. You need to keep learning to stay marketable. Otherwise you’ll become a dinosaur, stuck in the same job until, one day, you’ll no longer be needed or your job gets outsourced to some cheaper resource.

So what do you do about it? Some employers are generous enough to provide training to broaden your skill set. Others may not be able to spare the time or money for any training at all. To play it safe, you need to take responsibility for your own education.

Here’s a list of ways to keep you learning. Many of these can be found on the Internet for free:

  • Read books, magazines, blogs, Twitter feeds, and websites. If you want to go deeper into a subject, consider joining a mailing list or newsgroup.
  • If you really want to get immersed in a technology, get hands on—write some code.
  • Always try to work with a mentor, as being the top guy can hinder your education. Although you can learn something from anybody, you can learn a whole lot more from someone smarter or more experienced than you. If you can’t find a mentor, consider moving on.
  • Use virtual mentors. Find authors and developers on the Web who you really like and read everything they write. Subscribe to their blogs.
  • Get to know the frameworks and libraries you use. Knowing how something works makes you know how to use it better. If they’re open source, you’re really in luck. Use the debugger to step through the code to see what’s going on under the hood. You’ll get to see code written and reviewed by some really smart people.
  • Whenever you make a mistake, fix a bug, or run into a problem, try to really understand what happened. It’s likely that someone else ran into the same problem and posted it on the Web. Google is really useful here.
  • A good way to learn something is to teach or speak about it. When people are going to listen to you and ask you questions, you’ll be highly motivated to learn. Try a lunch-’n’-learn at work, a user group, or a local conference.
  • Join or start a study group (à la patterns community) or a local user group for a language, technology, or discipline you are interested in.
  • Go to conferences. And if you can’t go, many conferences put their talks online for free.
  • Long commute? Listen to podcasts.
  • Ever run a static analysis tool over the codebase or look at the warnings in your IDE? Understand what they’re reporting and why.
  • Follow the advice of the Pragmatic Programmers* and learn a new language every year. At least learn a new technology or tool. Branching out gives you new ideas you can use in your current technology stack.
  • Not everything you learn has to be about technology. Learn the domain you’re working in so you can better understand the requirements and help solve the business problem. Learning how to be more productive—how to work better—is another good option.
  • Go back to school.

It would be nice to have the capability that Neo had in The Matrix, and simply download the information we need into our brains. But we don’t, so it will take a time commitment. You don’t have to spend every waking hour learning. A little time—say, each week—is better than nothing. There is (or should be) a life outside of work.

Technology changes fast. Don’t get left behind.

—Clint Shank

3. Don’t Be Afraid to Break Things

Everyone with industry experience has undoubtedly worked on a project where the codebase was precarious at best. The system is poorly factored, and changing one thing always manages to break another unrelated feature. Whenever a module is added, the coder’s goal is to change as little as possible, and hold his breath during every release. This is the software equivalent of playing Jenga with I-beams in a skyscraper, and is bound for disaster. The reason that making changes is so nerve-racking is because the system is sick. It needs a doctor, otherwise its condition will only worsen. You already know what is wrong with your system, but you are afraid of breaking the eggs to make your omelet. A skilled surgeon knows that cuts have to be made in order to operate, but she also knows that the cuts are temporary and will heal. The end result of the operation is worth the initial pain, and the patient should heal to a better state than he was in before the surgery.

Don’t be afraid of your code. Who cares if something gets temporarily broken while you move things around? A paralyzing fear of change is what got your project into this state to begin with. Investing the time to refactor will pay for itself several times over the lifecycle of your project. An added benefit is that your team’s experience dealing with the sick system makes you all experts in knowing how it should work. Apply this knowledge rather than resent it. Working on a system you hate is not how anybody should have to spend his time. Redefine internal interfaces, restructure modules, refactor copy-pasted code, and simplify your design by reducing dependencies. You can significantly reduce code complexity by eliminating corner cases, which often result from improperly coupled features. Slowly transition the old structure into the new one, testing along the way. Trying to accomplish a large refactor in “one big shebang” will cause enough problems to make you consider abandoning the whole effort midway through.

Be the surgeon who isn’t afraid to cut out the sick parts to make room for healing. The attitude is contagious and will inspire others to start working on those cleanup projects they’ve been putting off. Keep a “hygiene” list of tasks that the team feels are worthwhile for the general good of the project. Convince management that even though these tasks may not produce visible results, they will reduce expenses and expedite future releases. Never stop caring about the general “health” of the code.

—Mike Lewis

4. The Professional Programmer

The single most important trait of a professional programmer is personal responsibility. Professional programmers take responsibility for their career, their estimates, their schedule commitments, their mistakes, and their workmanship. A professional programmer does not pass that responsibility off on others.

If you are a professional, then you are responsible for your own career. You are responsible for reading and learning. You are responsible for staying up to date with the industry and the technology. Too many programmers feel that it is their employer’s job to train them. Sorry, this is just dead wrong. Do you think doctors behave that way? Do you think lawyers behave that way? No, they train themselves on their own time, and their own nickel. They spend much of their off-hours reading journals and decisions. They keep themselves up to date. And so must we. The relationship between you and your employer is spelled out nicely in your employment contract. In short: your employer promises to pay you, and you promise to do a good job.

Professionals take responsibility for the code they write. They do not release code unless they know it works. Think about that for a minute. How can you possibly consider yourself a professional if you are willing to release code that you are not sure of? Professional programmers expect QA to find nothing because they don’t release their code until they’ve thoroughly tested it. Of course, QA will find some problems, because no one is perfect. But as professionals, our attitude must be that we will leave nothing for QA to find.

Professionals are team players. They take responsibility for the output of the whole team, not just their own work. They help one another, teach one another, learn from one another, and even cover for one another when necessary. When one teammate falls down, the others step in, knowing that one day they’ll be the ones to need cover.

Professionals do not tolerate big bug lists. A huge bug list is sloppy. Systems with thousands of issues in the issue-tracking database are tragedies of carelessness. Indeed, in most projects, the very need for an issue-tracking system is a symptom of carelessness. Only the very biggest systems should have bug lists so long that automation is required to manage them.

Professionals do not make a mess. They take pride in their workmanship. They keep their code clean, well structured, and easy to read. They follow agreed-upon standards and best practices. They never, ever rush. Imagine that you are having an out-of-body experience watching a doctor perform open-heart surgery on you. This doctor has a deadline (in the literal sense). He must finish before the heart-lung bypass machine damages too many of your blood cells. How do you want him to behave? Do you want him to behave like the typical software developer, rushing and making a mess? Do you want him to say, “I’ll go back and fix this later”? Or do you want him to hold carefully to his disciplines, taking his time, confident that his approach is the best approach he can reasonably take. Do you want a mess, or professionalism?

Professionals are responsible. They take responsibility for their own careers. They take responsibility for making sure their code works properly. They take responsibility for the quality of their workmanship. They do not abandon their principles when deadlines loom. Indeed, when the pressure mounts, professionals hold ever tighter to the disciplines they know are right.

—Robert C. Martin (Uncle Bob)

5. Take Advantage of Code Analysis Tools

The value of testing is something that is drummed into software developers from the early stages of their programming journey. In recent years, the rise of unit testing, test-driven development, and agile methods has attested to a surge of interest in making the most of testing throughout all phases of the development cycle. However, testing is just one of many tools that you can use to improve the quality of code.

Back in the mists of time, when C was still a new phenomenon, CPU time and storage of any kind were at a premium. The first C compilers were mindful of this and so cut down on the number of passes through the code they made by removing some semantic analyses. This meant that the compiler checked for only a small subset of the bugs that could be detected at compile time. To compensate, Stephen Johnson wrote a tool called lint—which removes the fluff from your code—that implemented some of the static analyses that had been removed from its sister C compiler. Static analysis tools, however, gained a reputation for giving large numbers of false-positive warnings and warnings about stylistic conventions that aren’t always necessary to follow.

The current landscape of languages, compilers, and static analysis tools is very different. Memory and CPU time are now relatively cheap, so compilers can afford to check for more errors. Almost every language boasts at least one tool that checks for violations of style guides, common gotchas, and sometimes cunning errors that can be hard to catch, such as potential null pointer dereferences. The more sophisticated tools, such as Splint for C or Pylint for Python, are configurable, meaning that you can choose which errors and warnings the tool emits with a configuration file, via command-line switches, or in your IDE. Splint will even let you annotate your code in comments to give it better hints about how your program works.

If all else fails, and you find yourself looking for simple bugs or standards violations that are not caught by your compiler, IDE, or lint tools, then you can always roll your own static checker. This is not as difficult as it might sound. Most languages, particularly ones branded dynamic, expose their abstract syntax tree and compiler tools as part of their standard library. It is well worth getting to know the dusty corners of standard libraries that are used by the development team of the language you are using, as these often contain hid-den gems that are useful for static analysis and dynamic testing. For example, the Python standard library contains a disassembler which tells you the bytecode used to generate some compiled code or code object. This sounds like an obscure tool for compiler writers on the python-dev team, but it is actually surprisingly useful in everyday situations. One thing this library can disassemble is your last stack trace, giving you feedback on exactly which bytecode instruction threw the last uncaught exception.

So, don’t let testing be the end of your quality assurance—take advantage of analysis tools, and don’t be afraid to roll your own.

—Sarah Mount

6. Ubuntu Coding for Your Friends

So often, we write code in isolation and that code reflects our personal interpretation of a problem, as well as a very personalized solution. We may be part of the team, yet we are isolated, as is the team. We forget all too easily that this code created in isolation will be executed, used, extended, and relied upon by others. It is easy to overlook the social side of software creation. Creating software is a technical exercise mixed into a social exercise. We just need to lift our heads more often to realize that we are not working in isolation, and we have shared responsibility for increasing the probability of success for everyone, not just the development team.

You can write good-quality code in isolation, all the while lost in self. From one perspective, that is an egocentric approach (not ego as in arrogant, but ego as in personal). It is also a Zen view and it is about you, in that moment of creating code. I always try to live in the moment because it helps me get closer to good quality, but then I live in my moment. What about the moment of my team? Is my moment the same as the team’s moment?

In Zulu, the philosophy of Ubuntu is summed up as “Umuntu ngumuntu ngabantu,” which roughly translates to “A person is a person through (other) persons.” I get better because you make me better through your good actions. The flip side is that you get worse at what you do when I am bad at what I do. Among developers, we can narrow it down to “A developer is a developer through (other) developers.” If we take it down to the metal, then “Code is code through (other) code.”

The quality of the code I write affects the quality of the code you write. What if my code is of poor quality? Even if you write very clean code, it is at the points where you use my code that your code quality will degrade to close to the quality of my code. You can apply many patterns and techniques to limit the damage, but the damage has already been done. I have caused you to do more than what you needed to do, simply because I did not think about you when I was living in my moment.

I may consider my code to be clean, but I can still make it better just by Ubuntu coding. What does Ubuntu code look like? It looks just like good, clean code. It is not about the code, the artifact. It is about the act of creating that artifact. Coding for your friends, with Ubuntu, will help your team live your values and reinforce your principles. The next person that touches your code, in whatever way, will be a better person and a better developer.

Zen is about the individual. Ubuntu is about Zen for a group of people. Very, very rarely do we create code for ourselves alone.

—Aslam Khan

7. You Gotta Care About the Code

It doesn’t take Sherlock Holmes to work out that good programmers write good code. Bad programmers…don’t. They produce monstrosities that the rest of us have to clean up. You want to write the good stuff, right? You want to be a good programmer.

Good code doesn’t pop out of thin air. It isn’t something that happens by luck when the planets align. To get good code, you have to work at it. Hard. And you’ll only get good code if you actually care about good code.

Good programming is not born from mere technical competence. I’ve seen highly intellectual programmers who can produce intense and impressive algorithms, who know their language standard by heart, but who write the most awful code. It’s painful to read, painful to use, and painful to modify. I’ve seen more humble programmers who stick to very simple code, but who write elegant and expressive programs that are a joy to work with.

Based on my years of experience in the software factory, I’ve concluded that the real difference between adequate programmers and great programmers is this: attitude. Good programming lies in taking a professional approach, and wanting to write the best software you can, within the real-world constraints and pressures of the software factory.

The code to hell is paved with good intentions. To be an excellent programmer, you have to rise above good intentions, and actually care about the code—foster positive perspectives and develop healthy attitudes. Great code is carefully crafted by master artisans, not thoughtlessly hacked out by sloppy programmers or erected mysteriously by self-professed coding gurus.

—Pete Goodliffe

Wishing you all the best in 2014.

Related

Sign up for the O'Reilly Programming Newsletter to get weekly insight from industry insiders.
topic: Programming
tags: ,
  • Terry A Davis

    My compiler is for a different language — operator precedence is different, for example. I’m sure it has lots of bugs. I mostly don’t hit bugs anymore. I program a certain way and most of my kind of bugs have been fixed. Some thing are not considered bugs.
    Preempt(OFF) can be used to simplify multiprocessing. From the starting gate, you will face multithreading since the screen update is a separate task with a callback.

  • yoanizer

    Hello! Thanks for the insight.

    But what makes you think you are in a good position to give advice on this topic? Are you an experience programmer, does your advice come from personal experience? Or from your “common-sense” sense?

    • http://www.joshuasimmons.name/ Joshua R. Simmons

      Hi Yoanizer! Amy is a fellow editor at O’Reilly and while she’s no programmer, she’s also not the one actually giving advice here.

      And so to answer your questions (however rhetorical they might have been): Kevlin Henney, editor of the 97 Things book, is absolutely qualified to give advice on this topic :-)

      • BahBoh

        That page doesn’t mention any code he has written.

    • CBalleChaud

      your comment is a good illustration of that chinese saying about the idiot, the moon and the finger!

      • ShortSighted

        What illustration?

        • spgun

          “When the wise man points at the Moon, the idiot looks at the finger.”

      • yoanizer

        are you ready to take any advice from the Internet for face value? There are a lot of BS on the web, (and I’m not talking only about programming). So I would say checking after the sources is not being an idiot. Just my opinion.

    • Christian Meilke

      I am a developer and all the advice is written by developers. I do not care about who compiled this list but I know how it spoke to me as a developer.

  • wat

    retarded.

  • Estevez Atya

    Be a better programmer (or programmer at all):
    - understand what you do, do not just copy-paste.
    - do copy-paste, to have more time on more intresting parts of the software creation.

    • th3byrdm4n

      Never copy paste something twice o_O

  • dig dig

    must be written by a BA or project manager….

    • Christian Meilke

      Why?

  • Olly

    Great write up. I keep banging on about being a professional and breaking things (in a good way!).

  • http://www.opwernby.com/ Dan Sutton

    0. Transcend items 1 to 7 (although you have to have done this to understand why).

  • http://www.manasbhardwaj.net/ Manas Bhardwaj

    Very well compiled Amy. Great article to read!

  • Mohan

    Good article. All good stuff. Thank you.

  • Michael Gray

    Uncle Bob is accurately “spot on” with his views on being a professional.

  • Leo Muller

    Nice article, completely agree, this gives a nice perspective on some important points that can make some of us to take that extra step from being a programmer to being a good programmer.

  • John

    All valid points, but sounds a bit preachy. Expect comments from offended readers. 2 is brilliant, 3 is wisdom, 4 needs more names. Overall would be more attractive if more tools and links to their homepages were included. eg. Dont be afraid to break code – would need more testing environment setups – Vagrant, VMs (VBox, VMWare, Xen/KVM), Bitnami, virtualenv for python. And code checking tools like JSLint, PHPlint, PMD, PHPMD. Composer is a trendy habit in the PHP world. Maybe the continuous learning should include links to “cloud” environments with free plans like cloudcontrol.com, Heroku, Amazon AWS (Free Tier), Zend PHP Cloud, appfog, frogcp. If you want cheap VPS servers to try out various new configurations or server side tools, then you have lowendtalk.com and lowendbox.com. Hope some of these names helps someone.

  • Syntax Nazi

    Syntax Error
    English, and other European languages, denote generic gender with the male form. Using female forms is politically correct affectation.

  • James

    Probably one of the worst articles I’ve read in a while. What you stated was all compeltely obvious. Instead of saying what everyone has heard, how about you provide some resources; for example:

    Read books, magazines, blogs, Twitter feeds, and websites. If you want to go deeper into a subject, consider joining a mailing list or newsgroup.

    How about providing some thoughtful links to “books, magazines, blogs, Twitter feeds, and websites” that you personally use?

  • spgun

    Interesting……

  • lovewubo

    cool, Thanks for sharing.

  • Valentin Heinitz

    Missing something like “Ethic matters” – don’t code for war-industry, don’t code for big brothers, don’t code for industries abusing addicted (gaming, gambling, etc), don’t code for industries making money with fear (so called “security”).

    • Andrew Norfolk

      One’s code of ethics is purely subjective — I see nothing wrong with coding for the military nor for gaming companies (though I’d certainly hate working in the game development industry).

  • daves

    I’ve never once thought of blaming the compiler. How does that work? Will my boss believe me?

  • Alex

    didn’t get this bit about the mentor: “If you can’t find a mentor, consider moving on.” Meaning leaving job, leaving project? Can someone clarify on this one.

  • fawad

    So, basically, in order to become a better programmer, start doing everything. The last paragraph is missing that should have read: “Find a focus to select a couple of areas to improve over the year”. You would be lucky if you bettered two maybe three major areas in your profession over a year.

  • Vishnu A Venu

    Thank….. I am thinking …. (Requesting).. to u be my Mentor!… cause i need serious Guidence

  • Havann Hansah

    pls i am new in computer programming and i want to know how to break codes and many more.