DaedTech

Stories about Software

Sep
29

By

Chess TDD 48: Getting Started with Castling

Category: You Asked For It Tags: , , , , |

Back in the saddle and making these regularly once again.  In this episode, I start implementing castling.  This proves to be something of a challenge because I’d gotten into such a routine of adding acceptance tests for the Pawn feature and changing mainly the Board class.  Here I’m in a different set of acceptance tests and changing a different set of production code, so it took a bit to get my bearings.  Castling, like en passant, is also a non-trivial edge case that deviates a fair bit from standard piece movement.

What I accomplish in this clip:

  • Implemented castling to the short side of the board.
  • Implemented castling to the far side of the board (though I think I got the move wrong).

Here are some lessons to take away:

  • It’s a big help if you keep a nice, large surface area of testable code in your code base.  This lets you dig in with the granularity of your choosing for writing tests.
  • You need to carve out time to keep your code clean and do boy scout refactorings.  If anyone is telling you not to do this, that’s a serious organization/group smell.  You need to keep the code reasonably clean to sustain the pace at which you deliver value.
  • As you have a larger and increasingly complex code base, “do the simplest thing that will work” becomes an increasingly tall order.  With more tests that can go red, it gets harder and harder to do trivial things that satisfy all tests.
  • It’s important to audit your tests continually to make sure they continue to add value.

Sep
27

By

Avoiding the Dreaded Experience Tuples

Category: The Life of a Programmer Tags: | 12 Comments

I went to monster.com today and discovered that it still exists.  I’m actually kind of chuckling as I type this, and for that I apologize.  I realize that I’m in a pretty fortunate position not to have to be looking for work in such a way, so I’m not trying to make light of anyone’s situation.  But, in all seriousness, if you’re a non-entry level developer and you’re perusing monster, you have much better options (and if you honestly think you don’t, drop me an email, and I’ll see what I can do to help you find work).

Anyway, I wasn’t looking at monster in the hopes of landing a Junior Full Stack Ninja role, but because of a reader question.  Here’s the question.

How do you successfully compete against experience while interviewing? Do you leverage education? Open Source involvement? What should I fall back on?

I recently tried to make the argument that experience may not be a good thing and rather an open mind is better since experience tends to bring along bad habits that are not correctable where an open mind is willing to adapt to the corporate policies/procedures that a company has. Needless to say, I wasn’t very successful and honestly it probably came off like I was being a smart ass. I just can’t stand people wanting 3-5 years of experience. Like 2.5 is not good enough, it really needs to be 3? If 2.5 is fine, why not 2? Why is that .5 so much greater than just 2? It seriously feels like I am 6 again telling everyone that I am 6 and 4 months old, not 6. I am so much older than 6…

(By the way, you can submit questions on the sidebar at the right, under “Ask Erik,” if you want to get my take on something — and please do!)

First of all, I love the way this is phrased.  It’s poignant as it makes the frustration palpable, and it aptly exposes the absurdity of this candidate-employer matching approach.  But beyond just liking the way this conundrum is described, I think it raises an important topic.

The reason this question prompted me to head over to monster.com is because I formed a hypothesis.  I hypothesized that if I went to a generic job site and did a search for a programmer gig, the very first one I found would consist of boilerplate (years, tech) tuples.  I’ll call these “experience tuples.”  Monster has top mindshare in my head under “generic job site,” so I cross my fingers that it still existed, typed in the URL, and was pleasantly surprised.  I then typed, “C# Software Engineer” and clicked on the very first link.  Here’s what I saw.

Read More

Sep
25

By

Chess TDD 47: En Passant in the Other Direction

Category: You Asked For It Tags: , , , , |

It’s been a while since the last episode, due mainly to my wedding and honeymoon, but here I am, back in action.  For some, there were a few audio glitches in the recording of this episode.  I did just upgrade to Windows 10, so maybe my version of Camtasia isn’t playing nicely with or something.  My apologies, but I think it’s just minorly annoying and not a problem for understanding.  This episode is pretty straightforward.  I performed a little bit of cleanup on naming and then finished up by implementing en passant in the other direction.

