Stories about Software


Are Your Meetings Worth Attending?

“Remember, kids, your projects are due a week from Monday, so you’d better get started if you haven’t already.”

This imminently relatable phrase, or one like it, is probably the first exposure to nagging that most of us had outside of the home. Oh sure, Mom and Dad had nagged us for years to clean our rooms, say please and thank you, and wear jackets. But our teachers introduced us to business nagging. I’m using the term “business nagging” to characterize the general practice of nudging people to do things for common professional effort.


If you fast forward to your adult life, business nagging morphs into things like, “don’t forget to sign off on your hours in payroll,” and, “everyone must update their email signatures to use the company’s official font by next week.” The subject matter becomes more adult in nature, but the tone and implications do not. When you hear these phrases, you’re transported back in time to junior high, when you needed to rely on a teacher to help prevent your general incompetence at life from creating unfavorable situations for yourself.

There’s a subtle problem with business nagging growing up alongside of us. As children, we actually are pretty incompetent at looking out for own interests. Left to our own devices, we’ll procrastinate on the school project and then pull an all-nighter ahead of turning in something that earns us a C minus. But as we grow to adulthood, we learn these lessons firsthand and wind up being generally decent at looking out for ourselves. We tend not to need nagging nearly as often to do things that will benefit us, so being nagged to do things that will benefit us winds up becoming largely superfluous.

And that leaves the most common form of business nagging: being nagged to do things that offer no obvious benefit to the recipient of the nagging. Signing off on your hours in payroll doesn’t benefit you directly (except, perhaps, by removing the artificial threat not to compensate you for the work you’ve done). Changing your email signature doesn’t benefit you directly. According to someone with some degree of power somewhere in the organization, you doing these things will benefit the company. Presumably, if the company benefits, so do you, somehow. But there is as much vagueness in that equation as there are “somes” in the previous sentence. From where you’re sitting, it’s just bureaucratic procedure having only one tangible benefit—getting the administrator of the business nagging to go away and leave you alone.

This was a post I originally wrote for Infragistics. Click here to read the rest.


ChessTDD 35: Acceptance Tests for Knight Movement

Things are really starting to flow with the acceptance tests now. In this episode, not only did I mercifully not uncover any important bugs, but I defined knight movement in acceptance tests in a way that I feel pretty good about. I’m learning as I go about using SpecFlow, which is cool, and as the cherry on the sundae, I actually got episode length back under control with a 17 minute episode.


What I accomplish in this clip:

  • Fixed the poor naming I left off with last time.
  • Wrote acceptance tests for the knight’s movement.

Here are some lessons to take away:

  • Naming is so, so, so important.  It may seem like a trivial thing, but leaving a method about chess piece movement where “origin” and “destination” were reversed would, sooner or later, cause someone a serious headache.  It would also probably make them hate me when they looked at the history.  Make sure your names are good.
  • You have to do a fair bit of fumbling when you’re figuring out a new tool/tech/framework on the fly.  Stick to your principles and be sensitive to the idea that there’s probably a better way to do a lot of the things that you’re trying to do.  Ask people, and read a lot if you can.
  • There’s a lot of out of the box stuff that comes when I make a SpecFlow feature, but I just get rid of it.  For me, it’s helpful to eliminate everything that I’m not using so as not to be confused about what’s mandatory and what isn’t and also not to be confused later about what functionality I’m even using.
  • An interesting tradeoff emerges in my use of SpecFlow.  Duplication is, by and large, pretty bad in a code base.  But, in the case of visualization, showing the chess board for each individual acceptance test may be helpful in that it makes it crystal clear what’s going on in each test.  There are probably various strategies to try optimizing for minimized duplication and maximized visualization simultaneously, but it’s worth bearing in mind that everything in software development is a matter of tradeoffs and it’s best to be deliberate about whatever choice you make.


Low Cost Legacy Help

If I think back a number of years, I can remember sitting in a software shop and feeling like the iconic stranger in a strange land.  I valued writing clean code, practicing TDD, refactoring away from procedural, legacy cruft, and generally improving my craft.  This was not otherwise common.  There were architects in that place that were long on seniority and opinions but short on chops, and they really, really liked them some global state.  And class size?  The bigger the better.

I seriously felt like I was in some kind of weird, parallel reality.  We’d have lunch & learns and watch things like Uncle Bob videos or talks from Channel 9 or whatever, and I would leave thinking that some kind of brainwashing A/B trick had resulted in me watching a different video from everyone else.  It was discouraging.  

I made progress in fits and starts.  I’d refactor a method here, kill a singleton there, inject an interface here, delete some dead code there.  But, then I’d go for a long weekend trip and come back to find a new singleton with more global state than its recently deceased cousin.  It was two steps forward and one step backward on a good week.  Like wading upstream against a raging, waist-high river, it was slow, exhausting progress.

