Stories about Software


Chess TDD 40: Diagonal Capture for Pawns

This post was the last of a series of 3 I recorded together, so it picks up right on the heels of episode 39 from a flow perspective.  I initially tied up loose ends from the previous episode and then got the pawn’s diagonal capture in place, at least for the white pawns (acceptance tests for black pawns won’t go well right now).  Fits and starts, but real progress nonetheless.

What I accomplish in this clip:

  • Finished the TDD implementation for IsCaptureAllowed
  • Implemented IsNonCaptureAllowed
  • Finally gave pawn diagonal capture ability

Here are some lessons to take away:

  • Always look to refactor test code when it comes to readability and eliminating duplication.  These refactorings are not just for production code!
  • There’s a sizable contingent of people that don’t like seeing the Assert call factored out of unit tests.  Clearly a matter of personal preference, but you may get pushback in a shared code base.
  • In methods, preserve a consistent level of abstraction.  If you have complex two part conditional, don’t factor out one part and leave the other part — make them both conceptually similar.
  • Clean, readable code will look at least vaguely familiar to domain experts, even if they aren’t programmers.  They should see/read concepts that are familiar.
  • Keeping the lines of code low in a class isn’t a first class or all-encompassing goal.  A class can get ugly by having too many methods, even if all of those methods are small.


Office Politics 101 for Recovering Idealists

In writing my book, I find that I wind up with these thoughts, paragraphs and mini-essays that may or may not find their way into the book. I’m adding to Leanpub sequentially, but writing relevant things as they occur to me, so there are bits floating around, waiting to have a home. I’m going to appropriate one of those bits today, as a blog post, since this is on the fringe of “maybe it will fit, maybe not.”

You almost certainly play the game of office politics, whether you do so deliberately or not. If there are more than two people involved in something, there are politics, so if you work for a company or project of more than two people, you’re involved. Saying, “I stay out of office politics and just work,” is like saying, “I don’t vote or follow elections, so I’m not really involved in laws and policies.” You can certainly opt out of participation in the process, but you can’t opt out of the consequences of that process.

Becoming good at office politics is a messy endeavor, involving a lot of intuition, trial and error, and real life, career consequences. It’s also unpleasant for a lot of people. But if you take away one piece of advice on how to navigate the minefield, let it be this: stop giving away information for free because information is leverage. Read More


Chess TDD 39: Dipping a Toe into Complex Piece Movement

What I accomplish in this clip:

  • Finished implementing the bishop acceptance tests.
  • Introduced the concept of “capture move” and “non-capture move” to piece movement.
  • Made some good headway on the pawn’s diagonal capture capability.

Here are some lessons to take away:

  • I’ve mentioned this before in the negative a few times, but I’ll phrase it in the positive.  If you’re going to do refactorings, even trivial ones like deleting a dead method, do it with a green test suite.
  • Writing acceptance or integration tests, whether using them to drive design or not, tends to give you a good lesson in patterns of things that can go wrong.  The specific example I’m referring to here is how I noticed that movement for the black pieces from higher numbered rows to lowered number ones tended to be a problem across pieces.
  • Even if you’re not thrilled with a design, you can be productive and get things done with it when your test coverage is good since you won’t be afraid to change it later.  This helps prevent “coders’ block” or “paralysis by analysis.”
  • When you’re reasoning about implementation, allow yourself to stub out helper methods or methods on other objects that will ‘magically’ do what you want.  E.g. if I were writing a “CookDinner” method, I might just declare “TurnOnStove()” and stub it out, to be implemented later.  This practice of defining what before how can help you get toward the single responsibility principle.
  • I won’t belabor the metaphor of tech debt, but having a really high degree of test coverage and a lot of small, modular methods in the code base lets you live with tech debt a little more easily in the short term.  With a lot of crufty code around the problematic code, you’ll never want to touch anything when it comes time to pay it off.  With lots of coverage and good code elsewhere, getting rid of the tech debt at a time that suits you is easier.


Let’s Make Better Code Metrics

A few months back, I wrote a post about changes to my site and work.  Today, I have another announcement in that same vein:  I’ve recently partnered with NDepend to help start and create content for their blog.  If you go there now, you can see the maiden post which announces the release of the newest version of NDepend (not written by me, personally, if you were wondering, though some of mine will follow).

What is NDepend?

In the broadest terms, NDepend is a static analysis tool.  More specifically and colloquially, you might think of NDepend as Jiminy Cricket, if Pinocchio were a software developer or architect.  It’s extremely helpful for visualizing the dependencies and properties of your code base (e.g. complexity, coupling, etc), which will give you a leg up on your fellow developers right out of the gate.  It’s also incredibly informative, furnishing you not only with detailed, quantitative metrics about your code, but also indicating where you’re deviating from what is broadly considered to be good programming technique.  And, of course, you can do a great deal of customization, from integrating this feedback into your build to tracking code quality over time to building and defining your own complex, custom rules.

