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.
Editorial Note: I originally wrote this post for the SubMain blog. You can check out the original here, at their site. While you’re there, check out GhostDoc, which can automatically generate help files for you.
If you spend enough years writing software, sooner or later, your chosen vocation will force you into reverse engineering. Some weird API method with an inscrutable name will stymie you. And you’ll have to plug in random inputs and examine the outputs to figure out what it does.
Clearly, this wastes your time. Even if you enjoy the detective work, you can’t argue that an employer or client would view this as efficient. Library and API code should not require you to launch a mystery investigation to determine what it does.
Instead, such code should come with appropriate documentation. This documentation should move your focus from wondering what the code does to contemplating how best to leverage it. It should make your life easier.
But what constitutes appropriate documentation? What particular characteristics does it have? In this post, I’d like to lay out some elements of helpful code documentation. Read More
Editorial Note: I originally wrote this post for the Monitis blog. You can check out the original here, at their site. While you’re there, have a look at the application monitoring options you can take advantage of.
First of all, make sure that you use StringBuilder when concatenating strings. You see, the “+” operator — just kidding. I mean, that’s not bad advice. Rather, I’m kidding in that I just don’t want to offer this style of tip today.
Often, advice about application performance comes at you with the staccato of rapid fire tips. “37 Ways to Shave Nanoseconds off of Your Overnight ETL Process.” I exaggerate for comedic effect with that title, perhaps. But the point remains. Authors serve up advice for optimization with many tips that matter only inside of tight loops. And it’s hard to keep all of those in your head.
I’d like to take a different tack here today and offer fewer suggestions in the hope that they’ll stick with you. But I differentiate my message in another crucial way as well. I want to offer performance tips for .NET programming that will also help you write clean, readable code.
All too often, these concepts stand in opposition to one another. Performance tips often demand changes that produce the desired effect while making the code harder to read. This phenomenon gives rise to the iconic wisdom that “premature optimization is the root of all evil.” Implementing them might bring relatively insignificant marginal gains in performance while creating confusing, hard-to-read code.
But it strikes me that readable and performant sometimes overlap. And, since tips for that serve two purposes, they are definitely worth filing away.
Before I get down to the brass tacks of how to do some interesting stuff, I’m going to spin a tale of woe. Well, I might have phrased that a little strongly. Call it a tale of corporate drudgery.
In any case, many years ago I worked briefly in a little department, at a little company that seemed to be a corporate drudgery factory. Oh, the place and people weren’t terrible. But the work consisted of, well, drudgery. We ‘consulted’ in the sense that we cranked out software for other companies, for pay. Our software plumbed the lines of business between client CRMs and ERPs or whatever. We would write the software, then finish the software, then hand the software over, source code and all.
Naturally, commenting our code and compliance with the coding standard attained crucial importance. Why? Well, no practical reason. It was just that clients would see this code. So it needed to look professional. Or something. Didn’t matter what the comments said. Didn’t matter if the standard made sense. Compliance earned you a gold star and a move onto the next project.
As I surveyed the scene surrounding me, I observed a mountain of vacuous comments and dirty, but uniform code.
My Complex Relationship with Code Comments
My brief stay with (and departure from) this organization coincided with my growing awareness of the Software Craftsmanship movement. Even as they copy and pasted their way toward deadlines and wrote comments announcing that while(x < 6) would proceed while x was less than 6, I became interested in the idea of self-documenting code.
Up to that point, I had diligently commented each method, file, and type I encountered. In this regard, I looked out for fellow and future programmers. But after one too many occasions of watching my own comments turn into lies when someone changed the code without changing the comments, I gave up. I stopped commenting my code, focusing entirely on extractions, refactoring, and making my code as legible as possible.
I achieved an equilibrium of sorts. In this fashion, I did less work and stopped seeing my comments become nasty little fibs. But a single, non-subtle flaw remained in this absolutist approach. What about documentation of a public (or internal) API?
Naturally, I tried to apply the craftsmanship-oriented reasoning unilaterally. Just make the public API so discoverable as to render the issue moot. But that never totally satisfied me because I still liked my handy help screens and Intellisense info when consuming others’ code.
And so I came to view XML doc comments on public methods as an exception. These, after all, did not represent “comments.” They came packaged with your deliverables as your product. And I remain comfortable with that take today.
In professional contexts, I think that the word “standard” has two distinct flavors. So when we talk about a “team standard” or a “coding standard,” the waters muddy a bit. In this post, I’m going to make the case for a team standard. But before I do, I think it important to discuss these flavors that I mention. And keep in mind that we’re not talking dictionary definition as much as the feelings that the word evokes.
First, consider standard as “common.” To understand what I mean, let’s talk cars. If you go to buy a car, you can have an automatic transmission or a standard transmission. Standard represents a weird naming choice for this distinction since (1) automatic transmissions dominate (at least in the US) and (2) “manual” or “stick-shift” offer much better descriptions. But it’s called “standard” because of historical context. Once upon a time, automatic was a new sort of upgrade, so the existing, default option became boringly known as “standard.”
In contrast, consider standard as “discerning.” Most commonly you hear this in the context of having standards. If some leering, creepy person suggested you go out on a date to a fast food restaurant, you might rejoin with, “ugh, no, I have standards.”
Now, take these common contexts for the word to the software team room. When someone proposes coding standards, the two flavors make themselves plain in the team members’ reactions. Some like the idea, and think, “it’s important to have standards and take pride in our work.” Others hear, “check your creativity at the gate, because around here we write standard, default code.”
What I Mean by Standard
Now that I’ve drawn the appropriate distinction, I feel it appropriate to make my case. When I talk about the importance of a standard, I speak with the second flavor of the word in mind. I speak about the team looking at its code with a discerning attitude. Not just any code can make it in here — we have standards.
These can take somewhat fluid forms, and I don’t mean to be prescriptive. The sorts of standards that I like to see apply to design principles as much as possible and to cosmetic concerns only when they have to.
For example, “all non-GUI code should be test driven” and “methods with more than 20 lines should require a conversation to justify them” represent the sort of standards I like my teams to have. They say, “we believe in TDD” and “we view long methods as code smells,” respectively. In a way, they represent the coding ethos of the group.
On the other side of the fence lie prescriptions like, “all class fields shall be prepended with underscores” and “all methods shall be camel case.” I consider such concerns cosmetic, since they concern appearance and not design or runtime behavior. Cosmetic concerns are not important… unless they are. If the team struggles to read code and becomes confused because of inconsistency, then such concerns become important. If the occasional quirk presents no serious readability issues, then prescriptive declarations about it stifle more than they help.
Having standards for your team’s work product does not mean mandating total homogeneity.