Stories about Software


Chess TDD 61: Testing an Actual Game

Editorial Note: I was featured on another podcast this week, this one hosted by Pete Shearer.  Click here to give it a listen.  It mostly centers around the expert beginner concept and what it means in the software world.  I had fun recording it, so hopefully you’ll have fun listening.

This post is one where, in earnest, I start testing an actual game.  I don’t get as far as I might like, but the concept is there.  By the end of the episode, I have acceptance tests covering all initial white moves and positions, so that’s a good start.  And, with the test constructs I created, it won’t take long to be able to say the same about the black pieces.

I also learned that building out all moves for an entire chess game would be quite an intense task if done manually.  So, I’d be faced with the choice between recording a lot of grunt work and implementing a sophisticated game parsing scheme, which I’d now consider out of scope.  As a result, I’ll probably try to pick some other, representative scenarios and go through those so that we can wrap the series.

What I accomplish in this clip:

  • Get re-situated after a hiatus and clean up/reorganize old cards.
  • A few odds and ends, and laying the groundwork for the broader acceptance testing.

Here are some lessons to take away:

  • No matter where they occur, try to avoid doing redundant things when you’re programming.
  • If, during the course of your work, you ever find yourself bored or on “auto-pilot,” that’s a smell.  You’re probably working harder instead of smarter.  When you find yourself bored, ask yourself how you might automated or abstract what you’re doing.
  • When you’re writing acceptance tests, it’s important to keep them readable by humans.
  • A seldom-considered benefit to pairing or having someone review your coding is that you’ll be less inclined to do a lot of laborious, obtuse work.
  • Asserting things in control flow scopes can be a problem — if you’re at iteration 6 out of 8 in a while loop when things fail, it’s pretty hard to tell that when you’re running the whole test suite.


How to Get a Raise

I’ve been slipping a little in my quest to answer reader questions of late, so I thought I’d course correct.  The question revolved around the notion of how to get a raise.  Actually, that was the question in its entirety.

How do I get a raise?

A deceptively simple question that one.  So much so, in fact, that I’m going to be kind of roundabout in my response.

Paying the Iron Price for Cable

Assuming that you’re one of the millions of people that pay for cable television, you fork over your $100 per month and get the full rainbow of channels.  You probably don’t think a whole lot about the $100 that you’re spending each month because it’s the closest a recurring cost can come to being a sunk cost.  You’re used to cable and you’re used to your wallet being $100 lighter, so continuing to have cable for $100 per month is not a decision that you consciously make.  In fact, to do something different would be the conscious decision.

Bearing this in mind, do you ever think to yourself, “you know, I love how they’ve finally stopped killing off erstwhile protagonists on Game of Thrones, so I think I’ll call the cable company up and offer to pay $103 per month, starting in the next fiscal year?”  Of course you don’t — that’s ridiculous.

But, let’s consider a slightly modified version of that scenario.  Let’s say that the cable company called you and said, “we’re raising the price of your Premium Thingamajig Package to $103 a month, so if you want to continue to see what Sansa, Arya and the gang are up to, you’re going to have to pay up.”  You probably go on to Facebook, post a cathartic rant, and then pay the extra money.  Because, while that’s inconvenient, what would be more inconvenient is to have to spend time figuring out how to compensate and vary your routine.  You could go with Dish or AT&T or whatever, but that’s probably too much effort to expend over a 3% increase.  If it were a 10% or 15% increase, on the other hand, it might be time to comparison shop.


Employment as a Zero Sum Game

As you’ve no doubt surmised, I offered this silly parallel to help you empathize with your employer’s position.  You’re the cable company in their lives — non-critical, largely taken for granted, and prominent enough to be missed as long as the price isn’t too high.  And, like your relationship with your cable company, your relationship with your employer is, talk of family and work-life balance notwithstanding, a zero sum game.  The more money you have, the less they have, and vice-versa.

Read More


Chess TDD 60: Wrapping Initial Development

