Tell us a little bit about yourself
My name is Erik Dietrich, and I’m a consultant and the co-founder of a content agency that specializes in software-oriented content. That’s actually kind of a weird development, given that I have a BS and MS in computer science and spent the first decade of my career with varying flavors of the job title software engineer.
Since then, I moved into management and then went into business for myself doing developer training and IT management consulting. Starting the content agency was a relatively recent and somewhat unexpected development.
On the personal front, I’ve had a lot of different hobbies and interests over the years, but the most interesting facet of my life right now is that my wife and I are what is known as slow travelers.
I spent a number of years on the road non-stop as a consultant and got so used to it that living out of suitcase was the norm. So even though I’ve stopped with the commuter travel, my wife and I pack up and go live in other places for 1-4 months at a time. Our home base is theoretically in Michigan, but I’m typing this from a house in Vermont where we came to watch the leaves change. We’ve also had protracted stints in Phoenix and San Diego this year as well.
How did you get started in programming?
When I was a little kid, during the mid-80s, we were one of the first families to have a computer. It was an IBM PC Jr, and I loved that thing. My dad taught me some rudimentary programming as he and I would make games together (for some definition of “together,” since it was mainly him programming and me yelling with delight and playing the game). So I was comfortable with computers from a very young age.
AP CS programs were after my time, so I settled in high school for writing bits of code for my TI-85 programmable calculator. The subject matter interested me, but I didn’t have a ton of resources. Still, I had a sense that I wanted to work with technology, so when I applied to college, I went for computer science, which had me go from toy calculator programs to C and C++ as soon as I arrived on campus.
The rest, as they say, was history.
What are some of the languages you use today and why?
Before I went off to school to pursue a CS degree, my first great academic love was math. So it’s probably not a great surprise that I find myself drawn to the functional paradigm. I don’t care a ton about languages, per se, but I very much love declarative semantics and writing side-effect-free, non-procedural code.
Language-wise, I’ve become something of a homer for C# over the years.
It’s not so much that I think it’s the best language or anything like that. Rather, I admire the way the language authors have made it more functional/declarative over time as well as taking great pains to eliminate pointless boilerplate and to make it terser.
So, I mainly use C#. I don’t get paid to program, so I can use whatever language(s) I want, and I enjoy using that one. But I would generally use whichever one gets the job done.
What type of applications do you develop?
The only production app I work on these days is an internal, line-of-business one for Hit Subscribe. It’s an ASP MVC app, deployed to Azure, and it’s mostly forms over data with a dash of domain logic.
I also do a fair bit of codebase research for my specialized consulting practice. I have an engine that does custom static analysis on codebases as well, but this is private and it’s a desktop (command line)-based application that has me as its only contributor.
Apart from that, everything I do is for training purposes or for the sake of writing instructional blog posts.
What’s your biggest passion these days related to programming?
Static analysis related to code quality. One of the things I find really frustrating about our industry is that our definition of “good code” is mainly anecdotal. We consider it good code if respected people in the industry consider it good code, or else we consider it good code if our experience is that it’s good to work with.
The codebase research that I mentioned is aimed at gathering statistics/metrics from many different codebases and to look at what sorts of properties and outcomes tend to correlate. For example, I did a series of studies about the relationship between unit tests and properties in production code, such as lower cyclomatic complexity.
It was interesting and gratifying to validate that the presence of more unit tests tended to really correlate with things like lower cyclomatic complexity per method.
What still sucks and shouldn’t be in programming?
I touched on this earlier, but I have a pretty low tolerance for boilerplate and needless verbosity in code. So, in that vein, I’m going to go with code generation.
I know that perhaps not everyone shares this point of view, but I’ve always found code gen to be, at best, an awkward bit of overkill and, more commonly, to be an absolute maintenance nightmare.
What are some of the most important skills developers can have?
I’m going to offer a somewhat contrarian take here. I think things like deductive reasoning, problem solving, and troubleshooting are certainly important for software developers, as is serviceable proficiency in whatever language/stack/etc you’re going to work in. But I think we tend to focus on these things to the point of diminishing returns.
Far more important than those things, I think, is the ability to mentor and teach these skills to others and the interpersonal skills for them not to grow to hate you as you do it. As Bob Martin once pointed out in a talk, the programmer population is doubling every 5 years or something like that. This means that our biggest impact as individual technologists, will always be shaping the paths of those who come to it later than we do.
And, frankly, from a career development perspective, these things are important as well. You’ll get more pay increases, leadership opportunities, and cool jobs via networking, business savvy and leadership than you will mastering your 14th programming language.
How did you learn about Typemock and what was your first reaction?
Years and years ago, while googling around for ideas on how to unit test around some nasty global/static state. I remember having a reaction that was something along the lines of, “oh, wow, you can mock THAT?!”
Do you have tips for readers who are just starting out with Typemock?
An isolation framework is an extremely powerful tool. You can do a lot of things, and you have a lot of options for creating seams in your production code.
Practice by working your way through simple examples in sequence to explore what all the tool can do. Get a sense for all of the different things that can be faked in your production code, how you would go about doing it, and what it’s like.
Once you’ve got that down, understand that you should use heavyweight isolation judiciously. Make your code testable and use the isolation framework to isolate APIs at the edge of your system that you would otherwise have to shim.
How do you convince your manager to write more unit tests or practice TDD?
I actually once did a course for Pluralsight about how to make the case for development practices like TDD. I would suggest convincing management by making a business case for it.
TDD does a lot of things for you: it prevents regressions, documents the intent of your code, reduces the lifespan of defects, guards against tech debt, etc. But you can summarize this to management by explaining that it reduces the application’s total cost of ownership (TCO), which means that they’ll have predictable releases and flat feature development times.
Speak their language, and they’ll trust you to act in their best interests, at your discretion.
Any tips on making managers understand the importance of using Typemock?
Building on the above, Typemock makes you more effective at TDD, which makes you more effective at reducing the TCO of your application.
But if you really want to convince them, get down to brass tacks. Figure that market price for a developer-hour is about $100 per hour. This means that for Isolator Complete to bring a return on investment, it would have to save you 8 hours per year, or about 9 minutes per week.
The first time you go in and try to get some code relying on complex global state under test, Isolator will pay for itself within a day or two.
Do you practice TDD and if so, what are some of your favorite code katas?
I do practice TDD, but it’s been a number of years since I did a code kata. I remember enjoying one about computing change from a vending machine and another about calculating bowling scores. I also once created a lengthy series of videos about how to do TDD by building a chess engine, which took longer than expected but was a lot of fun.
What are some of your must-have tools or libraries that you use in your daily working life?
These days, I pretty much manage everything about my life in Trello, so that probably takes the top spot. The other major thing that I have is a nice, effective pair of noise-canceling headphones.
My work these days is so varied and eclectic that it’s hard to go beyond that, but with those two things, I can manage my work and tune out the world to concentrate.
Who or what inspires you in the technical world?
I’ve been a home automation enthusiast for well over a decade, re-appropriating old computers, installing Linux, and using them to drive a network of X10 devices in my house back in the mid-2000s. This used to be sort of a weird, niche hobby.
Fast forward to today, and you’ve got an amazing array of commercial solutions at your fingertips. As much as people get IoT buzzword fatigue, I think all of these developments are really cool. I love that home automation is now part of the lives of many, many people, even if I didn’t necessarily participate actively in bringing that about.
When you need a quick recess at work to regain focus, what do you do?
Owning a location-independent business, I have a lot of flexibility when it comes to my days. So what I usually do if I’m at wits end or in need of a break is that I go for a jog or a kayak ride.
What’s your horror/war story from the coding trenches?
Hmm, let’s see. Maybe 12 years ago or so, I was working for a company that manufactured mail sorting machines. Specifically, I worked on the Linux kernel modules in the controller computer, which functioned as the “brain” of these large, complex machines that processed something like 50K mail pieces per hour.
In this particular case, I was doing some work at the Valpak plant down in Tampa Bay. This plant had a particularly large, particularly new, particularly complex sorting operation. I had taken over for a previous engineer that had written these precisely timed modules, but who wasn’t such a believer in things like source control or test environments.
So when I first got there, the way you “deployed to prod” was to FTP into this machine on the LAN, put the modules you’d just compiled on there, ask the operator to stop the machine, unload the old modules, load the new ones, and start ‘er up again. Seriously. I’m not kidding.
My first time onsite, I was tasked with fixing a few small but important issues. Facing pressure, I didn’t insist on establishing a better process than this before implementing fixes. The first few went off without incident, and I started to feel pretty good about myself.
But, like Icarus, I flew too close to the sun. For the next fix, I followed this same process, loaded the modules, and had them start the sorting back up. About a minute into it, a warning light started to flash, and something about the timing got just enough out of whack to somehow cause mail to start spewing everywhere out of the machine to the sound of this klaxon that was going off. I felt like I was in a bad action movie.
After that, I called shenanigans, and refused to do anymore patching until we’d gotten the code into version control and had at least some sanity testing in place, pre-deployment.
What’s the best advice you’ve ever received or what advice would you give your younger self?
I’ve received way too much great advice over the years to pick out one single piece that’s head and shoulders above the rest. But I can think of what would have surprised my younger self the most about me now, so I can give that younger self advice.
And that advice would be stop being a generalist programmer.
My goal in my 20s was to get good at programming in all shapes and sizes, and to become an accomplished programmer. Functional, object-oriented, structured – I should know all the paradigms. I should also probably know as many languages and as many frameworks therein as possible. And so on and so forth. I didn’t care what industry I was in, who I worked with, or what problems the software I worked on solved.
I would tell the younger me to take the opposite approach. Don’t worry so much about the techs and don’t develop a skillset miles wide and inches deep. Instead, pick an industry, a niche, or a type of client where the things you learn build upon one another more readily and eventually establish you as a specialized expert.
What are some interesting links you can share about yourself?
• The content agency that I own and have been referring to is Hit Subscribe.
• I’ve also been consulting under the DaedTech umbrella and blogging about my adventures there for years.
• I mentioned doing a course for Pluralsight, and you can check out my author page there, if you’d like.
• I’m a regular panelist on the Freelancers Show.
• I’ve written a few books that you can find, among other places, on Amazon.
• And you can Tweet at me @daedtech, too, but I must warn you I’m not terribly good at Twitter.