What I accomplish in this clip:

  • Fixed some naming hangover from last episode.
  • Got en passant working in the other direction: white pieces capturing black pieces.

Here are some lessons to take away:

  • I’ve said it more times than I can count, but naming is so important.  Spend extra time with it.  Revisit it.  Make your methods as readable as progress.
  • When you’re test driving (or, at least, making sure to write a lot of automated tests), the kinds of refactorings that a lot of people promise to do ‘later’ and never do turn out to be a lot easier.  You’re much more likely to deliver on promises to clean up later.
  • If you have logic that you want to test and it’s 2, 3 or more calls deep in private methods, this is often a sign that you should extract a class and have two different public surface areas to test.
  • If you can delete a line of code in your code base and no test goes red, you’ve failed at some point in your test driving.  Either you’ve deleted a test that should exist or else you’ve added functionality to prod without having a failing test that requires that addition.  It happens to the best of us, but understand that it’s a problem and either delete that code or add a test that makes it necessary.

Sep
23

By

Modularity on My Honeymoon

Category: The Life of a Programmer Tags: | 2 Comments

If you hadn’t noticed, I’ve been gone for the last couple of weeks.  I got married and went on a honeymoon and left the blog on auto-pilot, with scheduled cross posts of things I’d written for other blogs.  I figured this was better than providing no content and hopefully the posts and social media announcements synced up closely enough that I didn’t look ridiculous.

During the trip, I didn’t think a whole lot about software, per se, but I gave occasional thought to what I might say upon my return.  I think really good bloggers make cool segues out of trips and experiences.  You know, like  “I was gazing up at the Eiffel Tower and I couldn’t help but think of Liskov’s Substitution Principle.”  I’m not that good, so I didn’t come up with anything like that.  I was in France and Monte Carlo, and I ate a lot of cheese, saw a lot of sites, drank a lot of wine and spent a lot of time reading.  None of that reminded me of code or software, really.

An Idiot (Me) Abroad

In fact, the only technical lessons I could relate were birthed from my own stupidity.  I brought my Mac Book pro along, but, incredibly, managed to forget its charger.  Upon arrival at our hotel in Paris, jet lagged, I dug the laptop out of the bag to charge and discovered that this would be quite impossible.  Suddenly, the Mac’s 90% charge was an ominous harbinger of computing scarcity.  I’d have to ration, what, like 3 or 4 hours of latpop usage for the entire trip? Read More

Sep
20

By

Managing to Avoid Cobras

Category: The Life of a Programmer |

Incentives are a funny thing.  Done well, they can spur your team to productivity and career-advancing, win-win situations.  Done not so well, they can create havoc.

As this point, I could offer up a dry explanation of the “law of unintended consequences,” but I’ll let Wikipedia do that.  Instead, I’ll tell you a quick story about something that came to be known as the “cobra effect.”  Snakes are clearly more interesting than laws.

In colonial India, the Brits in charge didn’t like the large number of venomous snakes that they encountered. So they did something that seems imminently sensible at first blush: they offered a bounty to locals for dead cobras.  At first, things went well.  Locals killed corbras, locals got their rewards, and the governing Brits saw a dip in cobra encounters.  But then the cobra encounters started to creep back up, even as the number of dead cobras turned in continued to climb.

Turns out, the locals had started breeding cobras specifically to turn them in and collect the reward.  Once the British government caught wind of this, they (predictably) terminated the reward program, and the erstwhile cobra breeders simply released the now-useless snakes. So the net result of this program turned out to be an increase in the cobras.  Ouch.

Beware of Cobras

When I tell you to beware of cobras, I’m not talking about looking out for snakes (though, clearly, if you live in an area with cobras, you should probably look out for them).  I’m talking about keeping an eye out for bad incentives.  For instance, if you’re managing a software department, do a thought exercise as to what might happen if you agreed to pay testers $5 extra for each bug they found and developers $5 extra for each bug they fixed.  At first, that probably seems like a good way to get them all to work a little extra and produce good results.  But, channeling the cobra example, can you spot what might go wrong?

This is the beginning of a post that I wrote for the NDepend blog.  Click here to read the rest of it.

 

« Older Posts
Newer Posts »