Software Stranded Me in New England for Four Days

Craftsmanship in software matters to our lives more and more every day. I am reminded of that now that I am stuck in New England for four days because of a glitch with Southwest Air’s backend systems.

The only thing we seem to know about the root cause right now is that there was an issue with a “router,” but who knows what kind? Maybe a network router or maybe it was an API router. Maybe the hardware burned up, but more likely it was some kind of failure deep in the software stack of the device. Worse, for some reason the fail over systems failed too. Southwest reportedly had to “reboot everything” to get the whole system up and running again.

How ironic it was that I was reading about SOLID principles (an important aspect of craftsmanship) in functional programming in the Providence airport as all hell was breaking loose around me. Little by little my phone kept buzzing, letting me know I was getting increasingly delayed and then finally cancelled. The system failure was so bad that they can’t get me on a return flight until four days later.

Only a few years ago Southwest was able to issue paper boarding tickets and recover with old fashioned manual systems. These days, the software is so deeply intertwined that the failure was more massive (almost 1,200 flights cancelled). There was no way to recover.

Getting it right in software is more important than ever. Craftsmanship is one way to do it.

Leading Your Team to Craftsmanship — by Example! (No. 9)

Hey Software Crafter,

Hope you had a good Fourth of July!

Today I was starting some new consultants at my biggest client. These are junior consultants dropped into roles where they have to both excel technically and also exert quite a bit of influence with the client’s engineering team. As if that isn’t hard enough, they have to do this with absolutely no authority; it’s all non-positional leadership they have to demonstrate. I’m here to help them, but such can be the life of a junior consultant.

And their experience made me think about you. I suspect you are either discovering craftsmanship and/or you want to bring more professionalism to your team. Unfortunately, you don’t have the formal authority to mandate the change (both in practices and attitudes) you’d like to see.

Still, getting your team to follow you to a better place is a classic “leadership without authority” opportunity, just like the one my consultants are contemplating in their hotel rooms tonight. Here’s the opportunity: if you can get good at this, you can make amazing things happen with both your code base and your career far, far beyond your individual contributions.

But I’ll warn you, as I warned my consultants this morning, it’s not easy. Indeed, it’s the kind of choice that can lead to frustration, disaffection, and withdrawal if you go about it the wrong way.

For example, what if you read Clean Code over the holiday weekend (you did too, right??), you couldn’t wait for Tuesday to come, you can’t wait to refactor, and you got fueled up on Philz on the way in this morning. You burst into the office and announce on Slack, “Hey folks!! I’m renaming all our variables!!!” I already know the response you’re going to get — I’ve seen it.

It’s easy to get transported to a new mental place by an influential book like Clean Code, but most of your coworkers are probably still in the same mental place they were in last Friday afternoon (or even a little foggier than you left them after the Fourth of July weekend). They aren’t there with you and your over-caffeinated, evangelized self. Most coders are a little skeptical of evangelists. Which stings a bit and could leave you cynically thinking all the puppies and unicorns must be on the other side of some other rainbow with some other team.

So here’s an idea to try before brushing up your resume: lead by example. In The Software Craftsman, Sandro Mancuso says, “When it comes to driving technical changes, especially if the change is about attitude and practices like TDD, nothing will help you more than the ability to lead by example.” He’s right. I’ve seen it. I learned TDD by chance years ago when one of my peers just grabbed a couple of us out of a hallway and said something like, “hey I want to show you how I do TDD.” While I didn’t start doing it consistently right away, as others starting doing more of it, we all started doing more, and I saw the value.

If he hadn’t done that one act of leading by example, I wouldn’t be writing this email today.

(By the way, this post originally appeared as a letter to the LA Software Craftsmanship community. Consider joining us in LA or Phoenix.)

Craftsmanship, flow, and engagement – Software Craftsmanship Letter No. 6

What if you woke up in the morning actually looking forward to your day job? Maybe it’s because of the people you work with; uncommon, but it does happen.

Or what if you love coming to work because you know you’re going to be tightly focused on your code, and external things like tooling, crappy dependencies, or lame-ass processes won’t get in your way. Maybe the other engineers care as much as you do about the quality of the code base. Maybe you work with a supportive group of engineers who don’t make you self-conscious about every pull request. Maybe your manager works hard to give you some time to focus on quality, not just deadlines. Maybe the management and your team give you the autonomy to try things and they support you when you make mistakes or fail.

