Stories about Software


Habits that Pay Off for Programmers

Editorial Note: I originally wrote this post for the LogEntries blog.

I would like to clarify something immediately with this post.  Its title does not contain the number 7, nor does it talk about effectiveness.  That was intentional.  I have no interest in trying to piggy-back on Stephen Covey’s book title to earn clicks, which would make this post a dime a dozen.

In fact, a google search of “good habits for programmers” yields just such an appropriation, and it also yields exactly the sorts of articles and posts that you might expect.  They have some number and they talk about what makes programmers good at programming.

But I’d like to focus on a slightly different angle today.  Rather than talk about what makes people better at programming, I’d like to talk about what makes programmers more marketable.  When I say, “habits that pay off,” I mean it literally.

Don’t get me wrong.  Becoming better at programming will certainly correlate with making more money as a programmer.  But this improvement can eventually suffer from diminishing marginal returns.  I’m talking today about practices that will yield the most bang for the buck when it comes time to ask for a raise or seek a new gig.

Writing Readable Code

I’ll start with something counter-intuitive.  I can’t tell you how many folks I’ve encountered who think that writing inscrutable, convoluted code provides them with job security.  “They can’t fire me if no one but me knows how the payroll report module works!”

Sure, that might theoretically be true (although, you’d be surprised how much people saying this tend to overvalue themselves).  But while they might not fire you, they’re not exactly paying you a king’s ransom either.  If the company can’t lose you on the payroll reports module, it certainly isn’t going to promote you.  It’s not going to put you on another, more high profile project.  The thing that ensures your job keeps you firmly in place.

And, don’t kid yourself into thinking that you’re going to test the market, either.  Companies want people that write clean, maintainable code.  They need to shuffle people around to respond to business needs.  If your main resume credential is “proficient with rent-seeking behaviors,” you’re not going to have many options when you’re passed over for promotions again and again.

Don’t go that route.  Instead, write the kind of code that enables others and lets the business be flexible, both in staffing projects and making changes to the code.

Reasoning about the Unhappy Path

In the world of programming, the so-called “happy path” presents a highly optimistic scenario.  Along the happy path, nothing goes wrong and no errors occur.

Often, programmers make the mistake of programming only to the happy path.  They implement a user login page where, when the user types her correct username and password, login occurs.  But, oops, if she types either one incorrectly, the app crashes.  And if she leaves one blank, the app logs her in as admin.  Yikes.

Failing to account for unhappy path scenarios is a common pitfall for programmers.  In fact, it occupies such mind share that we embed an assumption in the very fiber of software development’s being.  You can’t allow the same people that wrote the code to test it.

Learn to reason extensively about unhappy path scenarios when writing and testing your code.  Defy this conventional wisdom.  If you become known as the developer that does it right the first time, your attention to detail will earn you raises.

Creating Automated Tests

Perhaps you continue to hold out against the mounting acceptance of automated testing in the software industry.  Heck, perhaps you even write better code than those TDD and ATDD people.  In a sense, it actually does not matter.

Don’t get me wrong.  I’m a huge proponent of automated testing because of its efficacy and the myriad ways that it improves a codebase.  I practice TDD myself, and I teach others to do it.

But, in terms of your pocketbook over the course of your career, the efficacy argument takes a backseat here.  Whether the holdouts or the proponents are right is becoming irrelevant.  Companies are increasingly demanding this skill on the resumes of applicants, whereas no companies write job descriptions that say, “must never have written a unit test.”  Learn to write automated tests, and see your job prospects grow.

Justifying Your Decisions

Why did you use the factory pattern here?  Why did you pick that particular Javascript framework?  If you tend to answer questions like this with “because it’s the right way to do it,” you’re not doing yourself any favors.

The world depends heavily on software and, by transitivity, upon software developers.  We possess an expertise that routinely puts us in a position of authority, particularly when dealing with non-technical or less experienced stakeholders.  As such, you will find that you can frequently justify what you’ve done with the paternalistic, “because I said so.”

Resist the impulse to do so.  At the very least, explain your reasoning.  Use analogies and other such aids to help people understand, even if they lack your technical experience.  Best of all, learn to make cases empirically, citing research, experimental data, or expert opinions.  Your career does not take place in a technical vacuum, and those that learn to justify programming decisions as business decisions will find themselves occupying leadership positions.

Understanding How Your Code Makes Someone Money

Speaking of the importance of business to your own pocketbook, can you articulate how a given line of code that you write helps your business?  That line of code you just added to stop a SQL injection — is it helping you by preventing damage to your reputation?  By preventing a lawsuit?  What if it’s not actually helping anyone at all (because, say, the form in question has not actually been green-lighted for production)?

