DaedTech

Stories about Software

Feb
26

By

Prerequisites for Effective Code Review

Category: The Life of a Programmer Tags: , | 4 Comments

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

Feb
18

By

High Stakes Programming by Coincidence

Category: The Life of a Programmer Tags: | 5 Comments

Editorial note: I originally wrote this post for the Infragistics blog.  Click here and check out the original at their site.  There are a number of authors worth checking out that write for them.

Have you ever found yourself running your code to test out some behavior when you noticed something unrelated and thought, “that’s odd?”  Maybe you wanted to verify that clicking “run” kicked off the process it was supposed to, but you noticed that the “cancel” button was randomly green for a second when the window opened.  “That’s odd,” you thought.

After verifying that the process was kicked off properly, maybe you re-launch the application to see about that odd, green cancel button.  But when you open the window this time, nothing.  It’s the normal color, with no sign of the green you noticed before.  Again, you thought, “that’s odd.”  And maybe, at that point, you shrugged, chalked it up to some weird OS rendering burp, and moved on.

ProgrammingByCoincidence

You never knew why the button went green, and you never knew why you couldn’t reproduce it.  This is a relatively benign version of the phenomenon known as “programming by coincidence.”

“Programming by coincidence” was coined in the book, “The Pragmatic Programmer,” and they define it as “[relying] on luck and accidental successes” rather than programming deliberately.  In the case of the mysteriously green button, the accidental success is the fact that the problem just kind of vanished on its own.

It’s probably no great surprise that the Pragmatic Programmer’s stance on programming by coincidence is “don’t do it.”  It’s my stance as well, and I imagine a lot of you reading agree.  And yet, it’s something we’ve probably all been guilty of at one time or another. Read More

Feb
11

By

Mistakes Dev Managers Make

Category: The Life of a Programmer Tags: , | 35 Comments

Editorial note: I originally wrote this post for the NDepend blog.  You can check out the original here, at the site.  If you like this post, head on over, and check out more at the site.

Managing a team of software developers is a tall order. This is doubly true when the line management includes both org chart duties (career development, HR administrivia, etc) and responsibility for the team’s performance when it comes to shipping. In this case, you’re being asked to understand their day to day performance well enough to evaluate their performance and drive improvement, in spite of the fact that what they do is utterly opaque to you. It’s like being asked to simultaneously coach a team and referee the game for a sport whose rules you don’t know. As I said, a tall order.

I’ll grant that, if you’re a manager, you may have been technical at some point, perhaps even recently. Or maybe not, but you’ve been around it long enough to pick up a lot of concepts, at least in the abstract. But in neither case, if you were asked what, exactly, Alice coded up yesterday, would you be able to answer. Whether it’s due to total lack of experience, being “rusty” from not having programmed in a number of years, or simply being unable to keep up with what 8 other people are doing, their work is opaque to you.

As with coaching/refereeing the game that you don’t understand, you can pick up on their body language and gestures. If all members of the team appear disgusted with one of their mates, that one probably did something bad. You’re not totally without context clues and levers to pull, but it wouldn’t be hard at all for them to put one over on you, if they were so inclined. You’re navigating a pretty tough obstacle course.

And so it becomes pretty easy to make mistakes. It’s also pretty understandable, given the lay of the land. I’ll take you through a few of the more common ones that I tend to see, and offer some thoughts on what you can do instead.

Micromanagement

The opacity of the development team’s labor creates a situation in which it’s easy to feel as though you don’t have control.  And a perfectly natural impulse in such a situation is to overcompensate and try to exert as much control as possible.  The overwhelming majority of folks that micromanage don’t think to themselves, “I want to be an insufferable control freak,” but rather something along the lines of, “I just need to get really involved for now while we’re facing this deadline, and then I’ll back off when things settle down.”

GrabbingTheWheel

Read More

Feb
5

By

Killer CEO Interview Questions

Category: The Life of a Programmer Tags: | 3 Comments

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

Jan
31

By

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

Category: The Life of a Programmer Tags: , | 6 Comments

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

« Older Posts
Newer Posts »