Personally, I have to use my imagination because I’ve never had a working experience like what I just described. Almost all my days were varying orders of magnitude away from that, probably your days are too. Now that I have more ability to change the environment, I actually do enjoy coming in, and I still love writing code. But yeah… there were a lot of days I didn’t feel much like going to work no so long ago.

That “what if” world I’m imagining comes from flow theory, and I think it’s how a software craftsman would ideally design his or her working environment. That matters because flow theory leads directly to high levels of engineer engagement. And it just so happens that flow, craftsmanship, and high levels of engagement should matter to your boss because it means both low turnover and high productivity.

Software Craftsmanship – Letters from the Road #5

Walmart. You cringe every time you go. You went there a while ago because you saved a few bucks on an iPad mini or got a killer price on that toy you wanted to give your niece. Whatever it was, you drove yourself to a Walmart in Duarte (or wherever) feeling clever for the $50 you’re saving. Saving $50 == awesome.

But then you parked your car. You walked in. The greeter was friendly — a little too friendly and a little too young, like he was on day release. You walked to the online pick up counter (’cause you’re just that clever to order online) and spent some quality time with the cashier talking about her loser boyfriend while she got your order.

You walked out thankful you had the opportunities in life you did so you could work in the hottest industry in the world instead of punching a time clock near the baler in the back of the Walmart in Duarte.

Yet, working for that place and that ethic is what Chad Fowler suggests as a paradigm for how we should think of our jobs writing code — at least sometimes. His sub-point is that “When you create software, the purpose is rarely self-expression.” If Fowler were talking about some other industries he might be right.

But he’s wrong about the software industry. The idea of “writing code to spec” died (or is dying) with agile. In our business (in sharp contrast to Walmart’s industry), the best talent wants to work in a place where the craft is respected and where their employers don’t cut corners just because the client asks for it. Also, Fowler overlooks that clients pay for high quality code.

The first point might be the most important when it comes to the war for talent. Craft matters. Personally, I spent far too many years working in shops that cared primarily about hitting deadlines without watching the ballooning balance on the tech debt credit card. It made me cynical, to say the least.

Maybe you did too. You hopped from job to job. Nothing was ever right. The code base. The tools. The managers. The product owners. The other people on the team. Something — lots of things — always sucked. Maybe it’s just that management (and/or the team) didn’t care about the craft.

The second point matters a great deal too. In our world, even in the enterprise, where people are inundated with choices and options for how to use our code to solve problems or use our apps to experience new things, quality is often the key differentiator. And quality doesn’t start with testing; quality starts with the craft.

Fowler suggests that sometimes we need to succumb to commodity because our clients demand it. I think Fowler is proposing a dangerous and unprincipled distinction that will inevitably lead to cynicism for anyone who tries to follow. I know because I’ve been there. I don’t argue that we should always win the battle between quality and shipping product. I only argue that we’ll fall into cynicism in our profession if we don’t engage in that battle, if we don’t advocate for the craft.

Software Craftsmanship – Letters from the Road No. 4

Assembling a Team of Effective Software Craftsmen

There’s a lot written about craftsmanship, but I haven’t come across much from a manager’s point of view. On the one hand, we all agree that deploying quality products rapidly is job one, which is what I mean by effectiveness. But the other hand is more controversial: what is software craftsmanship and, more salient to me, how in the world can one manage for craftsmanship?

The answers to the questions on both hands surely merit their own treatises. So let’s start with a smaller outset concern: how do you assemble a team of craftsmen from the ground up? Assuming you couldn’t hire a complete team of software engineers who obviously embrace craftsmanship ideals, here are a few indicia that I might look for:

A whole person who’s fun to talk to, work with, and generally hang out with. If we’re going to think of ourselves as working together in a workshop and we want our engineers to be communicating (a lot, right?) then we need to have engineers who are fundamentally good people, people who are easy to talk to about all kinds of things and open to changing their points of view on code and anything else. By this, I seriously don’t want the team to be a monoculture; I just want each member to be friendly and good-natured.