If someone is paying you to write software, someone has a financial stake in the output.  Learn and understand that stake.  Develop the ability to articulate it to anyone that asks.

Developers that get excited about the latest client side technologies or the ability to spin things up in the cloud are a dime a dozen (at least, inasmuch as developers can be considered a dime a dozen).  Developers that get excited about these things and understand how they can make money with them are much rarer.

If you cultivate understanding of the business motivation for features, you will do well for yourself.  You’ll find that you see alternate ways to do things that will save time and achieve the same business goal.  Or, when a feature proves implausible to implement, you will be able to suggest something nearly as good for a fraction of the cost.

Businesses (and, specifically, people that sign your checks) love this kind of thinking in software folks.  It will mean promotions, consulting gigs, and leadership roles for you.

Thinking about Career

As I alluded earlier, becoming good at programming represents a single facet of your career, if an important one.  I encourage you to consider many others, and develop and cultivate habits deliberately.  On your own time, you should, by all means, get good for the love of the game.  But in terms of professional interest, make sure that you’re making money for others and for yourself.

Newest Most Voted
Inline Feedbacks
View all comments
7 years ago

Good article. Each of your points resonate with me. Your first point is what I refer to as “pension code”. One of my mantras, and one that I share with junior developers as well, is that “if you can’t be replaced, you can’t be promoted”. It’s a simple, if a tad trite, way to remember that unmaintainable code hurts us all but particularly the author. On happy path scenarios – I find that the code author should consider the potential paths through their implementation and write tests for that but not necessarily communicate that they’ve written these tests outside the… Read more »

Andrew Davie
Andrew Davie
7 years ago
Reply to  RollingMaul

Except I’ve never seen anyone really promoted. They might go from Developer to Team Lead, but that’s it. If they want a promotion then they have to move to another company. (Well, okay, I’ve heard of people being promoted internally…back in the 1980s)
The real reason to create maintainable code is because _I_ might be the poor sod who has to maintain it 6-12 months later when I’ve almost forgotten that project.

7 years ago
Reply to  Andrew Davie

I’d say it depends on what you call “being promoted”. Not everything is about title, or going to management. Sometimes just changing project is a form of promotion, if you gain an advantage out of it. e.g. if you’re a team lead and a part of your compensation is indexed on the size or ROI of your project, then getting bigger projects is a form of promotion. Or if some projects give you new skills that are more marketable, you get negotiation leverage if you get to chose them, which is another kind of access to promotion. If your company… Read more »

Phil Vuollet
6 years ago
Reply to  FennNaten

My philosophy on company culture…if it’s not working for you, try to change it little by little; if that doesn’t work, change what you can change – go somewhere else! PHB types can really be catalysts for change – as in the revolving door type!

Erik Dietrich
7 years ago
Reply to  RollingMaul

“Pension code!” That’s a great term — I’m going to remember that and use it, credit not mine, of course.

Pragmatic advice on the whole, too. It sounds like your approach to reasoning about the code you’re going to write is quite similar to mine, though I’ve admittedly never leveraged a Cartersian Plane to do so.

Dan Sutton
7 years ago

Very good. I’d add another one: View every project as an opportunity to learn and extend your own skills as a programmer. In all but the most banal of projects, you’ll be able to find some way in which to learn a new thing: if you find a tricky bit to solve, consider writing it several ways, just to see if you can. You never know: you might find something new – some new concept in programming which you didn’t know before. After a while, you’ll start to develop a library of concepts you never had before. If it’s a… Read more »

Erik Dietrich
7 years ago
Reply to  Dan Sutton

Excellent tips. Number 2 resonates with me especially because of what I focused on in writing my recent book — getting away from an exclusive focus of the nuts and bolts of programming in favor of looking at ourselves as professional automators/creators of efficiency. “What are you trying to do and why” should become a standard part of any conversation leading up to code.

7 years ago

Those are pretty good tips. I think I’d replace the “write maintainable code” by the more generic guideline “strive to be replaceable”. For me this includes writing maintainable code, testing, documenting (especially documenting the reasons of choices), mentoring, and knowledge-sharing in a visible way. This grants a ton of benefits. – As said in the article, you won’t end up stuck on a project – It will make you be identified as a go-to person for knowledge, giving you “tech creds” among other developers – You’ll be an “efficiency multiplier”, means even if you’re replaceable on a specific project, you’ll… Read more »

Erik Dietrich
7 years ago
Reply to  FennNaten

I think “strive to be replaceable” is a great way to put it, and all of the advice you offer squares with my own experience as well. The more replaceable I become, the better I do. This especially resonates with my life now, where I only take on consulting engagements when a specific, end state can be articulated by both parties. In other words, I always start anything I do now with an end in mind meaning I help and leave, rather than creating any dependencies on me.