There is a bit of symmetry to this episode that may interest only me.  It is the 600th post to be published on the blog, and it is the 60th post in the ChessTDD series.  I wouldn’t have thought the series accounted for 10% of my posts, but, there it is.  Believe it or not, this post is about wrapping initial development on the project.  In other words, I have no more functionality cards to implement.  From here on in, it’s going to be constructing test scenarios and addressing any shortcomings that they reveal.  (Not ideal, but it’s hard to get user feedback in a one person show with no prod environment)

I also, after some time away have a bit more clarity on what I want to do with this going forward, so you’ll hear some mention of this as I narrate the videos.  I’m looking to wrap the youtube series itself and then to use that as the centerpiece and starting point of a video-product that I have in mind.  Stay tuned for updates down the line.

What I accomplish in this clip:

  • Get re-situated after a hiatus and clean up/reorganize old cards.
  • A few odds and ends, and laying the groundwork for the broader acceptance testing.

Here are some lessons to take away:

  • An interesting definition of done when it comes to software work goes beyond completeness and even shipping.  You can say that something is done when it has demonstrably added value somehow (it has sold or helped product revenue or something)
  • Writing unit tests is a great way to turn hypotheses that you have about the code base into productive regression test suite.  It’s also a great way to confirm or refut your understanding of the code.
  • It bears repeating over and over, but avoid programming by coincidence.  If you don’t understand why a change to your code had the effect that it had, stop what you’re doing and develop that understanding.  You cannot afford to have magic and mystery in your code.
  • There shouldn’t be any line of code in your code base that you can delete without a test turning red.  This isn’t about TDD or about code coverage — it’s about the more general idea that you should be able to justify and express the necessity of every line of code in the code base.  If removing code doesn’t break anything, then remove the code!



The Gravitational Force of Wage Labor

Editorial Note:  Thanks, to all for the heavy response rate to my last post!  I’m glad there’s interest in Expert Beginner T-Shirts and I’m really excited by all of the people interested in exploring new ways to do free agency.  In fact, I was sort of blown away by the number of responses, which far exceeded my expectations.  I’ll be figuring out next steps before too long, so stay tuned!

Today I’m going to do something that’s a first, but probably not a last, since it makes sense.  I’m going to regard a comment as a reader question (since the comment came in the form of a question).  This one also has a much shorter cycle time than average because the substance of it was something I was literally just having a conversation about in the last couple of days.  I have opinions on the matter, and fresh ones at that.  Here is the comment/question.

Ever dealt with this situation? You’re brought on to deliver with clear expectations on both sides. You deliver. They like you. They want you to stick around. Then your job slowly morphs into “do whatever needs to be done as an all purpose IT generalist.” You came on to port an old app to a newer platform, and next thing you know they are asking you to write custom sql data transforms to onboard new customers. To top it off, you want to be a “team player”, so you agree to take on one of these tasks. How would you respectfully and professionally address this situation? It’s basically the “this is not what I signed up for” argument.

First of all, have I ever dealt with this situation?  Oh, my, yes, and from a lot of different angles.  And, I’m not just being grandiose — there are a lot of different angles of approach once you think about the nuanced relationships between standard companies, software companies, software consultancies, and free agents.

But despite the myriad situations in which this arises, there is really only a singular cause.  And it’s because the closest thing to a law of nature in the corporate world is what I’ll call the “Gravitational Force of Wage Labor.”  But let me resurrect my consulting taxonomy before I get to that.

Consultants and the Enterprise

There are, in my estimation, three main ways for non-salaried people from outside of an organization to act, temporarily as part of that organization.  (Someone please chime in if you think of another one that is fundamentally different — I have not given this exhaustive thought to make sure nothing is omitted.)  I say “act as part of the organization” to discount superficial interactions and put us squarely into the realm of consulting.  These are as follows.

  • Staff augmentation
  • Project specialist
  • Retainer consulting

