Stories about Software


Signs Craftsmanship May Be For You

One of the things I’ve spent a good bit of time doing over the last year or so is called “Craftsmanship Coaching.” This involves going into teams and helping them adopt practices that will allow them to produce software more reliably and efficiently. Examples include writing automated unit and acceptance tests, setting up continuous integration and deployment, writing cleaner, more modular code, etc. At its core though, this is really the time-honored practice of gap analysis. You go in, you see where things could be better, and you help make them better.

Using the word “craftsmanship” to describe the writing of software is powerful from a marketing perspective. Beyond just a set of practices revolving around XP and writing “good code,” it conjures up an image of people who care about the practice of writing software to the point of regarding it as an art form with its own sort of aesthetic. While run-of-the-mill 9–5ers will crank out code and say things like, “if it ain’t broke, don’t fix it,” software craft-people will presumably agonize over the smallest details, perfecting their code for the love of the game.


The drawback with using a term like “software craftsmanship” is the intense subjectivity and confusion of what exactly it entails. One person’s “well crafted code” might be another’s spaghetti, not to mention that subjective terms tend to get diluted by people wanting, merited or not, to be in the club. To understand what I mean, consider the practice of scheduling a daily status meeting, calling it “daily Scrum,” and declaring a shop to be “agile.”

How then are software developers who are not associated with the software craftsmanship movement to know whether they should want in or not? How are they even to know what it is? And if they don’t easily know, how are overhead decision makers like managers to have any clue at all? Well, let’s momentarily forget about the idea of software craftsmanship and return to the theme of gap analysis. In the rest of this post, I’ll describe signs that you could stand to benefit from some of the practices that I help clients with. If you notice your team experiencing these things, the good news is that you can definitely simplify your life if you pursue improvements.

Similar Features Take Longer and Longer to Implement

Remember a simpler time when adding a page to your site took a few hours, or maybe a day, max? Now, it’s a week or two. Of course, that makes sense because now you have to remember to implement all of the security stuff, and there’s the validation library for all of the input controls. And that’s just off the top. Let’s not forget the logging utility that requires careful edits to each method, and then there’s the checklist your team put together some time back that you have to go through before officially promoting the page. Everyone has to think about localization, checking the color scheme in every browser, and so on and so forth. So it’s inevitable that things will slow down, right?

Well, no, it’s not inevitable at all. Complexity will accrue in a project as time drifts by, but it can be neutralized with carefully considered design approaches. The examples that I mentioned, such as security and logging, can be implemented in such a way within your application that they do not add significant overhead at all to your development effort. Whatever the particulars, there are ways to structure your application so that you don’t experience significant slowdown.

Simple Functionality Requests Are Anything But Simple

  • “Hey, can you change the font on the submit button?”
  • “Not without rewriting the whole presentation layer!”
  • “I don’t understand. That doesn’t seem like it should be hard to do.”
  • “Well, look, it is, okay? Software is complicated.”

Have you ever participated in or been privy to a conversation like this? There’s something wrong here. Simple-seeming things being really hard is a smell. Cosmetic changes, turning off logging, adding a new field to a web page, and other things that strike non-technical users as simple changes should be simple, generally speaking.

While clearly not a universal rule, if a vast gulf routinely appears between what common sense says should be simple and how hard it turns out to be, there is an opportunity for improvement.

Until Next Time

I originally wrote this post for the Infragistics blog and you can find the original here. There is also a second part to this post, as well.


Promote Yourself to Manager so that You Can Keep Writing Code

A while back, I announced some changes to DaedTech with idea of moving toward a passive income model. In the time between then and now, I’ve spent a good bit of time learning about techniques for earning passive income, and I’ve learned that I’m really, really bad at it. For example, I’m often asked for recommendations, and I respond by supplying them, as most decent humans would. This is wrong. What I should do is have a page on my site with all of my recommended and favorite tools and the page should link to them via affiliate links. I provide the same recommendations and earn a bit of money. Win-win.

Well, I’ve been halfheartedly working on this page for a bit. Believe it or not, the most difficult part of this is seeking out and obtaining the affiliate links. So, my page of recommendations remains a work in progress. And I was making progress tonight, securing affiliate links, when inspiration struck for a blog post about one particular affiliate. Most of the affiliates that I’ve identified are productivity tools, editors, and other techie goodies, but this one is different. This one represents an entirely different way of thinking for techies.