To put it more succinctly, in a world where developers are trying to distinguish themselves in terms of knowledge and chops, NDepend will give you such a huge advantage that it’s probably unfair to everyone that doesn’t have it.  I personally learned a ton about software architecture just from installing, using, and exploring this tool over the course of 5 years or so.  If you want to learn more about NDepend and static analysis in general, check out my Pluralsight course about it that I published in conjunction with the last major version. (If you don’t have a Pluralsight subscription but want to check it out, sign up for my mailing list using the form at the right).

Scientist Read More


It’s a Large Batch Life for Us

It’s a large batch life for us!
‘stead of feedback we just wait!
‘stead of options we trust fate!

— Little Orphan Annie…sort of.

Before I talk about “large batch life,” I’d like to take a moment to share with you a bemused chuckle at really poorly done verbal tribalism.  Rather than try to explain in the general sense, I’ll offer an example: an out of touch father trying to determine if his kids are doing drugs by saying, “so, dudes, are any of your friend-bros on the pot?”  He’s attempting (and failing) to crack their linguistic code to gain credibility. The kids, presumably, have a tribe with its own invisible speakeasy, and Dad is trying to get in.

There are tons of tribes, and you’re a member of many.  When you say, “pull request,” in casual conversation, you’re indicating that you’re part of the tribe that puts open source code on Github.  When you tell people to “put it on my calendar,” you’re indicating that you’re part of office culture. There’s nothing particularly notable or bemusing about that — it’s simply the mechanics of human communication.  Where things start to get awkward is when Dad enters the mix in the form of a recruiter or hard-charging project manager and wants to establish cred in that world without really having any: “Hey dudebros, can I pull request a phone interview with you?”


Read More


ChessTDD 38: Bishop Tests and Being Wrong about Being Wrong

For this episode, I did something a bit different.  I actually recorded the coding for this and then two more episodes on its heels.  If you’re following along on github, you’d notice that I’ve checked in code for episode 40, though I still need to do the audio for those next two episodes.  In this particular episode, I get off to a nice start with testing for bishop and then get a bit derailed.  Luckily (spoiler alert), I get it straightened out in next episode.  And, for all 3 of these, I successfully kept to right around 20 minutes.

What I accomplish in these clips:

  • Implement part of the acceptance tests for bishop.

Here are some lessons to take away:

  • I find a lot of benefit in stripping everything but what I need in default templates I’m provided (e.g. the spec flow feature file, an web.config file, etc).  I prefer to be as deliberate as possible about everything that goes into the software work product.
  • No matter what you’re doing, if you do it brainlessly, it won’t go well.  I avoided copy and paste to avoid brainless mistakes, and just wound up brainlessly typing in the wrong thing by hand.
  • TDD lets you poke at and test the code to see if you can get to green (or red) without fully understanding what you’re doing, but if you do this, make absolutely sure you spend time immediately afterward writing tests or reasoning about the code so that you do understand it.
  • You almost certainly won’t stop yourself from making stupid mistakes, but you can develop techniques for discovering them more quickly and reducing their impact scope.


Delegating is Not Just for Managers

I remember most the tiredness that would come and stick around through the next day. After late nights where the effort had been successful, the tiredness was kind of a companion that had accompanied me through battle. After late nights of futility, it was a taunting adversary that wouldn’t go away. But whatever came, there was always tiredness.

I have a personality quirk that probably explains whatever success I’ve enjoyed as well as my frequent tiredness. I am a relentless DIY-er and inveterate tinkerer. In my life I’ve figured out and become serviceable at things ranging from home improvement to cooking to technology. This relentless quest toward complete understanding back to first principles has given me a lot of knowledge, practice, and drive; staying up late re-assembling a garbage disposal when others might have called a handyman is the sort of behavior that’s helped me advance myself and my career. On a long timeline, I’ll figure the problem out, whatever it is, out of a stubborn refusal to be defeated and/or a desire to know and understand more.


And so, throughout my career, I’ve labored on things long after I should have gone to bed. I’ve gotten 3 hours of sleep because I refused to go to bed before hacking some Linux driver to work with a wireless networking USB dongle that I had. I’ve stayed up late doing passion projects, tracking down bugs, and everything in between. And wheels, oh, how I’ve re-invented them. It’s not so much that I suffered from “Not Invented Here” syndrome, but that I wanted the practice, satisfaction, and knowledge that accompanied doing it myself. I did these things for the same reason that I learned to cook or fix things around the house: I could pay someone else, but why do that when I’m sure I could figure it out myself?

