Strategy vs. Tactics in Coding Standards

I'm starting a new job on March 7. As I wrapped up my time with the company where I've spent the past 3 years, I spent some time thinking about the decisions and responsibilities that I was given, and that I took on, while there. One of the reasons I was hired was to bring to the development team my more formal education and professional experience as a software developer. And one of the responsibilities I was allowed was to lead regular discussions with the other developers. The goal of these discussions was to help our team to become more professional in the way we developed software. Of course it was only a matter of time before someone on the team brought up coding standards.

I've had enough experience with coding standards to have developed some skepticism to the way that they are typically applied. It sounds good, in theory. Bring some consistency, order, and predictability to the source code produced by the group. But in my experience, the practice rarely delivers on the promise. It's easy to start a fight on this topic, of course. It tends to be a "religious" topic in that people have strong and entrenched opinions, and are rarely shaken from them regardless of argument. This is unfortunate, because I think there is a way to make them work. But it requires thinking about coding standards in a different kind of way.

The challenge of establishing standards, and the reason standards tend to be so fractious, is that "what works" must necessarily vary depending on the case. But very rarely does an organization who establishes coding standards allow for much variance in response to new problems or process friction. To figure out why this is, and how we can deliver on some of the promise of standards without resorting to brainwashing, let's take a closer look at the types coding standards we see in the wild.

In my experience, coding standards tend to fall into one of two broad categories. There are strategic coding standards, which are general and outcome-oriented. And there are tactical coding standards, which are specific and mechanics-oriented.

I'll address the latter first, as these are the kinds of standards that tend to start religious wars. Here are some examples of tactical coding standards:

• All method headers must include a description, pre-conditions, side-effects, argument descriptions, and return value description.
• Use C#'s "var" keyword only for variables of anonymous data types.
• Place each method argument on its own line.

At this point you're probably at least nodding your head in recognition. Maybe some of you are nodding in satisfied approval, while others are holding back an outburst of disgust. When most people hear the words "coding standards", the tactical ones are the ones they think of. And these often evoke strong emotional responses. Their most common adherents tend to be managers or project leads, and often regular developers who've been around the block a few times.

The reason people want tactical coding standards is simple. They bring a modicum of consistency to a wild and woolly world. You often can't trust that the guy writing code in the next cube can code his way out of a paper bag. So when you have to take over his code after he's gone it's nice to know that, at the very least, he followed the standards. If all else fails, there is one thing that will provide sure footing as you plumb the dangerous depths of their code.

I understand this, and I sympathize. But at the same time, I chafe under these standards. They feel like micromanagement to me. It makes me feel like my coworkers don't trust me to do the thing that I was hired to do. There are organizations where this can't be taken for granted. But my own personal response to those environments is to leave them. I want to work with people I can trust at this level, and that can trust me the same.

It's not all bad for tactical standards, and we'll circle back in a bit. But for now let's look at some examples of strategic coding standards.

• Write informative class headers.
• Endeavor to keep methods to less than 25 lines in length.
• Use whitespace and indenting to identify related code.

Strategic coding standards are broad. They do not tell the developer exactly what to write. Rather they set an expectation of the kind of code that should be written, and leave it to the developer as to how exactly that kind of code should be created. In my experience, these are the kinds of standards that are okay to mandate and enforce from a management perspective. Evoke the general feel of the code you want your team to produce, and then let them use their skill, experience, and professionalism to decide how to make it happen.

You can probably tell that in general I feel a lot better about this type of standard than the other. For one, they stay out of your way on a minute-to-minute basis. They're also far easier to get people to agree upon. Rather than being a cynical defensive measure against bad code, they empower the developer while fostering good coding habits.

Now having said all that, I do think there is a place for tactical standards. One big reason that I named these categories as I did is because I think that the role of establishing each type of standard can map to the organization similarly to how the roles map in the military, from which these terms are taken. Strategic standards can be mandated by leadership without stifling the developers. While the particular tactics can be determined by the people "on the ground".