As a free agent, content creator, and product creator, I have a lot of metaphorical juggling balls in the air, and I’ve had to become hyper-productive and downright ruthless when it comes eliminating unnecessary activities. I don’t watch TV, I don’t go out much, I don’t take any days off of working, even on vacation, and I don’t really even follow the news anymore. Pretty much every conceivable bit of waste has been excised from my life, and I do a lot of work on an hourly or value basis. This has resulted in a whole new world of ROI calculations appearing before me — it’s worth paying premiums to save myself time so that I can spend that time earning more money than I spend.


Read More


The Secret to Fighting Buzzword Fatigue

A little while back, I made a post in which I mused about the work-retire dynamic as an unusual example of large batches in life. In the lead-in, I made passing reference to a post where I talked more specifically about buzzword fatigue. This is that post (with this explanatory paragraph pre-pended, of course).

It feels amazing, in an odd way, to give something a good name. You have to know what I mean. Have you ever sat around a whiteboard with a few people, tossing out names for some kind of module or concept or whatever, scrunching your nose and shaking your head slightly at each suggestion? “No, that’s almost right, but I don’t think that’s it.” And then finally, someone tosses out, “let’s call it the clobbering factory!” and all of your eyes go wide as someone else yells, “yes!!”


Names are important. There’s a certain finality to naming something, even when you wish it weren’t the case. Have you ever failed in the quest for the perfect name, only to say something like, “aw, screw it, let’s just call it ‘circle’ since it’s a circle on the whiteboard, and we’ll rename it later?” If you have, you can’t tell me that the thing’s official name isn’t still “circle,” even 3 years and 23 production releases later. You probably even once tried to rename it, grousing at people that refused to start calling it “The Phoenix Module” in spite of your many, many, reminder emails. It stayed “circle” and you gave up.

There’s an element of importance to naming that goes beyond simple aesthetics, however, when you’re naming a concept. Products, bits of code and other tangible goodies have it easy because you can always point at what you’re talking about and keep meaning from drifting. With concepts… not so much. Next to their tangible cousins, they’re like unmoored boats in a river and they will drift.

And I think that the amount to which they drift is controlled by two main factors:

  1. Uniqueness
  2. Mappability to known concepts in context

Read More


Let’s Put Some Dignity Back into Job Seeking

Alphabet Soup

I’ve seen a lot of resumes of late, so I can’t be sure where I saw this, exactly. I suppose it doesn’t really matter. This one resume really stood out to me, though, because it was perhaps the most self-aware talisman of the ceaseless employment quest that I’d ever seen. Specifically, one part of it was the self-aware part, and that came right at the end, under the simple heading “technologies.”

If you opened the PDF file of the resume, scanned down past heading info, work experience, and education, there was this bolded heading of “technologies,” followed immediately by a colon and then a comma-delimited list of stuff. It had programming languages, frameworks, design patterns, concepts, and acronyms. Oh, there were acronyms as far as the eye could see, I tell ya – the streets were paved with ‘em. (Well, they filled out the rest of the page, anyway).

It practically screamed, “this seems stupid, but someone told me to do this, so here-ya-go.” I’ve seen this before (and even done a version of it myself), but it was always organized somehow into categories or something to make it seem like manicured, useful information. This resume abandoned even that thin pretense.

Obviously, I didn’t look through this section in any great detail. I think neither I nor the resume’s owner would have considered it important to evaluate why he’d hastily typed “UML” in between some of those other things. It didn’t matter to either of us what was in that section, and, truth be told, I’d be surprised if he even knew everything that was in there.

I contemplated this idly for a bit, and then it occurred to me how similar this felt to the obligatory job description where a company lists 25 technologies under “requirements” and then another 15 under “nice to have.” UML is probably nice for everyone to have. Both job seeker and company probably list it and neither one probably knows it, making all parties better off even with a bit of mutual fibbing.

Applicants list things they don’t know because companies claim needs that they don’t have, and, in the end, the only one who profits from this artificially large surface area is the recruitment industry as a whole. The more turnover and churn, the more placements and paydays. The way the whole thing works is actually pretty reminiscent of a low quality dating website. Everyone on it lists every one of their virtues in excruciating detail, omits every one of their weaknesses, and exudes ludicrous pickiness in what they seek. Matches are only made when lies are told, and disappointment is inevitable. When people inevitably get tired of failure and settle for a mate, it’s random rather than directed.


Gah.  How depressing.  Let’s not do that anymore.  Let’s look for mutual fit instead of blind prospect maximizing on both sides.  We don’t want hundreds of potential employers or candidates.  We want a single one that’s well suited.

Read More


Office Politics 101 for Recovering Idealists