Read More


My Candidate Description

If you’re a regular reader of this blog, I’m treating you to a strange post. Consider this experimental art of a fashion, I suppose. Odd as it sounds, this isn’t addressed to you, though I encourage you to read it, hope that you enjoy it, and suggest that you consider doing a version of it yourself. You’ll see why shortly.

If you’re a recruiter, you’re reading this because I sent you this link in response to an email, a message through social media, a message through SO Careers, or something else similar. Let me first say that I thank you for coming here and taking the time to read this. I mean this sincerely; as a blogger who pays attention to various forms of analytics, I’m aware of how many people drop off from a call to action, so I’ve already lost a good chunk of people to whom this is sent. The fact that you’re here and reading means that you aren’t dialing for dollars in volume the way so many of your colleagues with an “URGENT REQUIREMENT FOR A JAVA DEVELOPER IN TEST” seem to do.

Now, I realize that what I’m doing here may come off as a bit flippant or cocky, but I assure you earnestly that this is NOT my intention. As you are no doubt aware, I receive a nearly endless stream of contacts from people looking for software developers, software architects, dev managers, etc. This post, for me, is mainly about time savings. But it’s also a polite but insistent suggestion that we stop playing by old rules that no longer make sense. Gone are the days of a company putting out a job description and waiting for the “lucky” applicants to prove that they’re good enough. You know it, and I know you know it because I’ve spent a lot of time in your situation over the last few years, desperately trying to hire developers in an economy that saw all promising candidates disappear in the two days between a phone screen and a “let’s bring them in for a chat.” It’s harder for companies to find developers than vice-versa, no matter how many free cans of soda and ping pong tables your clients or you are offering.

So what I’m posting here is my candidate description that will serve as pre-screening for inquiries about my availability for work. Assuming your company or the company on whose behalf you are searching seems like a good match for my description and meets the must-have requirements, I may be amenable to further discussion over the phone. I say may because I’m quite happy with my current work situation and have almost more contract work than I can handle, so I simply don’t have much spare time.

Candidate Description

I am an experienced programmer, software architect, team leader, CIO, coach, and technologist that enjoys working with a wide variety of programming languages, frameworks, and tools. The majority of my recent development experience has focused on the .NET framework, though over the years I have worked with C++, Java, and a number of other languages. Projects range from low-level driver and kernel module programming all the way up to user interface design. Types of applications run the gamut from home automation to rigorous code analysis to line of business applications. My more recent work focuses more heavily on software craftsmanship coaching aimed at developers and IT management consulting aimed at IT managers and other positions at the periphery of software teams.

My passion for working with technology extends beyond the workplace and into my work under the umbrella of my LLC. I do various types of traditional consulting projects, but I also produce software-related content for public consumption. I create developer training videos for Pluralsight aimed at intermediate to advanced programmers. Beyond that, I am also an author and active technical blogger.

Must-Have Requirements for a Candidate Company

  • Must be open to B2B contract work (unless you’re looking for a dev manager or CTO, in which case, I’d prefer a conversation first about why you’re staffing that role and potential alternate solutions)
  • Must be open to considering initial arrangements of less than 40 hours per week.
  • Must actively practice or encourage clean coding practices (CI, TDD, SOLID, continuous refactoring, etc.) or else want to bring me in with a mandate to get your team doing these things.
  • Remote work arrangement possibilities are a non-negotiable necessity for development work, though occasional travel for site visits is fine (for programming, a bit more flexible for coaching).
  • I will not consider W2, exempt arrangement for software development.  Not even for a number that you think will make me swoon as if I’ve been told I’m the prettiest belle at the ball.  Contracting a must.
  • Provided I give reasonable notice, time off or with other clients must not be an issue for you.
  • Position must allow creative control of software work product.
  • For interviews, no brain-teaser-oriented interviews or algorithm-centric interviews (see “The Riddler” and the “Knuth Fanatic” from this excellent video about interviewing anti-patterns).  I strongly prefer code reviews and evaluation of my public code samples and am just not interested in discussing why manhole covers are round or in reliving college coursework from 15 years ago.
  • Regardless of language and framework, access to the latest bits is critical for me.
  • If you’re McDonald’s and you’re hiring me to build you a recipe database, I will sign an NDA agreeing not to distribute your recipe to your competitors.  Anything more strict and/or that restricts my ability to do freelance projects in any way at all is an immediate deal breaker.


  • I enjoy working on .NET technologies and in the connected (mobile or web) spaces.  I’ll happily code away in any language, but C#/.NET is my favorite these days.
  • No expense is spared on software development tools, and I can have my favorite text editors, productivity add-ins, etc.
  • I have the opportunity to contribute to company blog or public thought leadership in general.
  • I’d love working for a developer tools company or one that specializes in software development and surrounding expertise. If there’s developer evangelism in-role, even better.