I remember thinking that it’d be great if I could plead with one of the speakers in the video to come in and talk to people in this shop.  Maybe if one of the folks from the video was there, speaking live to them, something would finally get through.  Or maybe the video hero would take pity on me and offer me a job.  But I also knew that this was a pipe dream because hiring a consultant like this would be wildly expensive.

A lot of years have passed since then, and my life has evolved considerably.  I make most of my living doing coaching and helping improve software development craft.  Other parts of my living come from making videos and writing books about the same.  And through it all, I’ve never forgotten that feeling — a feeling with which, I’d imagine, many reading are familiar.

I’ve recently piloted with great success a new coaching model.  Think of the Chess TDD series, but imagine that instead of building a (non-trivial) toy application, I was doing a codecast in which I refactored some nasty legacy method in your code base to make it testable and narrated over it, explaining what I was doing and why.  The beauty of this approach is that we can pick some problems that are representative of your code base, and you can refer to the videos for context when doing refactorings from then forward.

This has proven to be a good option for small shops because it’s low touch.  It doesn’t require much if any synchrony, and, perhaps more importantly, it doesn’t require flights, hotels, a multi-day engagement fee with opportunity cost, or advanced schedule clearing.  It’s really just a matter of billable hours, which winds up being something like three hours per hour of video footage.  And five-ten hours of video footage is a surprisingly large, helpful amount.

Think of it this way.  It’s like someone recording a Pluralsight course wherein they refactor your code.  So if you’re reading this, and you think your code base and/or team could use a kick in the pants, feel free to reach out, even if it seems like a long shot.  There’s no charge for us to talk and even for me to sign an NDA and take a look at your code.  You can tell your boss or whomever that I really just kind of jump into problem solving mode and only start to think about billing arrangements once I’m convinced that I can contribute meaningful value to you.

Because, honestly, it’s also a lot of fun.  :)


Appeasers, Crusaders, and Why Meetings Usually Suck

I think this is about to get weird, but bear with me, if you’re so inclined.  This is going to be another one of those posts in which I try to explain myself by way of a vague apology for my abnormality.  But maybe if enough of you are similarly abnormal, it’ll gain a little steam.  I’d like to talk today about my odd, intuitive approach to disagreements over the rightness of opinions or beliefs. (For epistemological purposes, consider anything that you’d think of as a “fact” to fall into the belief category.)

So, let’s say that Alice and Bob are sitting on a bench, and Alice proclaims that blue is the best color.  Bob might agree that Alice is right.  He might disagree with her on the basis that red is actually the best color, or he might disagree with her on the basis that this is a purely subjective consideration, so the idea of a “best” color is absurd.  In short, Bob thinks that Alice is wrong.

Perception of rightness affects different people differently, it appears to me.  There are a lot of people out there for whom rightness is extremely important, and the idea that someone might be wrong and not corrected offends them deeply (as shown here, ably, by xkcd).  I am not one of those people.  I might be baited into the occasional back and forth online (or in any asynchronous form) when someone directly accuses me of wrongness, but that’s pretty much it.  I almost never seek out people to correct general wrongness, and I certainly don’t do it in person — with the exception of very close friends and family, and only then in casual conversation.  By and large, other people being wrong about things doesn’t matter to me.  If I’m sitting in the bar, having a beer, and some drunk is yammering political opinions that get increasingly moronic with each boilermaker, I have an innate gift for quietly enjoying the free spectacle.

But there are situations that require cooperation, often professional ones.  Working with another person, there may be some debate or disagreement over the course of action that ought to be taken, and, in such cases, the moment happens when I’m convinced that someone is wrong, and they’re equally convinced that I’m wrong.  The first thing that I do is evaluate whether or not the wrongness negatively impacts me.  If not…meh, whatever. Read More


A New Kind of Blog

This comic from The Oatmeal is one of my favorite pieces of internet.  That’s true for a variety of reasons, but one of them is how he explains that it’s much easier to be told what to write than to be given the instructions, “write about whatever you want.”  He’s not alone in feeling this way.  Strangely, when it comes to writing, I find that restrictions on the content are oddly liberating.  And I have a hypothesis that this doesn’t only apply to Matthew Inman and me.  It probably applies to a lot of you as well.

This is one of the reasons that I think it’s so hard for new bloggers to get started.  You build up a bunch of momentum, picking a host, a platform, a theme, etc.  You procrastinate by doing these things, subconsciously terrified of the moment where you sit down, stretch, and say, “everything done — now to produce a little content!”  Because then the next thing to happen is a quick moment of anti-climatic dread as you realize you have no idea what to say.  Self doubt creeps in, and you start thinking things like, “what could I say that others haven’t already said better than I could?”  It’d almost be better if you had a time crunch and content restrictions/parameters.