Dismiss this point as obvious or “soft” at your own risk. This species of human resource — if you want to express it in inhuman terms — is a seriously scarce resource in our economy of software engineers. Still too squishy for you? Would you agree that a big, unspoken, factor in team communication failures (and therefore, project or business failures) is that some people are exquisitely horrible talk to or work with? Sometimes it’s so bad that other engineers want to work from home all the time. Slack can’t fix an asshole no matter how clever the giphy.

Works (or wants to work) in small increments. These days I’m of the perspective that craftsmanship is not a “thing” so much as a state of mind manifesting itself in the team’s process of crafting code. So in building a team of craftsmen if I can, somehow, surface during an interview that an engineer is focused on building small, shippable increments then it might be evidence that he or she has the habits of a craftsman.

I’ve tried a few different approaches on this point in the past with mixed success. Maybe I’ve been more successful looking for the reverse — the engineer who wants to design everything and every corner case before writing any code, let alone shipping anything. This habit is easy to detect and very difficult to change.

Self-directed, fascinated by great code, and fully engaged. My ideal engineers aren’t waiting around for stories or tasks from a scrum master nor are they seeking to score political points by taking potshots at a befuddled product owner in a grooming session. They’re dedicated to making their mark on the product by actively engaging (and truly educating) product owners and/or bringing in a great new method, technology, or something cool they learned at a coderetreat (or meetup or whatever) last weekend. I know this means that my ideal engineer is putting a lot more than forty hours a week into the job as well as his or her career, but I’m just stating my ideals here.

I could have made this a laundry list with a million ticky tacky points but I think broad strokes are more effective with human “resources” than punch lists. Also, one thing you won’t ever find on my list is any kind of quantitative measure.

My objective for this  list is to help identify a team of software engineers who could grow into solid (or even great) craftsman who ship code. In summary, I think my list might capture the raw material if each individual on the team is (1) a great person to work with, (2) works in small increments, and (3) is self directed and fully engaged.

What do you think?

Software Craftsmanship – Letters from the Road No. 3

Heart, head, and hand

On my flight out of Burbank yesterday morning I finally got a few free cycles to read some more of Why We Make Things and Why It Matters. Korn, the author, wants me to explore craftsmanship from two points of view — the creator’s and the reader’s. It’s a short flight to Phoenix, so I’ve only got time for one chapter and one POV — the creator’s.

Korn argues that “the making of craft calls forth a symphony of human capacities that are intrinsically fulfilling to the craftsman.” Too many software engineers — especially in the enterprise — I know would counter an assertion like that with an all-too-cynical response. What do you think? Do you feel you’re using the “full symphony” of skills when you’re crafting code?

Sure, Korn is talking about crafting with wood, materials, and the physical world, which you could argue is a critical distinction. You and I work with ephemeral code; we work in mental abstractions. But is it really so different? After all, the code ultimately finds its way into the processor, which is just as unforgiving (maybe more so) than a dovetail joint gone wrong.

I think most conscientous software engineers would universally agree with Korn on the point that “[t]o achieve consistent quality in terms of fit and finish, [we have] to marshal qualities of [personal] character such as focus, patience, and perseverance.”

What if our day jobs engaged our whole character — our focus, our patience, our perseverance? Korn goes further to suggest that craftsmanship may give us the “holistic experience many contemporary Americans find lacking in their occupations and personal lives.” Interesting. What if it we weren’t missing this “experience”? What if you could you go into work tomorrow morning and own that belief? Of course, I can’t do that for you. But maybe you can find a bit of it in our little Los Angeles meetup group.

Maybe I’m getting too out there for you; it’s late as I write this.

Maybe this will get down to the actual rivets of the modern software craftsman’s trade: “Craft is a process of continuous feedback in which the craftsman’s working suppositions are subject to constant fact-checking by the real world.” The real world Korn is talking about is how wood reacts to his tools, but maybe he’s starting to sound like what we think of as software craftsmanship; we use tools and methods like devops, TDD, small increments, and etc. these days… maybe as an industry of creators we’re getting closer to craftsmanship — or maybe that’s just the tooling and not the true point of view.

Do you agree? Maybe? No… yes?

Software Craftsmanship – Letters from the Road No. 2

Dear Craftsman,