In writing my book, I find that I wind up with these thoughts, paragraphs and mini-essays that may or may not find their way into the book. I’m adding to Leanpub sequentially, but writing relevant things as they occur to me, so there are bits floating around, waiting to have a home. I’m going to appropriate one of those bits today, as a blog post, since this is on the fringe of “maybe it will fit, maybe not.”

You almost certainly play the game of office politics, whether you do so deliberately or not. If there are more than two people involved in something, there are politics, so if you work for a company or project of more than two people, you’re involved. Saying, “I stay out of office politics and just work,” is like saying, “I don’t vote or follow elections, so I’m not really involved in laws and policies.” You can certainly opt out of participation in the process, but you can’t opt out of the consequences of that process.

Becoming good at office politics is a messy endeavor, involving a lot of intuition, trial and error, and real life, career consequences. It’s also unpleasant for a lot of people. But if you take away one piece of advice on how to navigate the minefield, let it be this: stop giving away information for free because information is leverage. Read More


It’s a Large Batch Life for Us

It’s a large batch life for us!
‘stead of feedback we just wait!
‘stead of options we trust fate!

— Little Orphan Annie…sort of.

Before I talk about “large batch life,” I’d like to take a moment to share with you a bemused chuckle at really poorly done verbal tribalism.  Rather than try to explain in the general sense, I’ll offer an example: an out of touch father trying to determine if his kids are doing drugs by saying, “so, dudes, are any of your friend-bros on the pot?”  He’s attempting (and failing) to crack their linguistic code to gain credibility. The kids, presumably, have a tribe with its own invisible speakeasy, and Dad is trying to get in.

There are tons of tribes, and you’re a member of many.  When you say, “pull request,” in casual conversation, you’re indicating that you’re part of the tribe that puts open source code on Github.  When you tell people to “put it on my calendar,” you’re indicating that you’re part of office culture. There’s nothing particularly notable or bemusing about that — it’s simply the mechanics of human communication.  Where things start to get awkward is when Dad enters the mix in the form of a recruiter or hard-charging project manager and wants to establish cred in that world without really having any: “Hey dudebros, can I pull request a phone interview with you?”


Read More


Delegating is Not Just for Managers

I remember most the tiredness that would come and stick around through the next day. After late nights where the effort had been successful, the tiredness was kind of a companion that had accompanied me through battle. After late nights of futility, it was a taunting adversary that wouldn’t go away. But whatever came, there was always tiredness.

I have a personality quirk that probably explains whatever success I’ve enjoyed as well as my frequent tiredness. I am a relentless DIY-er and inveterate tinkerer. In my life I’ve figured out and become serviceable at things ranging from home improvement to cooking to technology. This relentless quest toward complete understanding back to first principles has given me a lot of knowledge, practice, and drive; staying up late re-assembling a garbage disposal when others might have called a handyman is the sort of behavior that’s helped me advance myself and my career. On a long timeline, I’ll figure the problem out, whatever it is, out of a stubborn refusal to be defeated and/or a desire to know and understand more.


And so, throughout my career, I’ve labored on things long after I should have gone to bed. I’ve gotten 3 hours of sleep because I refused to go to bed before hacking some Linux driver to work with a wireless networking USB dongle that I had. I’ve stayed up late doing passion projects, tracking down bugs, and everything in between. And wheels, oh, how I’ve re-invented them. It’s not so much that I suffered from “Not Invented Here” syndrome, but that I wanted the practice, satisfaction, and knowledge that accompanied doing it myself. I did these things for the same reason that I learned to cook or fix things around the house: I could pay someone else, but why do that when I’m sure I could figure it out myself?

Read More


My Candidate Description

If you’re a regular reader of this blog, I’m treating you to a strange post. Consider this experimental art of a fashion, I suppose. Odd as it sounds, this isn’t addressed to you, though I encourage you to read it, hope that you enjoy it, and suggest that you consider doing a version of it yourself. You’ll see why shortly.

If you’re a recruiter, you’re reading this because I sent you this link in response to an email, a message through social media, a message through SO Careers, or something else similar. Let me first say that I thank you for coming here and taking the time to read this. I mean this sincerely; as a blogger who pays attention to various forms of analytics, I’m aware of how many people drop off from a call to action, so I’ve already lost a good chunk of people to whom this is sent. The fact that you’re here and reading means that you aren’t dialing for dollars in volume the way so many of your colleagues with an “URGENT REQUIREMENT FOR A JAVA DEVELOPER IN TEST” seem to do.

