DaedTech

Stories about Software

Nov
22

By

Your Coworker’s Bad Code: Having The Hard Conversation

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

Editorial Note: This post was originally written for the SmartBear blog.  You can check out the original here, on their site.  If you’ve never had the chance, take a look at their blog in general.  A lot of good authors over there.

Last time, I talked about how to prepare for a tough conversation with a coworker about having bad code.  This included understanding what not to say and creating a game plan of specific shortcomings to address and concrete outcomes you want from the conversation.  This time, I’m going to talk about how to actually engage with your teammate, who I’m calling “Bob.”

Engage

Having built your case ahead of time, it’s time to go have a chat with Bob. You’re calm, you’re rational, you have a legitimate argument, and you’re all set for a constructive dialog…but the lead in for the conversation threatens to be awkward. What I’d suggest doing to put the conversation in more natural terms is to ask for his help. “Hey Bob, I’m chasing a defect through the code and it led me to this method of yours. It’s a little hard to follow at first glance, so I was hoping maybe we could trace through it together?” Now you’re not coming over to preach to Bob about the evils of his code but rather to ask him to help you solve a problem.

Once you’re looking together at a screen and starting to dig in, one of the most effective ways I’ve found to surface code problems is through the Socratic Method. Instead of telling Bob that the method is too long, ask a series of questions. “Wow, good thing you’re here—this is a pretty long method with a lot going on. How long do you think it would take the average team member to understand it?” “Huh, wow, three or four hours seems like a pretty long time to spend trying to understand a method, don’t you think?” “What if it were smaller?”

Socrates0001

Making proclamations of fact or strongly stating opinions tends to put people in a defensive posture. Asking questions, even leading ones, doesn’t get people’s hackles up as much. They tend to join you in problem-solving mode rather than argue against you in debate mode. Still, asking questions this way may not lead to the desired outcome, which is why you’ve done your homework. Switch gears from the questions to statements of your experience and how you feel. These are inarguable. Read More

Oct
25

By

How to Address Your Coworker’s Bad Code (Part 1)

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

Editorial Note: This post was originally written, some months back, for the SmartBear blog.  You can read the original at their site, and. while you’re at it, I recommend checking out other posts there as well.  There are a lot of good authors over there, and I’m flattered to be included with them.  This is part 1 of 2.  I’ll publish 2 here later as well, but it’s already published on their site if you want to read it immediately.

Ugh. You’re sitting at your desk, trying to chase down a bug that’s been reported, when it happens. The hunt takes you into some method that inspires you to do a double take. It’s about 1,200 lines long, it has switch statements nested three deep, and you think (but aren’t sure) that it does the same thing two or three times in a row for no particular reason. You look at the source control history, see that this is another “Bob special,” and start thinking about finally having a long overdue talk with Bob so that you don’t have to keep cleaning up these messes. That sure won’t be a fun talk. So how do you approach it?

ScaryComputer Read More

Sep
15

By

Make the Complex Simple

Category: The Life of a Programmer Tags: , |

For many years, I associated the concept of “making the complex simple” with teaching. And that’s certainly not wrong. We’re in an industry filled with complexity, both essential and accidental. To survive in this industry requires understanding essential complexity and eliminating accidental complexity, and novices struggle with this. As developers become self-sufficient, they figure out complexity reduction enough that they can mentor others in the concept. Once they get to the point of teaching concepts pretty seriously — giving conference talks, creating courses, coaching, etc. — it can definitely be said they’ve become good at “making the complex simple.”

Of course, it could also be said that the term applies to communications with non-technical stakeholders and not just teaching inexperienced developers. Think fast — how would you explain to the CIO who doesn’t have a programming background why you should stop delivering features for a couple of weeks in order to retrofit an IoC container onto your codebase? If you start saying things like “inject your dependencies” and “switch your database driver without recompiling,” you’re keeping the complex complex as the CIO stares blankly at you. Making it simple isn’t easy, is it?

To take complicated concepts and communicate them simply, with minimized loss of pertinent information, is a skill you could (and should) spend a lifetime improving. It requires overcoming the curse of knowledge, understanding your subject matter extensively, knowing your target audience’s world fairly well, being  adept at mapping concepts and creating analogies, communicating clearly and, oh yeah, often doing it all off the cuff. Piece of cake, right?

Hard though it may be, it’s a skill worth developing.

I originally wrote this post for John Sonmez’s site, Simple Programmer.  Click here to read the rest of my argument as to why you should develop this skill.

Jul
29

By

Who Accepts Your Team’s Academy Awards?

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

I was listening to the Smart Passive Income podcast the other night. Yeah, I wasn’t kidding. I’m really trying to figure out how to do this stuff. Anyway, it was an episode with “User Stories” in the title, so I was intrigued. What I actually thought to myself was, “I’m a lot more inclined to hear stories about passive income than about Scrum, but this could be interesting!” And, it actually was interesting. I mean that earnestly. The episode was about Pat commissioning an IOS app for his podcast, so anyone making a living in our industry would be somewhat intrigued.

The episode started, and I listened. Admittedly, beyond Pat, I don’t exactly know who the players are, but I can tell you what I inferred as I was jogging (I frequently listen to podcasts when I jog). The interview started, and Pat was talking to someone that seemed to have a project-manager-y role. Pat asked about the app, and the guest talked about communication, interactions, and the concepts of “user story” and “product backlog.” He didn’t actually label this process Scrum until much, much later in the interview, and I get that – he’s talking to a huge audience of potential clients, so it’s a lot more compelling to describe Scrum as if it were something he thought of than it is to say, “oh yeah, we do Scrum – go google it!”

LeaderSpeaker

I don’t begrudge him that in the slightest. It’s a savvy approach. But it did strike me as interesting that this conversation about an app started with and centered around communication and planning. The technical decisions, data, and general nuts and bolts were all saved for later, delegated to a programmer underling, and framed as details that were definitely less relevant. In the development of this app, the important thing was the project manager, who he talked to, and when he talked to them. The development of the app was a distant second.

My reaction to this, as I jogged, was sad familiarity. I didn’t think, “how dare that project manager steal the show!” I thought, “oh, naturally, that’s a project manager stealing the show – that’s more or less their job. Developer code, not know talk human. Project manager harness, make use developer, real brains operation!”

Read More

May
21

By

Are Your Meetings Worth Attending?

Category: The Life of a Programmer Tags: |

“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.

CodeReview

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.

« Older Posts
Newer Posts »