loading

2017.04.28 / industry

Habits That Pay Off for Programmers

Erik DietrichErik Dietrich

图标
  
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 many people saying this tend to overvalue themselves).

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 mindshare 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 an 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 to 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.
 

Related articles

Contact

Fast and accurate grasp of the customer's business form in the rapidly changing market.
Free consultation and advice to customers.

Leave us a message

loading...