DaedTech

Stories about Software

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

Manual Code Review Anti-Patterns

Editorial Note: I originally wrote this post for the SubMain blog.  You can check out the original here, at their site. While you’re there, take a look around at some of the other posts and at their offerings.

Today, I’d like to offer a somewhat lighthearted treatment to a serious topic.  I generally find that this tends to offer catharsis to the frustrated.  And the topic of code review tends to lead to lots of frustration.

When talking about code review, I always make sure to offer a specific distinction.  We can divide code reviews into two mutually exclusive buckets: automated and manual.  At first, this distinction might sound strange.  Most reading probably think of code reviews as activities with exclusively human actors.  But I tend to disagree.  Any static analyzer (including the compiler) offers feedback.  And some tools, like CodeIt.Right, specifically regard their suggestions and automated fixes as an automation of the code review process.

I would argue that automated code review should definitely factor into your code review strategy.  It takes the simple things out of the equation and lets the humans involved focus on more complex, nuanced topics.  That said, I want to ignore the idea of automated review for the rest of the post.  Instead, I’ll talk exclusively about manual code reviews and, more specifically, where they tend to get ugly.

You should absolutely do manual code reviews.  Full stop.  But you should also know that they can easily go wrong and devolved into useless or even toxic activities.  To make them effective, you need to exercise vigilance with them.  And, toward that end, I’ll talk about some manual code review anti-patterns.

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

Choosing Among Text Editors and IDEs

Editorial Note: I originally wrote this post for the Monitis blog.  You can check out the original here, at their site.  While you’re there, take a look at their offerings for monitoring all of your production concerns and infrastructure.

Few subjects in programming can get as contentious as quickly as, “what should I use to edit my code?”  Before you even get to the subject of “which one,” vigorous debates emerge over “what kind?”  This cordial Quora question with roughly 6 billion answers serves as an example of this.  Text editor or Integrated Development Environment (IDE)?

Only after that perilous decision do you arrive at the “which one debate.”  So furious has this debate proved that Wikpedia has an “Editor War” entry.  It describes the choice between the Emacs and VI editors.  The usage of “war” is a joke.  But only kind of.

So against this backdrop, you might regard the choice as one fraught with peril.  Pick incorrectly and risk the scorn of your peers.  That’s a joke.  But only kind of.

Fortunately, for the purposes of guidance, at least, I count myself a pragmatist mercenary.  In other words, I come from the relatively small camp of software developers without much strong preference about any of it.  I have spent years with each of the following: Visual Studio, Eclipse, IntelliJ, Emacs, Pico, Nano, Scite, SublimeText and Notepad++.  And I’m probably forgetting some.  All have their perks and foibles, but I prefer to keep my options open and let context guide me.

So, face with the need to pick new tooling, how should you handle it?  Today, I’ll offer some advice on heuristics for selecting an IDE or text editor.

Make a Quick List of Your Needs

First things first.  Do what you would do when contemplating any sort of consumer decision.  Make a list of your needs and wants.

For instance, say you were buying a refrigerator.  You’d need a certain size to fit your space, and you’d need a certain amount of storage capacity.  You might then want a chrome finish and an ice maker.  Contemplate the tool you’ll use for writing code in this same fashion, for starters.  You may have non-negotiable needs around operating system and programming language, and more fluid wants around features.

But also bear in mind context.  For example, do you specifically need a tool to work on one specific project at the office?  Or do you want something versatile that you’ll use everywhere, across various languages and technologies?

Now, combine these two lines of thinking and you will probably have narrowed the field considerably.  And you need to narrow the field, since a surprisingly daunting number of options exist out there.  Easier to choose among 2 or 3 than from hundreds.

Read More

By

Automation and the Art of Software Maintenance

Editorial Note: I originally wrote this post for the SubMain blog.  You can check out the original here, at their site.  While you’re there, check out CodeIt.Right for automating your code review process.

I have long since cast my lot with the software industry.  But, if I were going to make a commercial to convince others to follow suit, I can imagine what it would look like.  I’d probably feature cool-looking, clear whiteboards, engaged people, and frenetic design of the future.  And a robot or two.  Come help us build the technology of tomorrow.

Of course, you might later accuse me of bait and switch.  You entered a bootcamp, ready to build the technology of tomorrow.  Three years later, you found yourself on safari in a legacy code jungle, trying to wrangle some Sharepoint plugin.  Erik, you lied to me.

So, let me inoculate myself against that particular accusation.  With a career in software, you will certainly get to work on some cool things.  But you will also find yourself doing the decidedly less glamorous task of software maintenance.  You may as well prepare yourself for that now.

The Conceptual Difference: Build vs Maintain

From the software developer’s perspective, this distinction might evoke various contrasts.  Fun versus boring.  Satisfying versus annoying.  New problem versus solved problem.  My stuff versus that of some guy named Steve that apparently worked here 8 years ago.  You get the idea.

But let’s zoom out a bit.  For a broader perspective, consider the difference as it pertains to a business.

Build mode (green field) means a push toward new capability.  Usually, the business will regard construction of this capability as a project with a calculated return on investment (ROI).  To put it more plainly, “we’re going to spend $500,000 building this thing that we expect to make/save us $1.5 million by next year.”

Maintenance mode, on the other hand, presents the business with a cost center.  They’ve now made their investment and (at least partially) realized return on it.  The maintenance team just hangs around to prevent backslides.  For instance, should maintenance problems crop up, you may lose customers or efficiency.

Read More