Stories about Software


Sources of Inspiration

A while back, I got a reader question that was extremely short and sweet.  It was, in essence, asking me about success that I’ve enjoyed.  Given that this is a subjective concern and that I wince at the prospect of self promotion (I’ve learned this is probably a matter of being an introvert), I’d rather deflect this and talk about things that have inspired me over the last number of years.  This post is about those sources of inspiration.

First, though, the reader question.

How did you get to where you are?

To answer that properly would require a good bit of introspection of the form, “where, exactly, do I think that I am.”  I’m not really prepared for that, not because I don’t like introspection, but because I’m pretty content with my life in these terms at the moment.  My life suits me well, but I wouldn’t presume to suggest that it suits others well.  This presents me with the challenge of answering the question, but without the typical, self-help template of “here’s what I did as a blueprint, and you can do it too!”

I think what would go better than that is to talk about some serious sources of inspiration over the last several years.  That way, rather than focusing on what particular things I’ve done, I can focus instead on what I’ve been trying to do and why.  This, I feel, will leave you in a better position to evaluate whether you want to understand “where” I am and whether you also want to be there.

For you mythology buffs, this is Sysiphus actually making it to the top of the hill.

In terms of format, I’m going to talk about four books that have helped me formulate and refine my more recent approach to life.  Using a good bit of wisdom from these books, I’ve gone from working as a software engineer to being an independent technologist.  My work is asynchronous, entirely remote (with some travel), and generally varied in nature.  This makes for a fun mix and it lets me live a pretty low key, mobile life.  All of this is no accident.

So, without further ado, here are the books that have contributed significantly to inspiring my choices.  I’ll describe them briefly, and then the impact they had upon my life.  Keep in mind that these are not in chronological order of my reading of them, but rather in the order I think makes sense to introduce them if you’re looking to pursue a similar path to mine.

Read More


How to De-Brilliant Your Code

Three weeks, three reader questions.  I daresay that I’m on a roll.  This week’s question asks about what I’ll refer to as “how to de-brilliant your code.”  It was a response to this post, in which I offered the idea of a distinction between maintainable code and common code.  The lead-in premise was that of supposedly “brilliant” code, which was code that was written by an ostensible genius and that no one but said genius could understand.  (My argument was/is that this is usually just bad code written by a self-important expert beginner).

The question is, as follows, verbatim.

In your opinion, what is the best approach to identify que “brilliant” ones with hard code, to later work on turn brilliant to common?

Would be code review the best? Pair programming (seniors could felt challenged…)?

Now, please forgive me if I get this wrong, but because of the use of “que” where an English speaker might say “which”, I’m going to infer that the question submitter speaks Spanish as a first language.  I believe the question is asking after the best way to identify and remediate pockets of ‘brilliant’ code.  But, because of the ambiguity of “ones” it could also be asking about identifying humans that tend to write ‘brilliant’.  Because of this, I’ll just go ahead and address both.

Einstein Thinking Public Static Void

Find the Brilliant Code

First up is identifying brilliant code, which shouldn’t be terribly hard.  You could gather a quorum of your team together and see if there are pockets of code that no one really understands, or else you could remove the anchoring bias of being in a group by having everyone assess the code independently.  In either case, a bunch of “uh, I don’t get it” probably indicates ‘brilliant’ code.  The group aspect of this also serves (probably) to prevent against an individual not understanding simply by virtue of being too much of a language novice (“what’s that ++ after the i variable,” for instance, indicates the problem is with the beholder rather than the original developer).

But, even better, ask people to take turns explaining what methods do.  If people flounder or if they disagree, then they obviously don’t get it, self-reporting notwithstanding.  And having team members not understanding pockets of code is an ipso facto problem.

An interesting side note at this point is whether this illegible code is “brilliant” or “utter spaghetti” is going to depend a lot more on knowledge of who wrote it than anything else.  “Oh, Alice wrote that — it’s probably just too sophisticated for our dull brains.  Oh, wait, you were reading the wrong commit, and it’s actually Bob’s code?  Bob’s an idiot — that’s just bad code.”

De-Brilliant The Codebase

Having identified the target code for de-brillianting, flag it somewhere for refactoring: Jira, TFS, that spreadsheet your team uses, whatever.  Just make a note and queue it as work — don’t just dive in and start mucking around in production code, unless that’s a team norm and you have heavy test coverage.  Absent these things, you’re creating risk without buy in.

Leave these things in the backlog for prioritization on the “eventually” pile, but with one caveat.  If you need to be touching that code for some other reason, employ the boy-scout rule and de-brilliant it, as long as you’re already in there.  First, though, put some characterization tests around it, so that you have a chance to know if you’re breaking anything.  Then, do what you need to and make the code easy to read; when you’re done, the same, “tell me what this does” should be easy to answer for your teammates.

De-brillianting the codebase is something that you’ll have to chip away at over the course of time.

De-Brilliant The Humans

