This week I’m starting the process of engaging more yak-shaving, but I think it’s important yak-shaving. If we’re going to be doing this SpecFlow thing in the series, let’s get it done right. In a post I made last week, Darren Cauthon took the time to put together this gist. I read through it and my eyes bugged out. That kind of visualization is solid gold for this problem space. How powerful is it to be able to show other developers (and hypothetical business stakeholders) these ASCII chess boards and say, “look, this movement works?!” So, I’m asking you to indulge me in the journey to get there.
Here’s what I accomplish in this clip:
Created AsciiBoardBuilder class to take strings like “BQ” and “WP” and turn them into pieces added to a Board instance.
Got half-ish way through implementing that class.
Here are some lessons to take away:
I created something called “AsciiBoardBuilder.” There was a time when I would have immediately thought to have it implement an IBoardBuilder interface, but I’ve gravitated away from this over the years as it tends to lead to unnecessary abstraction at times. We can always do this alter if we need some other means of constructing boards aside from just using the Board class itself.
In case you’ve forgotten, one trick I use is to create the production class in the same file as the test class at first, when convenient. NCrunch runs a little quicker this way and you don’t have to flip back and forth between two files. I leave it in here until it no longer makes sense to, usually (e.g. when some other production class needs to use my new class).
I did something that’s a little more complex than your average TDD scenario, wherein I was modifying two different production classes as I went. This isn’t particularly common and you might not want to do it if you’re new to this or you run into trouble trying it. But if it works for you, there’s no reason not to do this.
If you go look up a solution, such as how to implement a bit of Linq-fu, it’s probably worth writing an extra test or two that you expect to go green just to confirm that you really understand the behavior of the solution that you found.
What I did with factoring out GeneratedBoard may not be to your liking. This has the upside of eliminating duplication but the downside of introducing a bit of indirection. For me, the improvement in how succinct the test cases are is worth it, but you may not agree. This isn’t always an exact science — taste does factor in.
I’m pretty rigid about strongly favoring one assert per test method. Not everyone feels this way, but I felt it worth refactoring to assert only one thing: that the piece is a white bishop. (As opposed to asserting that it’s white and then that it’s a bishop). I suggest that unless there’s really no option but to have multiple asserts, you factor toward one.
I’ve been reading a book called, “The Four Hour Work Week” lately, and the timing is pretty interesting. In the book, Ferris outlines a positively cold-blooded plan to seize control of your life and career using an approach that he calls “Lifestyle Design.” For me, the timing is interesting because “lifestyle design” is a good way to describe the way that I’ve been re-shaping my life over the last several years, thinking in terms of things that I want to be true about my life (e.g. “I should be able to go where I want when I feel like it and work from wherever”) rather than my career (e.g. “I wanna be a SENIOR Architect”). It also reinforces and then some my desire to focus increasingly on passive income. So, basically, reading this book for me is sort of like a gigantic pat on the back: “you’re on the right track, Erik, but you should double down!”
You should buy and read this book. Seriously. It’s, at times, audacious to the point of discomfort, and it can feel a little Amyway-this-is-too-good-to-be-true-ish (though it probably isn’t), but he makes some incisive observations that will rattle you and alter the way you think of the corporate world… like I’m about to do (I hope). Some of the inspiration for this post is derived from my experience (particularly the focus on programmers, which he doesn’t do), and some of it from the book. So, without further ado…
The Hard Truth
Salaried, exempt employment is an atrocious economic deal, especially for programmers. Weird as it sounds to say now, I’m not saying that your employer is screwing you nor that you shouldn’t be a salaried, exempt employee. I actually rewrote that first sentence several times, trying to be a little less blunt, but it is what it is. It’s not a value judgment and it’s not intended to be click bait or offensive — it’s just the stark truth. Let’s go through some numbers, to put an exclamation point on it. Read More
If I squint hard enough, I see an odd symmetry to my life that can be book-ended pretty simply with the phrase, “I want to build a thing.” I say this now, and I said it when I headed off to college, but I didn’t say it all that much in between. At least, I didn’t say it in the macro sense. But let me start the story a little before college.
As a kid, I was pretty equal opportunity when it came to academics. This was eventually born out somewhat empirically by my nearly identical SAT scores for math and verbal. So even though I had aptitude for math and the sciences, the first actual profession I aspired to in a non-childish fashion was to be a writer/novelist. I was pretty sure that I would make my living this way until it came time to apply to college. Here, I punted on a decision, applying to what I perceived to be the most rigorous major/school at each college and reasoning that I’d sort of force myself to make a decision. Mission accomplished. After weighing options and finances, Carnegie Mellon University in Pittsburgh was my best option and they were pretty good at Computer Science, so Computer Science it was. The world was enthralled with dot-coms, I’d always liked hacking around on my programmable calculators, I was told I’d be printing money when I graduated, and so I headed off to school saying, “alright, I’m gonna go build a thing!”
One of the serious difficulties about the life of a traveling consultant is avoiding weight gain. While this might sound like such a first world problem as to be 0.5 world problem, it’s actually a serious struggle. Living in a hotel, every meal is a restaurant meal, and restaurants tend not to optimize for low caloric intake. Recently, though, I’ve turned the tide and started to make a pretty successful foray into enemy territory; I’ve lost about 8 pounds over the last few weeks.
As someone who already exercises regularly and is conscious of my caloric intake, I pulled a different sort of lever to make this happen. I eliminated decisions about eating them by making them ahead of time. To wit, I set a rule for myself that until I became about 15 pounds lighter, I would not eat any desserts, drink any alcohol or eat any snacks. This is surprisingly easy to do compared to making decisions like that every time I was out with friends or felt hungry or was offered a cannoli or something. Standing in front of the pantry, it’s a lot easier to say simply, “oh, I don’t have snacks anymore” than “well, I’ll have a few handfuls of popcorn to tide myself over, and one cookie is probably okay…” The former is 0 decisions while the latter is endless decisions in the form of “should I eat this or that?” and “should I stop eating this now?” Life gets easier when you pre-make decisions.
This post has been a draft without words for a long time, evoking images of a jar of pickles that’s been in the fridge for 15 months. Someone says to me something like “man, I really want to start blogging but __________” and I say, “Don’t let that stop you — tell you what, I’ll write some tips and tricks.” The first time this happened was me buying the pickles and putting them in the fridge. Each subsequent time, I stick my head in and say, “yep, still have pickles and I’m totally going to eat them one of these nights.” Well, today is pickle-eating day.
This post is aimed at someone who either has no blog or someone whose blog consists of a few posts described by the metaphor in the last paragraph. You have a blog or don’t, but you’re interested, rather than having a blog, in being a blogger. This is an important, but subtle distinction since it flips the matter from achievement to identity — you can move a “make a blog” or “make a post” card into another column in Trello, but not so much with “be a blogger.”
Also, caveat emptor. What I’m telling you here essentially amounts to, “here’s what I’ve learned through some reading and collaborating and a whole lot of trial and error.” I have a pretty decent reader base and sometimes I even get paid to write (and, recently, to help others get better at writing), but I am not Lifehacker or some kind of blogging empire. I’m a guy that’s been treating the world to two or three rants per week for a number of years.
In my ChessTDD series, I was confronted with the need to create some actual acceptance tests. Historically, I’d generally done this by writing something like a console application that would exercise the system under test. But I figured this series was about readers/viewers and me learning alongside one another on a TDD journey through a complicated domain, so why not add just another piece of learning to the mix. I started watching a Pluralsight course about SpecFlow and flubbing my way through it in episodes of my series.
But as it turns out, I picked up SpecFlow quickly. Like, really quickly. As much as I’d like to think that this is because I’m some kind of genius, that’s not the explanation by a long shot. What’s really going on is a lot more in line with the “Talent is Overrated” philosophy that the deck was stacked in my favor via tons and tons of deliberate practice.
SpecFlow is somewhat intuitive, but not remarkably so. You create these text files, following a certain kind of format, and they’re easy to read. And then somehow, through behind the scenes magic, they get tied to these actual code files, and not the “code behind” for the feature file that gets generated and is hard to read. You tie them to the code files yourself in one of a few different ways. SpecFlow in general relies a good bit on this magic, and anytime there’s magic involved, relatively inexperienced developers can be thrown easily for loops. To remind myself of this fact, all I need to do is go back in time 8 years or so to when I was struggling to wrap my head around how Spring and an XML file in the Java world made it so that I never invoked constructors anywhere. IoC containers were utter black magic to me; how does this thing get instantiated, anyway?!
At this point, I’m not going to bother with excuses any longer and I’ll just apologize for the gaps in between these posts. But, I will continue to stick with it, even if it takes a year; I rarely get to program in C# anymore, so it’s fun when I do. In this episode, I got a bit more sophisticated in the use of SpecFlow and actually got the acceptance tests into what appears to be reasonable shape moving forward. I’m drawing my knowledge of Specflow from this Pluralsight course. It’s a big help.
Here’s what I accomplish in this clip:
Implemented a new SpecFlow feature.
Discovered that the different SpecFlow features can refer to the same C# class.
Implemented parameterized spec flow components and then scenarios.
Got rid of the “hello world-ish” feature that I had created to get up to speed in favor of one that’s a lot more useful.
Here are some lessons to take away:
When using new tools, you’re going to flounder a bit before the aha! moments. That’s okay and it happens to everyone.
As your understanding of tooling and your environment evolves, be sure to evolve with it. Don’t remain rigid.
Fight the urge to copy and paste. It’s always a fight myself, but on the occasion that I don’t have a better solution right in the moment, getting a test green, than duplicating code, I force myself to feel the pain and re-type it. This helps me remember I’m failing and that I need to make corrections.
When I got my bearings in SpecFlow and realized that I had things from the example that I didn’t actually need, I deleted them forthwith. You can always add stuff back later, but don’t leave things you don’t need laying around.
Notice how much emphasis I placed throughout the clip on getting back to green as frequently as possible. I could have parameterized everything wholesale in a broad refactoring, but I broke it up, checking for green as frequently as possible.
Sometimes sanity checks are necessary, especially when you don’t really know what you’re doing. I was not clear on why 8 was succeeding, since I was querying for a piece off the board. Just to make sure that I wasn’t messing up the setup and it was never even checking for 8, I added that exception in temporarily. Use those types of checks to make sure you’re not tilting at windmills. As I’ve said, getting red when you expect red is important.
No matter what you’re doing, always look to be refactoring and consolidating to keep your code tight.
As most of you know, one of the biggest anti-patterns when you’re instantiating program slots is to forget to set CanRemoveOverride to true. But what you probably didn’t know was that the SlotConfig is — Just kidding. I lifted this from a post I wrote almost 3 years ago about legacy code I was working with then. I have little more idea than you do what any of that means.
If you were to ask people in the corporate world about the most significant moments of their careers, a lot of them would probably talk about annual performance reviews. That’s a curious thing. Anyone who talks about performance reviews when asked this question is not talking about an idea they had that saved the company hundreds of thousands of dollars or about rescuing a project that had gone sideways. Instead, their careers were defined sitting in a room with their managers, going through a worksheet that purports to address how well they’ve matched up against the company’s ‘values.’