DaedTech

Stories about Software

By

How to Deal with an Insufferable Code Reviewer

Time for another installment of reader question Monday.  Today, I’m going to answer a short and sweet question about how to deal with an “irksome” code reviewer.  It’s both simple, and fairly open ended, making it a good candidate for a blog post.

How do you deal with peer code review and irksome coworkers? Any trick?

Okay, first things first.  This could cover a lot of situations.

Theoretically, someone could be writing extremely problematic code and finding coworkers “irksome” simply for pointing that out.  And, at the complete other end of the spectrum, the code may be fine but a toxic culture creates endless nitpicking.

In environments like this, the code review becomes an adversarial activity, as much about political games as about code quality.

So you must introspect and also think in terms of your goals.  What is it that’s irking you, exactly, and what is the desired outcome?

I’ll frame the post roughly in terms of goals, and my advice for achieving them.  Really, that’s the only way to do it, since code review processes vary so widely from team to team.

A Bit of Perspective on Code Reviews and Code Reviewers

Before going into any advice, let’s consider the subject of code review itself.  There are two conceptual levels at play.

Obvious Level: A Practice with Demonstrable Benefit

A well-conducted code review process helps with code quality and it helps developers learn.  In his book Code Complete, Steve McConnell cited a study that found “formal code inspection” to be the most effective defect prevention method.

This put it ahead of even automated unit tests in the study.

But, beyond that, code review has important human ramifications as well.  People learn and share knowledge through this process.

And they use it to prevent the kind of defects that result in frustration for the team: rework, embarrassment and even a need to come in on weekends.  People with a stake in the codebase get emotionally invested.

Subtle Level: Small Kings in Small Kingdoms

There’s also another, more subtle element at play, however.

I talk extensively about these terms in my book, Developer Hegemony, but you can read a brief primer here.  Software developers (to my endless irritation) are pragmatists (line-level laborers) with almost no actual influence in the corporate world.

When you participate in the so-called “technical track,” you typically never have people reporting to you, earning only developmental titles that include things like “senior,” “tech lead,” and “architect.”

So often, the only simulacrum developers get of actual organizational power comes during interviews and code reviews.  Decent human beings handle this well, looking to mentor and teach.

But there are a lot of less-than-decent human beings out there, who relish these opportunities to wield what little power they have.  The phrase, “a little man with a little power” comes to mind.

An angry code reviewer

Read More

By

Are Code Rules Meant to Be Broken?

Editorial note: I originally wrote this post for the NDepend blog.  You can check out the original here, at their site.  While you’re there, take a look at the NDepend’s code rules.  Interested in me writing for your site?  Get in touch through our content marketing business.

If you’ve never seen the movie Footloose, I can’t honestly say I recommend it.  If your tastes run similarly to mine, you’ll find it somewhat over the top.

A boy from the big city moves to a quiet country town.  Once there, he finds that the town council, filled with local curmudgeons, has outlawed rock music and dancing.  So follows a predictable sequence of events as the boy tries to win his new town over and to convince them of the importance of free expression.  You can probably hear his voice saying, “come on, Mr. Uptighterton, rules are made to be broken!”

Today, I’d like to explore a bit the theme of rules and breaking them.  But I’ll move it from a boy teaching the people from American Gothic to dance and into the software development shop and to rules around a codebase.

Perhaps you’ve experienced something similarly, comically oppressive in your travels.  A power mad architect with a crazy inheritance framework.  A team lead that lectures endlessly about the finer points of Hungarian notation.  Maybe you’ve wanted to grab your fellow team members by the shirt collars, shake them, and shout, “go on, leave the trailing underscore off the class field name!”

If so, then I sympathize and empathize.  Soul crushing shops do exist, seeking to break the spirits of all working there.  In such places, rule breaking might help if only to shake people out of learned helplessness and depression.  But I’m going to examine some relatively normal situations and explore the role of rules for a software team.

Read More

By

Weaponized Mastery, Autonomy, And Purpose

Years ago, I published a post called How to Keep Your Best Programmers.  In it, I discussed what drives programmers out of jobs and what keeps them happy.  This discussion touched heavily on the concepts of mastery, autonomy, and purpose as important motivators for knowledge workers.  If you want to keep skilled programmers, you can’t just throw money and bonuses at them — you need to appeal to these other forms of motivation.

This post became quite popular and has remained so over the years.  I think the popularity results from the resonant idea of wanting our lives and careers to mean more than just a paycheck.  We want to be proud of what we do.

Since my own discovery of it years ago, I’ve seen frequent reference to these motivators and to Daniel Pink’s talk about them.  People use it to explain the difference between work that pays the bills and work that deeply satisfies.  More and more, we exhort our employers to appeal to mastery, autonomy, and purpose.  And more and more, they seem to do it, to our benefit and that of the industry at large.