There are many cases where tactical coding standards are beneficial. But it almost always serves the organization better to let the developers establish and enforce them. Take a team with multiple people all sharing equally in ownership of a codebase, each working from day to day on code written by the others. Imagine further that the code is sensitive in some way that can't abide regression bugs or the like. Maybe there is also a huge amount of code, or a large number of coders.

In these types of situations, it's crucial that the developers be able to pick up a strange piece of code and get a quick picture of what's going on. And to be able to modify the code without introducing a foreign-looking island of code to trip up the next guy. To do this, the developers have to be comfortable with the low-level style aspects of the code, both to read and to write. The best hope a team has of developing this comfort is to, as a self-directed group, come to agreement on common-denominator style standards over time and through shared experience.

There is a balance to be struck here. We want to ensure quality output from our teams, but we don't want to turn our developers into code-generators that don't take responsibility for their own work product. I think this balance is best struck by the proper application of each type of coding standard, in the proper context. If leaders can establish strategic standards that express high-level goals for clean code and understandable designs, then they can empower their teams to find solutions to the lower-granularity challenges such as understanding each other, and reducing the friction involved in cooperation on a shared codebase. This is strategy and tactics in practice, and at its best.

What is a Senior Programmer?

My friend and co-worker Nate recently wrote about some hurdles he has encountered in pursuing his professional ambitions as a software developer. I know what he's going through because I entered both my internship and my first post-college job with tragic misconceptions (non-conceptions really, in the case of my internship) as to how my career would develop.

My first mistake was that, as I began my internship, I had no idea how my career would progress, how it should progress, or how active a participant I would be in whatever progression did occur. I knew that I enjoyed twiddling around with code, and that I seemed to have more of a natural talent for it than most of my classmates. And I figured that if I was going to make a career out of anything, it should be something that I did at least passingly well, and that I enjoyed.

As I entered my first post-college job, I had decided I most definitely did not want to become a manager. I enjoyed programming too much to give it up, for one thing. Further, managers had so far stood mostly as obstacles to my involvement in interesting work, and as incriminating figures more prepared to remonstrate me for my professional flaws rather than empower me to better myself as a programmer. So I wanted nothing to do with that. Instead I set a near-term goal of becoming a "senior developer", at which point I would re-evaluate my career trajectory and adjust course if necessary.

An important question in gauging the advancement of your career as a programmer is to ask what exactly it means to be a senior programmer. I have come to see this title as being tied to the professional respect that one has accumulated in a programming career. A senior programmer is not someone who has served a certain amount of time "in the trenches". Nor is it even someone with a broad experience base.

No, I think there is something a bit more intangible, that identifies someone deserving of the "senior developer" title. Something less measurable. Something that is probably sensed, but not necessarily explicable by those with less experience. But something that would be conspicuous by its absence.

As I see it, what distinguishes someone deserving of the "senior developer" title is a sense of stability. A senior developer is someone who can stand in the middle of the chaos that arises in a project, and exert a calming influence on the people and efforts swirling around him. A senior developer is an anchor to which a project can be tied to keep it from drifting into dangerous waters. He is a sounding board against which claims will ring true or false and goals will ring possible or impossible. He is the steady hand, not necessarily on the rudder of your project's ship, but wherever that hand is needed most. And he is a strong voice that reliably calls out your bearing relative to your destination.

Of course, these metaphors sound a bit grandiose. But the general picture I think is accurate. A senior developer is someone that you put on a project to ensure there's some measure of certainty in the mix. It doesn't mean your project is guaranteed to succeed. But it should mean that you can sleep a little easier knowing that where you think the project is, is where it really is. And that if it's not where it needs to be, that there is someone involved who has a decent idea of how to get it there.

