DaedTech

Stories about Software

By

Prerequisites for Effective Code Review

Editorial Note: this is a post that I wrote originally for the SmartBear blog.  You can read the original here, at their site.  You should check out the posts by some of the other authors over there as well.

I’m betting that, at some point in your travels, you’ve seen a blog post or a document in a software shop that details prerequisites for good code review. It probably contains items like, “make sure you’ve run all the unit tests” and “make sure you’ve given the reviewer(s) enough notice.” This information certainly has value, but it’s not what I want to talk about today.

Today, I want to talk about prerequisites for effective code review culture, rather than prerequisites for an actual code review. The question thus is not, “are you prepared for this code review?” but rather “is your group prepared for code review, in general, to be as effective as it can be?”

Asking a question like this makes sense, if you stop and think about it.  A director of software engineering can’t one day stroll through her group’s team space, declare, “Alright, folks, start doing code review,” and expect awesome productivity to follow straightaway.  Various elements of preparation are necessary, first.

DreamJob

Read More

By

Escaping the Legacy Skill Quicksand

Editorial note: The readership of this blog has been growing steadily, and I very much appreciate that.  Thanks for reading!  An enjoyable byproduct of this is that a lot of my posts these days generate a good deal of discussion in the comments.  The only downside of this is that it’s growing harder and harder for me to respond to all of them.  Disqus sometimes batches my email notification, and there are days when people are commenting on half a dozen or more different posts, so I lose some in the shuffle.  For my regular readership, if I miss something you say, please don’t think it’s for lack of interest.  If you really want to get my attention or thoughts on something and you don’t see a response, feel free to email me or reach out through the site’s reader questions section.

Now, speaking of reader questions, let’s do one of those.  I was originally going to do a ChessTDD post today, but tornadoes were ripping through the Louisiana countryside like a vengeful wolverine today.  The end result was that I didn’t really have the time or guaranteed power to sit at my recording and development desktop.  I’m going to paraphrase today’s question so as not to have anything identifiable in there.

LousianaTwister

I’ve been working at a product company, focused mainly on specific, entrenched database technologies.  This is causing me to lose touch with current languages and trends, and I’m worried that I’m getting stuck.  How can I avoid being stuck and becoming an Expert Beginner?  Can you offer tips on learning new languages and exploring other technical things?

First of all, let me say this.  Asking yourself, “am I becoming Expert Beginner” is like an inverted Catch-22.  An Expert Beginner wouldn’t engage in this sort professional introspection.  That said, it is certainly possible to become pigeonholed into an unmarketable, aging technology.  I’m sure someone out there reading is, and has for a long time been, “the VB6 guy” and that person is nodding ruefully.  That’s a position that becomes harder and harder to climb out of.

At the core of this discussion is a debate I’ve seen play out an awful lot among people in the software world: is it up to your employer to help you stay current or is it up to you to do this in your spare time?  I’ve seen this debate play out most ferociously in the context of the mildly pejorative “9-5 programmer” used to describe people who are in it for money rather than the love of the game.  One side says “real programmers do it all day for work and all night for fun” and these folks are more likely to say that keeping current and managing your career is your business, to be managed on your own time.  The other side says, “programming is a job, and part of the deal with a wage job is that your employer empowers you to stay current.”

Read More

By

Killer CEO Interview Questions

I’d like to have a little fun for this Friday post.  I’m sitting on a plane, where I paid for wifi to take care of a few late in the day items.  Those took less time than I was expecting, so instead of the cross-post I was planning, I’m going to do this post.

Someone on twitter linked to this article, and Rands had previously linked to it, so I thought it must be worth a read.  It’s titled, “We got 10 CEOs to tell us their one killer interview question for new hires,” so I immediately thought, “Rands… why?!”  Off the cuff, it seemed like a standard Buzzfeed piece, filled with typical interview mythology where we’re asked to assume that something is profound because Warren Buffet asked it, or something.