But with this trend, I’ve noticed an interesting and unanticipated side effect.  People can appeal to autonomy, mastery, and purpose to enrich our lives, but they can also do so to manipulate us.

Mastery, autonomy, purpose -- they make us happy, but they can mesmerize us.

Mastery, Autonomy, and Purpose as Vices

To understand how that works, consider our desires in a different light.  Consider what happens when you take them to extremes.

We enjoy getting better at things (mastery), but that can lead to obsessive behavior.  I think most of us can relate, at some point in our life or another, to playing way too much of some kind of stupid video game.  We know it wastes our time and that we should probably delete it, but… just… one… more level.  Mastering the game drives us even when we know it wastes our time.

We also enjoy autonomy, but chasing that can lead to problems as well.  Have you ever known someone serially unemployed because they bristled at the thought of anyone telling them what to do?  Some people with that demeanor become entrepreneurs, but some become angry criminals.

And purpose as a vice can be, perhaps, the scariest of all.  Think about the phrase, “the ends justify the means.”  What is this if not a statement that purpose trumps all?  As long as you’re chasing a lofty enough goal, it doesn’t matter who you step on to get there.

We can chase mastery, autonomy, and purpose into problematic territory.  But other people can also use them to chase us there.

Read More

By

Why Expert Developers Still Make Mistakes

Editorial note: I originally wrote this post for the NDepend blog.  You can check out the original here, at their site.  While you’re there, take a look at the most recent version of NDepend with an assortment of features around visualizing tech debt.

When pressed, I bet you can think of an interesting dichotomy in the software world.  On the one hand, we programmers seem an extraordinarily helpful bunch.  You can generally picture us going to user groups, conferences, and hackthons to help one another.  We blog, record videos, and help people out on Twitter.

But then, we also seem to tear each other apart.  Have you ever hesitated before posting something on Stack Overflow?  Have you worried that you’ll miss some arcane piece of protocol or else that you’ve asked a stupid question.  Or, spreading our field of vision a little wider, have you ever seen nasty comment sections and ferocious arguments?

We programmers love to help each other… and we also like to rip each other to shreds.  What gives?

Reconciling the Paradoxical

Of course, I need to start by pointing out that “the programming world” consists of many, many human beings.  These people have personalities and motivations as diverse as humanity in general.  So naturally, contradictory behavioral tendencies in the population group can exist.

But let’s set that aside for a moment.  Instead, let’s try to squish the programming community into a single (if way over-generalized) human being.  How can this person be so helpful, but also so… rude?

The answer lies in understanding the protocol of helping.  The person presenting the help is an expert.  Experts enjoy explaining, teaching, offering opinions, and generally helping.  But you’d also better listen up the first time, pay attention to the rules, and not waste their time.  Or they’ll let you hear about it.

In the programming community, we gravitate toward conceptual, meritocratic ladder ranking.  Expert thus becomes hard-won, carefully guarded status in the community.  Show any sign of weakness, and you might worry that you’ll fall down a few rungs on the ladder.

Read More

By

The Polyglot’s Dilemma

Few things seem as institutional to the programming world as what I call the experience tuple.  A company needs to hire someone to automate something, so, naturally, it asks the software development group to make alphabet soup for dice.com.  “We need someone with (C#, XML, HTML, JS, ASP, MVC, REST, Angular, AJAX) with (React, MSTest, Moq, CSS) as plus.”  Presumably then, polyglot applicants stand a better chance.  But I’d argue that they also face something I’ll call the polyglot’s dilemma.

Hold on to your hats, programmers, because this will get counter-intuitive before it makes sense.  With that in mind… where to start?

Problem Solvers and Problem Transformers

Well, perhaps categorizing hired software developers as problems makes for a good start.  I don’t mean problems in a negative sense, but rather in the same vein as puzzles.  A business hires software developers for some broader purpose.  Maybe they work on internal automation that reduces operating expenses.  Or perhaps they produce software sold as a good or service and add to top line revenue.

In either case, the business implicitly says “I need help increasing our profitability.”  And you show up saying the following.

I have (8, 10, 10, 4, 6, 3, 1, 1, 0) years of (C#, XML, HTML, JS, ASP, MVC, REST, Angular, AJAX).  Now while the rest of you figure out how to make use of me, I’ll be over here sharpening the saw with some code katas.

Whenever I’ve had management responsibility, I’ve subconsciously put people into two buckets.  Problem solvers take a problem I have and make it go away.  Problem transformers take a problem I have and solve it by bringing me the next problem.  (I’m omitting non-performers who don’t solve problems at all as beyond the scope of this post.)

For instance, take the problem of a malfunctioning production server.  A problem solver would go off and come back with a functioning production server, somehow.  A problem transformer would come back, report that the problem was caused by a faulty power supply and ask what I wanted to do about that new problem.

As programmers, we behave as problem transformers.  We present ourselves and our skill sets as problems in need of management solutions.

Read More