I would include a blurb on how to find the humans, but that should be pretty straightforward — find the brilliant code and look at the commit history.  You might even be able to tell simply from behavior.  People that talk about using 4 design patterns on a feature or cramming 12 statements into a loop condition are prime candidates.

The trick isn’t in finding these folks, but in convincing them to stop it.  And that is both simple to understand and hard to do.

During my undergrad CS major many years ago, I took an intro course in C++.  At one point, we had to do a series of pretty mundane, review exercises that would be graded automatically by a program (easy things like “write a for loop”).  Not exactly the stuff dreams are made of, so some people got creative.  One kid removed literally every piece of white space from his program, and another made some kind of art with indentations.  When people are bored, they seek clever things to do, and the result is ‘brilliant’ code.

The key to de-brillianting thus lies in presenting them with the right challenge, often via constraints or restrictions of some kind.  They do it to themselves otherwise — “I’ll write this feature without using the if keyword anywhere!”

The Right Motivation

Like I said, a simple solution does not necessarily imply an easy solution.  How does one challenge others into writing the kind of straightforward code that is readable and maintainable?

Code review/pairing presents a possible solution.  Given the earlier, “can others articulate what this does” metric, the team can challenge programmer-Einstein to channel that towering intellect toward this purpose.  That may work for some, but other brilliant programmers might not consider that to be a worthwhile or interesting challenge.

In that case, automated feedback through static analysis might do the trick.  FXCop, NDepend, SonarQube, and others can be installed and configured to steer things in the general direction of readability.  Writing code that complies with all warning thresholds of such tools actually presents quite a challenge, since so much of programming is about trade-offs.  Now, a sufficiently determined clever coder could still invent ways to write hard-to-read code, but that would be a much more difficult task when he’d get slapped by the tool for chaining 20 Linq statements onto a single line or whatever.

Of course, probably the best solution is to work with the sort of people who recognize that demonstrating their cleverness takes a backseat to being a professional.  They can do that in their spare time.

If you have a question you’d like to hear my opinion on, please feel free to submit.


Surviving The Dreaded Company Framework

This week, I’m making it two in a row with a reader question.  Today’s question is about an internal company framework and how to survive it.  Well, it’s actually about how to work effectively with it, but the options there are sort of limited to “get in there and fix it yourself” and “other” when the first option is not valid (which it often is not).

How does one work effectively with a medium to large sized company-internal framework? The framework has one or two killer features, but overall is poorly abstracted and [released] with little QA.

I think the best way for me to tackle this question is first to complain a little about Comcast, my erstwhile cable company, and then come around to the point.  They recently explained, in response to one of my occasional Comcast rage-tweets, “[The] promotional pricing is intended to offer you the services at a reduced rate, in the hopes that you enjoy them enough to keep them.”

This is, in a nutshell, the Comcast business model — it was an honest, and forthright tweet (unlike the nature of the business model itself).  What Comcast does is reminiscent of what grocery stores do when they flood the local shopping magazines with coupons: differential pricing.  Differential pricing is a tactic where in you charge different rates for the same product to different customers, generally on the basis of charging more when people are non-price averse.

The trouble is that outright differential pricing is usually illegal, so companies have to get creative.  With the grocery store, you can pay full price if you’re generally too busy for coupons, but if you load up with serious couponing, you can get that same grocery trip for half the price or less.  They can’t say, “you look rich so that’ll be $10.00 instead of $5.00” but they can make the thing $10.00 and serially discount it to $5.00 for people willing to jump through hoops.

Comcast does this same thing, but in a sneakier way.  They advertise “promotions” and “bundles” to such an extent that these appear to be the normal prices for things, which encourages people to sign up.  Then, after some time you’ll never keep track of and never be reminded of, the “regular” price kicks in.  For me, recently, this turned out to be the comical price of $139 per month for 24 Mbps of internet.


When you call them to ask why your most recent bill was for $10,928 instead of $59.99, they’ll say “oh noes, too bad, it looks like your bundle expired!”  And this is where things take a turn for the farcical.  You can ask them for another bundle, and they’ll offer to knock your monthly bill down to $10,925.  If you want to secure the real savings, you have to pretend for a while to be canceling your service, get transferred over to the “retentions department,” and then and only then will you be offered to have your service returned to a price that isn’t absolutely insane.  I suspect that Comcast makes a lot of hey on the month or two that you get billed before you call up and do that again, because the ‘normal’ prices are equal parts prohibitive and laughable.

Why am I mentioning all this?  Well, it’s because when the time came for my most recent annual Comcast gouge ‘n’ threaten, things got a little philosophical.  I wound up on the phone with an agent to whom I confessed I was sick of this stupid charade.  Instead of arguing with me, he said something along the lines of, “yeah, it’s pretty ridiculous.  Before I started working here, I used to hate calling up and threatening them every year, but the thing is, all of the other companies do it too.”  This was either a guy being refreshingly honest, or a really shrewd customer service tactic or, perhaps, both.