As I read through it, though, something struck me.  Most articles like this are written by corporate pragmatists, for corporate pragmatists.  As such, they are ispo facto not interesting from a realpolitik perspective.  They are, to draw on Gervais Principle lexicon, gametalk.  “‘What’s your greatest weakness,’ should be answered with, ‘well, try to find a way to describe a strength as if it were a weakness!'”  Thanks for that insight, Dale Carnegie!

But as I read the article, it dawned on me that there were potentially non-zero stakes, and that these were actually questions that opportunists might gamely pose to other opportunists.  In other words, this isn’t “CEO says that these are questions grunts should be prepared to answer when asked by grunt-managers.”  Instead, it’s, “this is something I would ask a C-level person because I would find the answer interesting.”  (And finding the answer interesting might be entirely orthogonal to a hiring decision).

FriendlyBoss

So here are the questions, along with what I’d posit as the right answer from any self-respecting opportunist (answers in normal print, commentary in italics).

Read More

By

We’re Not Beasts, So Let’s Not Act Like It

If I were in the kind of blogger that sought readers via click gimmicks, I might title this post, “In Business, You’re Either a Partner or an Asset.”  Actually, on reading that, it still wouldn’t exactly be juicy click bait, but it’d at least be less nuanced and more provocative than my actual point here.  Maybe.

On Cats and Humans

Rather than get to the point, I’ll lead with a parable of sorts.  Let’s say that I were an aspiring entrepreneur in the death market, and that I were interested in “niche-ing down.”  I wanted to start an extermination business, and, specifically, a mouse extermination business.  You’ve got mice?  Call Erik — the mouse-killer.

Toward this end, I establish two distinct service products.  The first is that I’ll dispatch a mouse-removal expert to your house to take a more-or-less scientific approach to mouse removal.  This person will wander around your house, doing whatever it is that exterminators normally do, dispatching poison and such.  This will cost you $100 per hour.  The second service product is that I’ll rent you a cat for $15 per day.  The cat will wander around your house, doing whatever it is that cats normally do, which presumably includes chasing and sometimes killing mice.

The difference in price is significant, but it also makes sense.  The exterminator, while onsite, will focus in laser fashion on your mouse problem.  He’s basically a consultant, dedicated to helping you with your mouse problem.  His time is valuable.

The cat, on the other hand, will do whatever it wants.  It will arrive onsite and most likely take a nap.  It will then wake up, meow for food, wander around the house, purr and put its anus near your face, spend a weird amount of time sniffing a couch cushion, and then, maybe, take an interest in the scrabbling sound in your wall that represents the mouse problem.  Or, maybe it won’t.  Maybe you’ll just have to wait until tomorrow or the next day.  Eventually, the cat will be sufficiently interested to do something about the mice, but that’s clearly going to proceed according to the cat’s calendar and not yours.

CattButt

Read More

By

What To Avoid When Doing Code Reviews

Editorial Note: I originally wrote this post for the SmartBear blog.  You can see the original here, at their site.  Go on over and check out their site!

Years ago, I had a senior software developer role in a shop where code review was part of the standard workflow. The way the review process worked was that anyone writing code had to submit the code for review to one of the senior developers of their choosing.

Over the course of time, I began to notice something interesting and a bit flattering: I was picked a lot to do reviews.  When I first got an inkling of this trend, I simply thought I was flattering myself, but then I started to keep track and I realized that there was a definite trend.  What was going on?

Was I an “easy grader” or a pushover?  Was it just by chance?  Was it that people thought I was some kind of legendary, super-developer?  Turns out it was none of these things.

Midas

In search of the answer, I started to pay more attention to the nature of code reviews offered by other senior developers.  In doing this, I came to realize that the answer lay not as much in what I was doing, but in what they were doing.  Specifically, they were doing things that I wasn’t doing, and those actions were causing others to seek out my reviews.

This phenomenon was revealing to me, so I made a point to pay attention to the actions of different reviewers among the senior developers, and line them up with how much people sought out or avoided them for code review.  Making these observations taught me valuable lessons about what to avoid when doing code reviews.

Read More