Thanks Again

If you’re still reading, thanks again for taking the time and paying attention all the way through.  I know this seems strange, but I appreciate you humoring me, and I believe that this will save a lot of time in the long run for me and for you.  As I often tell people that I’m coaching, “it’s almost always better to fail fast and obviously,” so better you shake your head and move on to the next candidate rather than have you, me, and a phone screener all waste time only to have it come out after an hour of conversation that I’m not interested in signing an NDA and starting a W2 gig.

Readers, to address you once again, I suggest you do something like this as well.  Don’t settle; the market is too good.  And don’t let people on the hiring side convince you that you should be lucky to have a job.  I’ve tried hiring people who do what you do, offering generous salaries and a score of 10 or 11 on the Joel Test, and it was really, really hard.  Don’t settle for the first thing that comes along. Make your list, be patient, and be picky.  It will pay off.


Don’t Learn to Code — Learn to Automate

Does anyone remember a few years ago, when the mayor of New York decided to learn to program? It was a heady time, because it wasn’t just him. I remember these surreal commercials where Miami Heat forward Chris Bosh was encouraging children to learn to code for the good of humanity or something. There was this sudden, overwhelming sentiment that humanity should abandon the folly of any non-programming pursuit and learn them some Ruby or whatever. Andy Warhol, were he alive in 2012, no doubt would have said, “in the future, everyone will write code for 15 minutes.”

Jeff Atwood wrote an interesting rebuttal to this zeitgeist, entitled, “Please Don’t Learn to Code.” The covers a good bit of ground and makes some interesting points, but the overarching thesis seems to be, “avoid thinking of writing code as the goal and learn to solve problems.” I think this is an excellent, philosophical point, but I’d like to add a bit of nuance.

I’ve written in the past about how important I think that it is to be a problem solver, to the point where I wrote a post about liking the title “problem solver.” So please don’t think I disagree with his take that a lot of programmers get too hung up with the particulars of code. I don’t — I think that’s a very common issue. But, at the same time, I think the mayor of New York and Chris Bosh and others have a point that Jeff doesn’t really address, per se. Specifically, the world is getting dramatically more technical, which means that a lot of pursuits are being automated out of existence, while other pursuits require an increasing degree of technical savvy. My fiancee, a professional copy editor, is finding aspects of her job to be easier if she knows a bit of HTML and CSS.

So while I wince alongside Jeff at the thought of people randomly learning programming languages because they think it’ll make them rich or because they want to be a person that writes lots of code, I don’t think we can simply say, “stay out unless you’re serious and willing to spend years getting good.” The rapidly evolving technical landscape has created this black hole of technical savvy that’s sucking in even people well past the event horizon.

The advice that I’d offer on this subject creates a pretty fine distinction. I don’t think that everyone needs to learn to code by any stretch. What I think that everyone needs to start learning about and understanding is how to automate. Or, if not how to do it themselves, at least how to recognize things that could be automated and have meaningful discussions about whether the effort is worth it or not. Read More


ChessTDD 37: Cleaning Up and Implementing Rook

Got back in the saddle with this episode, and had a shorter recording that basically went well.  Someone pointed out in the comments that I had reversed king and queen position for the black pieces, so I started off by fixing that, and then moved on to fixing a bug and finally implementing the Rook acceptance tests.  Wrapped it up in relatively short order, too.

What I accomplish in these clips:

  • Fixed my template for the full chess board.
  • Fixed the vertical version of that reverse bug from last time.
  • Implemented rook acceptance tests.

Here are some lessons to take away:

  • It’s important to understand past shortcomings of your code so that you can form good hypotheses about where you might have other potential weak spots.
  • If you’re going to run an experiment on your code, do it from a test that you’re writing instead of through the GUI or the debugger or something.  You’re running the experiment anyway, so you may as well capture the results in the form of an automated regression test.
  • A lack of test coverage for a line of code isn’t a problem in and of itself.  Coverage is a metric and not a goal.  The problem with having code not covered by tests is that there’s nothing to prove that the code was implemented in a thoughtful, deliberate way.  If you don’t have a test expressing what a path through the code is supposed to do, there’s no way to know if you’ve reasoned about that code.
  • Copying, pasting, and adjusting often winds up taking longer than typing by hand.  You spend more time staring dumbly at the screen trying to figure out what’s wrong than it would have taken you to hand type the code you need.

Acknowledgements | Contact | About | Social Media