But the interesting message came through loud and clear.  In my area, if you want TV and internet, it’s Comcast or it’s AT&T.  And if both of them behave this way, it goes to show you the power of a monopoly (or a nominally competing cartel).  Their motto is, in essence, “Comcast: it’s not like you have a choice.”

Read More


How Do I Find Good Recruiters?

I’ve fallen off my cadence with answering reader questions of late, so I’d like to correct that today.  The question in question is a fairly straight forward one about how to find good recruiters.  This one is actually lifted from a comment some time back that I thought would be more conducive to a post than a comment response.

I would like to ask you how you get to “good” recruiters? My experience with recruiters has been rather negative and I’m wondering if I’m doing something wrong here.

First of all, it’s had to imagine that you’re doing anything wrong.  From the perspective of the job seeker, this is not a difficult transaction.  It’s a lot more likely that the problem lies with the recruiting field in general.

What Makes Them Good?

I’ve had a lot of experience with recruiters, both on the hiring and applicant ends — enough to know well how the game works.  I’ve explained this before, about a year ago.  Short form version is that the typical recruiting firm will take nothing from the applicant, but will take 15 – 20 percent of the first year’s salary from the company that makes the hire.  This cut will be refundable if the applicant leaves within something like six months.  The recruiter’s game is thus to make a match and hope it sticks for 6 months.


Recruiters’ customers are thus hiring companies, and not you.  It’s like Facebook — you’re the product, not the customer.  The majority of recruiters are in the business of selling humans (that happens to be developers) to companies.  The good recruiters are in the business of selling a match to both the human and the company, since this is the best way to build reputation and avoid the six month refund blues.

But most recruiters are not good — they’re shooting for quantity over quality by treating you as the product.

Read More


Chess TDD 62: Finishing Chess TDD

You might not have expected to read this, and I honestly wasn’t really expecting to write it, but here we are.  I’m going to call it and announce that I’m finishing Chess TDD series.  It’s been a lot of fun and gone on for a long time, and I’m not actually done with the codebase (more on that shortly).

My original intention, after finishing the initial implementation with acceptance and unit tests, was to walk through some actual games, by way of “field testing,” so to speak.  I thought this would simulate QA to some extent — at least as well as you can with a one person operation.  And, with this episode, I’ve showed a tiny taste of what that could look like.  And, I’ve realized, I could go on this way, but that would start to get pretty boring.  And, I’ve also realized that it would be irresponsible.

What I mean is that plugging laboriously through every piece on the board after every move would be showing you a “work harder, not smarter” approach that I don’t advocate.  I’d said that I would save ingesting chess games and using algebraic notation for an upcoming product, and that is true — I plan to do that.  But what I shouldn’t be doing in the interim is saving the smart work for the product and treating you to brainless, boring work in the meantime.

So with that in mind, I brought the work I was doing to a graceful close, wrapping up the feature where initial board positioning was shown to work, and using red-green-refactor to do it.

You’ll notice in the video that the Trello board is not empty by a long shot.  There’s a long list of stuff I’d like to tweak and make better as well as peripheral features that I’d like to add.  But, to use this as a metaphor for business, I have a product that (as best I can tell) successfully tells you all moves available to any piece, and that was the original charter.  It’s shippable, and, better yet, it’s covered with a robust test suite that will make it easy to build on.

What should you look for in the product?  Here are some ideas that I have, off the top (and from Trello).

  • A way to overlay algebraic chess notation for acceptance tests.
  • Remove type checking for a polymorphic scheme.
  • Improve the object graph with better responsibilities (e.g. removing En Passant logic from Board)
  • Apply static analysis tooling to address shortcomings in the code.
  • Make sure that piece movement also works properly (currently it probably wouldn’t for castling/en passant).
  • Develop a scheme for ingesting chess games and verifying that our possibilities/play match.

In short, what I have in mind is bringing this application along with the kinds of work I’d advise the teams that I train/coach and assess.  Here’s how to really make this codebase shine.

I have a couple of things to get off my plate before I productize this, but it’s not going to fall off my radar.  Stay tuned!  And, until then, here is the last of the Chess TDD posts in the format you’re accustomed to.

What I accomplish in this clip:

  • Finish the testing of the initial rows on the board.

Here are some lessons to take away:

  • The new C# language features (as of 6) are pretty great for making your code more compact and functional-appearing in nature.
  • Always, always, always make sure that you’re refactoring only when all tests are green.  I’ve experienced the pain of not heeding this advice, and it’s maddening.  This is a “measure twice, cut once” kind of scenario.
  • Clean, consistent abstractions are important for readability.  If you think of them, spend a little extra time to make sure they’re in place.
  • If something goes wrong with the continuous test runner or your test suite in general, pause and fix it when you notice it.  Don’t accept on faith that “everything should be passing.”  Like refactoring when red because “it’s just a trivial change,” this can result in worlds of downstream pain.