(As a quick aside, please note that I would consider wholesale project/product delivery to be a vendor relationship — if you’re a ‘consultant’ that sits at home every day for six months, building a piece of software that you then hand off to the client, you are acting as a vendor rather than as a part of that organization.)

Perhaps not surprisingly, these line up pretty well with my taxonomy from the earlier post, when expectations align and all is right with the world.

  • Software pros, when onsite, offer staff augmentation.
  • Specialists, when onsite, serve as project specialists for the duration of some project.
  • True consultants, when onsite, do so in a retainer consulting capacity.

This should line up with common experience.  Software pros sign on through agencies to work at the company with its staff developers or else they get para-dropped in by ‘consulting’ firms in the same capacity.  The only way you know whether they’re staff or not is the color of their badge.  Specialists come in to help with the CRM installation and then toddle on off to the next CRM installation elsewhere when this one finishes.  And, consultants come in to offer advice during the course of a particular situation or phase of a project.


At least, that’s the theory.

The Gravitational Force of Wage Labor

But have you ever noticed something odd?  Have you ever noticed that you come in as a consultant or specialist, and are regarded as a high priced, hot shot commodity?  And then, you just kind of run out of steam somehow, without realizing it, six months in?  When you started, the CTO was interested in your strategic expertise, but now some project manager is chiding you for not reporting your status with a little more flair during a daily standup?  (I’m asking the royal you, since the question submitter presumably has, per the premise of the question.)

Read More


Gathering the Confidence to Leave Your Job

It’s Thursday night, and I’m holed up in a hotel in Lansing, Michigan.  I figure there’s never been a better time to answer a reader question.  This one is about how to summon the confidence to leave your job.

The question is actually a rather lengthy one, and here is a redacted/obfuscated version of it (removing anything that could be identifying).

I have had my developer position for several years. I’ve been promoted, but I’m still not a senior developer. I have become extremely “silo-ed” in my skills, because those are the types of projects I’ve been assigned.  I read your statement that salaried employment is a bad economical decision for developers. The developer should be making $50 or maybe a bit more at $60. I get paid {a good bit less} an hour for 40 hours a week of expected work.  I feel the need to grow my abilities.

I watched your video on Pluralsight on how to propose practices. My manager bought into some,  but most of my coworkers are ignoring the new stuff.  My place of employment fires developers once they are called as a references for checking if they ever worked there.

I need a goal, something I can achieve to give me confidence to start pursuing other options. Something that gets me into a situation where people seek me for relevant development.

There are actually several questions and issues here to unpack, so I’ll tackle them in order of complexity.

Pay is Relative

First of all, when I talk about developers making 50 per hour/100K or 60 per hour/120K, I’m mainly catering to myself and ease of math.  100K is a nice, round figure, and 120K makes monthly finace (10K) easy to calculate.  These figures were slightly high in the Chicago-land area as of 2+ years ago, which was when I was last seriously hiring and evaluating pay there.

But, beyond that, pay varies a lot by geographic location, industry, filing status (nonprofit, for profit), etc.  If you salaried a developer working in San Francisco at 150K per year, he would probably need to move into a homeless shelter.  (I kid, but only slightly).  Pay that same wage to someone in central Kentucky and “should we install a second hot tub on the master bedroom deck” becomes a topic of debate around the marble dinner table.

All that being said, your wage was fairly low for a developer anywhere of your experience.  But don’t base your assessment of how low on my blog and what I know (I don’t pay much attention these days).  Base instead off of researching in your region.

We’ll Fire You for Looking…

Okay, this is where I offer the IANAL (I am not a lawyer) caveat.  This is based on my experience doing management consulting and working as a manager, much of which happened in at will states (this can vary by state and certainly by country).

If you’re a company, terminating employees is like playing Minesweeper, except instead of bombs, there are lawsuits.  You’re clicking along gleefully when suddenly, one day, BLAMMO!  Wrongful termination!  So you learn your lesson and you start looking at all of those numbers really carefully and insulating yourself against potential problems.

Minesweeper Read More