Well, that’s exactly what I’m proposing. Read More


ChessTDD 34: Specflow for Pawn Movement

This episode featured a return to progress toward shippable features.  I refactored the first feature that I’d started to use the new, idiomatic Specflow approach.  This resulted in it making the most sense to have this be the feature for pawn movement and thus progress toward implementing the pawn’s movement as well as shaking out more bugs.

What I accomplish in this clip:

  • Refactored the old Specflow feature to look like the newer one.
  • Deleted a bunch of now-dead code and made the Specflow backing class a lot more concise.
  • Implemented HasMoved from the board perspective.
  • Fixed a bug in GetMovesFrom

Here are some lessons to take away:

  • I made a mistake in deleting dead code when I had a red test.  Part of the reason I got this wrong was that the IDE crashed and I sort of lost my place, but there’s a lesson here.  It’s easy to get distracted when you see dead/unused code (or something else similar) and go off on a tangent.  That’s fine, but be sure you’re green when you go off on tangents.
  • Thinking ahead about how they code you’re writing will be useful elsewhere is a double edged sword.  It’s good because it can lead to more efficiency and less future rework, but it’s also the first step along the path to gold-plating.  There’s no exact how-to I can offer for walking this line, but just being aware of it will help.
  • When things go wrong with acceptance tests, which are coarser-grained, integration tests, your next stop in figuring out the problem will generally be to move down the test pyramid and look for more details in your unit tests.  Unit tests are going to exercise the code in more granular fashion, so you should get good insights there.
  • I recommend favoring domain-specific, communicative exceptions coming out of your code rather than allowing boilerplate exceptions to be thrown to your callers.  If someone using your code gets an array index out of bounds exception or a null reference exception, they can’t be sure whether you screwed up in your code or whether they screwed up calling your code.  If you, instead, throw “BadBoardCoordinateException”, it’ll be very clear to callers of your method that you’ve anticipated what’s going on right now, and that they’re doing something wrong.
  • Deferred execution with Linq is really powerful and allows you to do some great things, but it also leads to subtle bugs.  I’ve written about this in the past, even.  Be careful and always remember to make sure you’re aware of whether or not you’re enumerating the sequence when you run into stuff like this.


Are You Changing the Rules of the Road?

Happy Friday, all.  A while back, I announced some changes to the blog, including a partnership with Infragistics, who sponsors me.  Part of my arrangement with them and with a few other outfits (stay tuned for those announcements) is that I now write blog posts for them.  Between writing posts for this blog, writing posts for those blogs, and now writing a book, I’m doing a lot of writing.  So instead of writing Friday’s post late Thursday evening, I’m going to do some work on my book instead and link you to one of my Infragistics posts.

The title is, “Are You Changing the Rules of the Road?”  Please go check it out.  Because they didn’t initially have my headshot and bio, it’s posted under the account “DevToolsGuy,” but it’s clearly me, right down to one of Amanda’s signature drawings there in the post.  I may do this here and there going forward to free up a bit of my time to work on the book.  But wherever the posts reside, they’re still me, and they’re still me writing for the same audience that I always do.






8 Career Tips That Don’t Require Competence

A few weeks ago, I posted my spin on the MacLeod Hierarchy and promised to follow up with a post addressing the kind of vacuous, non-strategic career advice that is often given in Buzzfeed sorts of formats.  I started, then, to type this post, but realized that a bridge of sorts was needed.  So I indulged a digression wherein I described the corporate idealist that typically solicits and follows this sort of advice.  (That post also became pretty popular, with a number of requests to pre-order my upcoming book, which you can now check out here on leanpub).  Now, having described the corporate idealist and his willingness to overwork in exchange for useless status tokens, I can go on to be clearer about why so much of the career advice that you tend to hear is so, well, frankly, dumb.

I started to write this just from anecdotal experience, including various comical, ham-fisted self promotion attempts that I’ve watched over the years.  But then I thought it’d make more sense to go out, do some research, and synthesize my experience with actual advice offered in these “Linkbait for Idealist” articles.  This is a list of the ones that I read as reference material.  (As an aside, I also stumbled across a few that offered fairly sensible, decent advice for how to advance meaningfully, so it is actually possible to find advice that isn’t silly)


Read More


I Have a New Book

