DaedTech

Stories about Software

By

Code Kata? How About Product Kata?

When I was a kid, I spent a bunch of years doing karate. As best I can recall, there were three main types of activities around which we’d focus: kihon, kata, and kumite. I listed these roughly in order of sophistication. Kihon translates to something like “basics” and it involved executing the same punches, blocks, or kicks repeatedly, going for correct technique. Kata was something like “form” and this involved stringing together moves into more complex sequences and practicing those, presumably to emphasize rote practice of sequential movements. Kumite was sparring, and this was meant to be in-situ, improvisational practice, using the first two activities as building blocks.

There’s a lot of spiritual type stuff that goes on around martial arts, and it’s not my intention to rag on that in any way. You get out of things what you put into them and you find value that makes sense to you. But, at its core, these activities are really all about learning how to punch and kick other people and win fights. So you practice the basics, string those together into sequential movements and then have dress rehearsal sparring matches. This is all done so that when the time comes to actually punch and kick people in real life, you’re good at it. You don’t flinch when someone throws a punch because your countless hours of practice have made stepping into the blow, deflecting it and countering as second nature to you as cringing and protecting the head are for most people.

Learning to Punch People with Our Code

When I first heard of the martial arts concept of “kata” being applied to software development, I found it sort of interesting and weird. There’s intense marketing power in appropriation of this nature, and it can really make a concept take off. And, there are parallels between the two beyond the simple notion that deliberate practice improves technique. One of the main benefits to code katas is the practice of techniques like refactoring, TDD, etc. when the pressure is off. When in coaching/mentoring roles, it’s pretty common to see people try new techniques, only to abandon them when delivery pressure is perceived. To have “stickiness” for a software development technique, it’s essential that it hit a tipping point where the practitioner finds it less efficient to skip it than to do it. And doing a lot of code katas is a way to work toward that tipping point.

NinjaAssassain

Of course, as with any cross-disciplinary metaphor, there are gaps and those gaps can be problematic. Again, putting aside the spiritual overtones, karate is about learning to punch and kick people effectively. This is pursuit heavy on instinct and muscle memory and relatively light on cerebral cortex activity. A fight also spans seconds or, at most, minutes, where programming is a pursuit of hours, days, weeks, months, or years. I believe it was this sort of information gap that led John Sonmez to post about code katas. He heard the term “code kata” and mapped the martial art version onto it — one where you practice precisely executing the exact same movements until you can do them in your sleep. That’s not the intent of the code kata, but recall that we’ve been over what happens when you recycle terms with baggage for marketing purposes.

Read More

By

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.

Delegating

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

By

Are You Changing the Rules of the Road?

Happy Friday, all.  A while back, I announced some changes to the blog, including a partnership with Infragistics, who sponsors me.  Part of my arrangement with them and with a few other outfits (stay tuned for those announcements) is that I now write blog posts for them.  Between writing posts for this blog, writing posts for those blogs, and now writing a book, I’m doing a lot of writing.  So instead of writing Friday’s post late Thursday evening, I’m going to do some work on my book instead and link you to one of my Infragistics posts.

The title is, “Are You Changing the Rules of the Road?”  Please go check it out.  Because they didn’t initially have my headshot and bio, it’s posted under the account “DevToolsGuy,” but it’s clearly me, right down to one of Amanda’s signature drawings there in the post.  I may do this here and there going forward to free up a bit of my time to work on the book.  But wherever the posts reside, they’re still me, and they’re still me writing for the same audience that I always do.

 

 

CodersBlock

 

By

What Story Does Your Code Tell?

I’ve found that as the timeline of my life becomes longer, my capacity for surprise at my situation diminishes. And so my recent combination of types of work and engagements, rather than being strange in any way to me, is simply ammo for genuineness when I offer up the cliche, “variety is the spice of life.” Of late, I’ve been reviewing a lot of code in a coaching capacity as well as creating and giving workshops on story telling and creative writing. And given how much practice I’ve had over the last several years at multi-purposing my work, I’m quite vigilant for opportunities to merge story-telling and software advice. This post is one such opportunity, if a small one.

A little under a year ago, I offered up a post in which I suggested some visualization mnemonics to help make important software design principles more memorable. It was a relatively popular post, so I assume that people found it helpful. And the reason, I believe, that people found it helpful is that stories engage your brain far more than simple conveyance of information. When you read a white-paper explaining the Law of Demeter, the part of your brain that processes natural language activates and decodes the words. But when I tell you a story about a customer in a convenience store removing his pants to pay for a soda, your brain processes this text as if it were experiencing the event. Stories really engage the brain.

One of the most difficult aspects of writing code is to find ways to build abstraction and make your code readable so that others (or you, months later) can read the code as easily as prose. The idea is that code is read far more often than written or modified, so readability is important. But it isn’t just that the code should be readable — it should be understandable and, in some way, even memorable. Usually, understandability is achieved through simplicity and crisp, clear abstractions. Memorability, if achieved at all, is usually created via Principle of Least Surprise. It’s a cheat — your code is memorable not because it captivates the reader, but because the reader knows that mapping what she’s used to will probably work. (Of course, I recognize that atrocious code will be memorable in the vivid, conversational sense, but I’m talking about it being memorable in terms of its function and exact behavior).

It’s therefore worth asking what story your code is telling. Look at this code. What story is it telling?

Read More

By

10x Developer, Reconsidered

Unless my memory and a quick search of my blog are both mistaken, I’ve never tackled the controversial concept of a “10x developer.” For those who aren’t aware, this is the idea that some programmers are order(s) of magnitude more productive than others, with the exact figure varying. I believe that studies of varying statistical rigor have been suggestive of this possibility for decades and that Steve McConnell wrote about it in the iconic book, “Code Complete.” But wherever, exactly, it came from, the sound byte that dominates our industry is the “10x Developer” — the outlier developer archetype so productive as to be called a “rock star.” This seems to drive an endless debate cycle in the community as to whether or not it’s a myth that some of us are 10 or more times as awesome as others. You can read some salient points and a whole ton of interesting links from this jumping off stack exchange question.

Read More