Now, I realize that what I’m doing here may come off as a bit flippant or cocky, but I assure you earnestly that this is NOT my intention. As you are no doubt aware, I receive a nearly endless stream of contacts from people looking for software developers, software architects, dev managers, etc. This post, for me, is mainly about time savings. But it’s also a polite but insistent suggestion that we stop playing by old rules that no longer make sense. Gone are the days of a company putting out a job description and waiting for the “lucky” applicants to prove that they’re good enough. You know it, and I know you know it because I’ve spent a lot of time in your situation over the last few years, desperately trying to hire developers in an economy that saw all promising candidates disappear in the two days between a phone screen and a “let’s bring them in for a chat.” It’s harder for companies to find developers than vice-versa, no matter how many free cans of soda and ping pong tables your clients or you are offering.

So what I’m posting here is my candidate description that will serve as pre-screening for inquiries about my availability for work. Assuming your company or the company on whose behalf you are searching seems like a good match for my description and meets the must-have requirements, I may be amenable to further discussion over the phone. I say may because I’m quite happy with my current work situation and have almost more contract work than I can handle, so I simply don’t have much spare time.

Candidate Description

I am an experienced programmer, software architect, team leader, CIO, coach, and technologist that enjoys working with a wide variety of programming languages, frameworks, and tools. The majority of my recent development experience has focused on the .NET framework, though over the years I have worked with C++, Java, and a number of other languages. Projects range from low-level driver and kernel module programming all the way up to user interface design. Types of applications run the gamut from home automation to rigorous code analysis to line of business applications. My more recent work focuses more heavily on software craftsmanship coaching aimed at developers and IT management consulting aimed at IT managers and other positions at the periphery of software teams.

My passion for working with technology extends beyond the workplace and into my work under the umbrella of my LLC. I do various types of traditional consulting projects, but I also produce software-related content for public consumption. I create developer training videos for Pluralsight aimed at intermediate to advanced programmers. Beyond that, I am also an author and active technical blogger.

Must-Have Requirements for a Candidate Company

  • Must be open to B2B contract work (unless you’re looking for a dev manager or CTO, in which case, I’d prefer a conversation first about why you’re staffing that role and potential alternate solutions)
  • Must be open to considering initial arrangements of less than 40 hours per week.
  • Must actively practice or encourage clean coding practices (CI, TDD, SOLID, continuous refactoring, etc.) or else want to bring me in with a mandate to get your team doing these things.
  • Remote work arrangement possibilities are a non-negotiable necessity for development work, though occasional travel for site visits is fine (for programming, a bit more flexible for coaching).
  • I will not consider W2, exempt arrangement for software development.  Not even for a number that you think will make me swoon as if I’ve been told I’m the prettiest belle at the ball.  Contracting a must.
  • Provided I give reasonable notice, time off or with other clients must not be an issue for you.
  • Position must allow creative control of software work product.
  • For interviews, no brain-teaser-oriented interviews or algorithm-centric interviews (see “The Riddler” and the “Knuth Fanatic” from this excellent video about interviewing anti-patterns).  I strongly prefer code reviews and evaluation of my public code samples and am just not interested in discussing why manhole covers are round or in reliving college coursework from 15 years ago.
  • Regardless of language and framework, access to the latest bits is critical for me.
  • If you’re McDonald’s and you’re hiring me to build you a recipe database, I will sign an NDA agreeing not to distribute your recipe to your competitors.  Anything more strict and/or that restricts my ability to do freelance projects in any way at all is an immediate deal breaker.


  • I enjoy working on .NET technologies and in the connected (mobile or web) spaces.  I’ll happily code away in any language, but C#/.NET is my favorite these days.
  • No expense is spared on software development tools, and I can have my favorite text editors, productivity add-ins, etc.
  • I have the opportunity to contribute to company blog or public thought leadership in general.
  • I’d love working for a developer tools company or one that specializes in software development and surrounding expertise. If there’s developer evangelism in-role, even better.

Thanks Again

If you’re still reading, thanks again for taking the time and paying attention all the way through.  I know this seems strange, but I appreciate you humoring me, and I believe that this will save a lot of time in the long run for me and for you.  As I often tell people that I’m coaching, “it’s almost always better to fail fast and obviously,” so better you shake your head and move on to the next candidate rather than have you, me, and a phone screener all waste time only to have it come out after an hour of conversation that I’m not interested in signing an NDA and starting a W2 gig.

Readers, to address you once again, I suggest you do something like this as well.  Don’t settle; the market is too good.  And don’t let people on the hiring side convince you that you should be lucky to have a job.  I’ve tried hiring people who do what you do, offering generous salaries and a score of 10 or 11 on the Joel Test, and it was really, really hard.  Don’t settle for the first thing that comes along. Make your list, be patient, and be picky.  It will pay off.


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.


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

Acknowledgements | Contact | About | Social Media