Naturally, these things do come with time and experience. So what I said earlier isn't completely true, in that a senior developer is someone with tenure and experience. However, these are necessary, but not sufficient conditions. Not everyone with 20 years of experience on 5 platforms and 15 languages qualifies. And not everyone with 5 years of experience on 1 platform and 2 languages doesn't qualify. Rather, if you show that you can learn from experiences both positive and negative, port technical and non-technical knowledge from one domain to another, and educate, inspire, or empower colleagues and junior developers.... Then you are showing yourself to have what it takes.

If you're like me, and Nate, you don't feel that you're there yet, but you hope one day to proudly contribute this kind of value. Don't lose hope. Every new experience, technical and non-technical, is a growth opportunity. But it is important to broaden your horizons in both of those respects. If you hope to educate, inspire, and empower others, you must first learn to do so for yourself. And if there's one thing I've learned, it's that you can't do that if you feel stagnant. In that case, your first responsibility to yourself is to educate your boss of the professional value you could offer with a little broader exposure. And if that doesn't work, address the issue yourself, dedicating a bit of time outside work. If you can find them, working together with some like-minded friends or co-workers can be very encouraging, like what we have done with our "book club". Remember, nothing changes if things just stay the same.

Where will your programming job be in 7 years?

There's been a lot of noise recently about the future of programming, as a profession. Okay, let's be honest, people have been talking about the imminent programming crash for a long time. But they didn't know what they were talking about. When I graduated college a few years back, we were warned that many of us would not find jobs, but this fear turned out to be overblown.

But now the noise is coming from some different directions. It's not analysts, or people who've been layed off, or the people who got screwed in the "dot.com bust". Though to be fair, the analysts are still saying it, louder than ever. But it's also now coming from the people who hire programmers. And unfortunately, if you are a programmer, those are the people you care about. So, what's different this time? Why don't companies need programmers anymore?

Well, they do need programmers. But they need programmers who can do more than just program. So odds are good that if your job title is "programmer", or "programming" constitutes 90% or better of your responsibilities on the job, they're looking at you like day-old tuna salad.

From the ComputerWorld article:

"It's not that you don't need technical skills, but there's much more of a need for the business skills, the more rounded skills"

"Crap," you say to yourself. "I hate business stuff." Or maybe you're saying "Crap. Why didn't I go for that business minor or second major back in school?" Easy, cougar. Don't get too worked up yet. Let's look at the context of this statement. We already know who's saying it: "business people". People working in IT in companies throughout the nation. Not software companies. Not consulting companies. Just regular companies. This is crucial information. It means the positions we are talking about are mostly going to be be "business programming" jobs.

Now we have a few more questions. Where are the jobs going? Why did I put quotes around "business programming"? And why are these jobs going away for real this time?

First answer: they're going to go to people with Associate degrees, and people who are self-taught, and consultants. Some to high-quality on-shore resources, but an awful lot to people who speak Hindi or Urdu (or Chinese, or Korean). Wages and education requirements will be cut for in-house employees, and others jobs are going to consultants. Offshore in most cases.

Next... The reason I put quotes around "business programming" is to distinguish these jobs from other types of programming positions. If you are a "business programmer", you're part of what is currently a pretty huge job market. You're part of a population that does a lot of work for a lot of companies, but is often looked at as an unfortunate necessity by other people at these companies. "Business programming" is the type of programming for which, in the past, a company who sells shoes, would hire some people on full-time and in-house to do. It's order processing, financial reporting, CRM, network management, database scripting, and so on and so forth. And for a long time, management types have had an uneasy feeling that they were getting kind of a raw deal on these guys. And I hate to break it to any business programmers out there.... but they were right.

According to the Occupational Outlook Handbook entry for computer programmers, there are very specific and very real reasons that programming jobs are being phased out.

"Sophisticated computer software now has the capability to write basic code, eliminating the need for many programmers to do this routine work. The consolidation and centralization of systems and applications, developments in packaged software, advances in programming languages and tools, and the growing ability of users to design, write, and implement more of their own programs mean that more of the programming functions can be transferred from programmers to other types of information workers, such as computer software engineers.