It’s been a brutal month for me. I’ve been in the business the better part of two decades, but this has been the hardest few weeks I’ve had since I was a teenager waiting tables. Angelinos are prone to theatrics; I’m not — this is for real. And that’s my excuse for my radio silence here.

I also haven’t seen much come across my radar worth reporting (not to mention that I haven’t had time to figure out what I want for lunch let alone have an original thought). But I did come across another email list you should consider subscribing to from a craftsmanship Meetup organizer in France. Looks like it’s a new group and a new list, kinda like mine. I hope his turns into something (and ours too).

One of the links in his newsletter is to Trey Stout’s recent Medium, Engineering Principles. Stout’s an engineering manager out in NYC… a herder of nerds like I find myself today. Engineering Principles includes an eleven point guide to things that seem to have worked for him. Of immediate interest to you, my dear craftsman, is that he encourages his engineers to “be a craftsman” (#8) and defines craftsmanship thusly:

[a] product’s quality is only as good as its weakest part. This can manifest itself as well documented modules, open-sourcing our tools, or just giving lunch-talks on things you’ve made.

Personally, I think his comment on craftsmanship is probably his weakest point. That said, I think you should review his post because his other points go to the kind of critical thinking that might be the genesis of craftsmanship among individual developers — especially people who want to lead and develop craftsmen, like me.

I’m deeply envious of his list — why can’t I come up with a list like that? But of course I can. So can you. We’re both smart enough to write code and deal with the precisions required by the machine. We can think critically if we try.

But therein may lay the problem: maybe dealing with the pedantry and quirks of the language we’re working in, the ill-documented frameworks, someone else’s crappy API, the buggy IDEs, the soul-sucking enterprise policies, the oppressive meetings, and the broken ice machine in the break room cause the critical thinking cell of developers’ brains to get beaten out of too many enterprise developers. I’ve pulled the victim card on this too many times myself, but now that culture is on my job description my bosses took my victim card away from me. I don’t think I get to pull yours by proxy.

These days, I think that’s why craftsmanship in software is such a valuable thing to me. Somehow, I imagine true craftsmen rise above the frey, the bullshit that is day-to-day working life, and they think deeply about their craft. That’s why I aspire to it, and I aspire to figure out how to give my teams the environment they need to aspire to it.

I hope you do too.

Software Craftsmanship – Letters from the Road #1

I’m based in Los Angeles, but tonight I’m on a hotel balcony during a beautiful October evening in Scottsdale, Arizona. I’ve been staring at a blank text box for a long time tonight — longer than usual. I want to start writing regularly about craftsmanship in software development, especially in the enterprise, because I don’t hear enough about it in my day job.

I’m staring at the screen because I’m not really sure where to start. Craftsmanship in software is both a huge topic and a tiny one. Even just thinking about it means I’m considering broad issues of developer culture one moment and the Zen of a developer’s solitary experience in refactoring a single variable name in another moment.

And I’ve come up short looking to the web for a consistent source of unique thinking on the subject. For example, I set up a Google alert on software craftsmanship over a month ago. After a few weeks of coming up with few hits and very little worth reading, I started ignoring the emails. Alternatively, I guess I could regurgitate Uncle Bob’s Clean Code or follow the lead of some of the software craftsmanship authors, but I think that would just perpetuate the digital echo chamber.

So last night I started reading Why We Make Things and Why It Matters: The Education of a Craftsman by Peter Korn. He’s a woodworker. He turned his back on professions like law and medicine in the 1960s to find meaning in day to day work and found it with woodworking. Why didn’t I have that kind of mission when I was in my twenties? I doubt I’ve ever worked with anyone who took up software development for the same purpose. While I’ve met people with varying levels of intensity (is it always passion, or is it sometimes just intensity?) in the world of software development, no one has ever struck me as doing it for the craft — let alone announced it.

I’m only a few chapters in, and what I’m reading is touching in places and moving in others. But I’m torn between the often high speed demands of software development (especially so-called agile processes with drop dead dates) and the creative destruction that happens in those cycles with the individual needs of developers (including me) who do care about their craft.

By the way, a few months ago I started a Meetup group called Los Angeles Software Craftsmanship. Come join us. We can figure it out together.