It’s been an interesting week with respect to my philosophy about the future of labor for knowledge workers. This post about corporate idealists and seniority got relatively popular and attracted around 10,000 readers. If you’re a regular follower of this blog, you know that one was just the latest in a series of a few posts I’ve done on this topic and you probably also know that these are coming from my work on a book. But this understandably wasn’t immediately clear to new readers, and so I got a smattering of inquiries as to where the book was for sale or whether it could be pre-ordered. I invited those folks to stay tuned or sign up for my mailing list, but alas I had nothing to offer.

A few days later, I noticed the hashtag #talkpay on Twitter, promoting the controversial but clearly forward-thinking idea that making salary information confidential is problematic in a variety of ways (specifically, in this case, that it facilitates gender and racial pay inequality). I’m not a salaried employee, so I couldn’t offer information about my salary, but it did prompt me to tweet this:

As you can see, this was a pretty popular sentiment, which jived with the reception my post about salary negotiation hacks received. There appears to be a great deal of appetite for reconsidering the knowledge worker’s relationship with the corporate structure.

To this end, I decided over the weekend to put an end to my large-batch approach to writing this book and include anyone that wants to come along for the ride right from the outset. I wrote my initial introduction to the book and published it on Leanpub (most of the material I’d been gathering is still scattered in a large document on my personal google drive). Beware, there’s not much there, but that will change. In the coming months, I’ll be writing to the book almost the way I would to a second blog. So, stay tuned.

The infant book is now officially on Leanpub and officially for sale. I have absolutely no idea what I’m doing when it comes to marketing or setting price, so please bear with me. It’s doubly confusing because Leanpub offers a lot of different options for differentiated pricing. The minimum price for the book is $1 and the suggested price is $4.99. The suggested price was just the default, and the minimum price is 1 cent more than the default for no particular reason other than selling things for 99 cents seems somehow hokey to me. I considered making the initial minimum price free, since there’s not much book there, but data about whether people would pay for the thing or not is a lot more meaningful if people have to pay for it. If I made it free, I might get a lot of spurious information (lessons learned from Lean Startup and 4 Hour Work Week).


Now, here’s the nuance. You can get the book for free. I wanted to be sure to offer that option to people that are regular fans and followers of the blog and will provide feedback as I write it along with support and shares. So I created a coupon that I’ll send out to the DaedTech mailing list as well as anyone who signs up for it from here forward. Also, I’m not going to lie. If you just email me, I’ll send you the coupon too, but I’d prefer to do it through the mailing list. For those of you on the mailing list, look for the coupon email in the next few days.

As I said, I have no idea what I’m doing when it comes to marketing, so I hope this makes sense and isn’t crazy. I wanted to err on the side of giving too much away if I erred in any direction. Weird as it sounds to say, I’ve never regretted erring on the side of giving away content. People seem to live life petrified that they’ll give something away for free when they could have wrung a few dollars out of it, but for me, the goodwill and engagement created by giving away content has paid far more dividends down the line than a few dollars.

So I cordially invite you to join me on this book journey. And, naturally, I invite you to invite as many of your friends and colleagues as you please! :) I’m excited and looking forward to this, and fascinated to see how it goes.


ChessTDD 33: Scenario Housekeeping

Having fixed some bugs in the last few episodes, it would have been nice to make some progress with functionality, but there was housekeeping to be done first. I did some refactoring for board setup using the tables, compacting methods, and made the implementation of the moves checker correct. This will put me on much more sustainable ground as I go forward implementing game scenarios.

What I accomplish in this clip:

  • Fixed incorrect/incomplete implementation of checking for moves.
  • Refactored BuildBoardFromTable method.

Here are some lessons to take away:

  • When you make a test go red, don’t then take the opportunity to do a refactoring — even a small or inconsequential one.  Go back to green and then do it.  You want to be taking actions in batches as small as possible.  Doing 2 things at once is a recipe for confusing cause and effect.
  • I’m not sure how others feel about this, but I did something in this video that I do from time to time.  I had a green test covering an implementation that was too permissive — too easy to get right.  So I altered the test temporarily to green in a situation where it should have been red.  I then modified the production code to get the expected red, then reverted the test and verified that it was green.  This is the equivalent of writing another test, framed in the negative, and then taking that test from red to green.  I shortcutted that process because I didn’t want that other test to be left around when I was done.
  • I consider baking the names of types into class, method, and variable names to be a bad practice.  You might change the type they use and forget to update the name accordingly, and you’re also leaking implementation details.
  • A refactoring may well never seem perfect to you.  If you make sure it seems cleaner or better as compared to where it was, that’s progress.  Stick a pin it it and make a note to revisit later.  Not only is this good for avoiding diminishing returns on a given day’s effort, but it also removes you from the problem so that you can better assess readability later.

Acknowledgements | Contact | About | Social Media