Another factor limiting growth in employment is the outsourcing of these jobs to other countries. Computer programmers can perform their job function from anywhere in the world and can digitally transmit their programs to any location via e-mail. Programmers are at a much higher risk of having their jobs outsourced abroad than are workers involved in more complex and sophisticated information technology functions, such as software engineering, because computer programming has become an international language, requiring little localized or specialized knowledge. Additionally, the work of computer programmers can be routinized, once knowledge of a particular programming language is mastered."

I would add to this list that "business programming" is almost inherently redundant. Every company out there that employs in-house developers is reinventing the wheel. 99% of the problems their programmers are solving have been solved by thousands of other programmers at other companies around the country. When I look at it that way, it feels like such a tremendous waste of money and time. These programmers could be working on real problems like true AI, building Skynet, or bringing about the rise of the machines and their subsequent domination over the human race.

So essentially, the big reason is that there is finally a way for a company to separate their technical needs from their business needs. Packaged software has finally come to a point where it solves the general problems, while still providing a minimum amount of flexibility necessary to handle a company's critical peculiarities. When they have a need that isn't fulfilled by some packaged solution out there, contracting resources have become plenteous and cheap enough to fill that need. The company can move the business knowledge into more generic manager roles that are more useful to the company. (Roles with better pay, and job titles such as "software engineer" and "system analyst", and "project manager".) And the technical knowledge can be moved mostly out of the company into a "unpluggable" resource that they only need to pay as long as the work is actually being performed.

So, what's a programmer to do?

Well, first of all, stop being just a programmer. Don't be a code monkey. Yes, the under-appreciated coder-geeks of the world have "owned" that pejorative term. But in the eyes of corporate America, the words "code monkey" are always preceded by the words "just a". Code monkeys abound. They are replaceable. If you don't evolve (pun intended) you're going to end up obsolete when your company finds an offshore contractor that doesn't suck. (Yes, they do exist!)

One way you can evolve is by taking the advice of all the articles and reports I've linked to in this post. You can take courses, get certifications, etc., and become a "software engineer" or a "system analyst" or a "project manager". The numbers show there are plenty of companies out there that will be willing to pay you to do this as long as you don't suck at it. (And some that will even if you do suck. But I strongly advise against sucking.)

Many programmers go this route at some point. And there's no shame in it, if you can let go of coding every day (or at all) as part of your job and not hate yourself for it. I think I might go that route one day, but I'm not ready for it yet. For one thing I don't feel my experience base is either broad or deep enough to be as effective as I would want to be. But also, there are just too many cool languages and libraries out there. Too many programs that haven't been written yet. Too many problems that haven't been solved.

So what is there for me, and those like me? Those who don't want to give up programming as the core of our job, but don't want to end up teaching programming to high school kids by day while we sate our code-lust at night in thankless open source efforts? (No not all open source is thankless. But there are a lot of projects that go nowhere and just end up abandoned.)

Two answers:

1. Consulting. Not everyone is willing to send the work around the world, dealing with language barriers, time-zone difficulties, and security uncertainties, to get it done. There's a definite place in the market for on-shore, face-to-face consulting. This spot is getting tighter though, so you had better make sure you're a top-shelf product.
2. Software companies. The companies that sell the software that's putting code monkeys out of jobs are still raking it in. And they're actually solving new problems, building new technologies, etc. All the exciting stuff I dream of working on as I churn out yet another database script for a client.

These are your new targets. The sooner you make the jump the better. Not only will you be trading up, as far as job satisfaction (and probably pay), but you'll also be contributing your own small part to the further expansion of software technology. Both by actually working on it, and by condemning the tremendously redundant field of "business programming" to the death it has deserved for so long. You'll probably still have to learn that business and management stuff, but you can also probably avoid it taking over your job.