DaedTech

Stories about Software

Jul
25

By

Weaponized Mastery, Autonomy, And Purpose

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

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

Jul
24

By

APIs and the Principle of Least Surprise

Category: Language Agnostic Tags: , , | 6 Comments

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, have a look at some of the other authors for their blog.

I remember something pretty random about my first job.  In my cubicle, I had a large set of metal shelves that held my various and sundry programming texts.  And, featured prominently on that shelf, I had an enormous blue binder.

Back then, I spent my days writing drivers and custom Linux kernel modules.  I had to because we made use of a real time interface to write very precisely timed machine control code.  As you might imagine, a custom Linux kernel in 2005 didn’t exactly come with a high production quality video walking users through the finer points.  In fact, it came with only its version of the iconic Linux “man pages” for guidance.  These I printed out and put into the aforementioned blue binder.

I cannot begin to tell you how much I studied this blue binder.  I pored through it for wisdom and clues, feeling a sense of great satisfaction when I deciphered some cryptic function example.  This sort of satisfaction defined a culture, in fact.  You wore mastery of a difficult API as a badge of honor.  And, on the flip side, failure to master an API represented a failure of yours.

Death of “Manual Culture”

What a difference a decade makes.  No longer do we have battleship gray windows applications with dozens of menus and sub-menus, with hundreds of settings and thousands of “advanced settings”.  No longer do we consider reading a gigantic blue documentation binder to be a use of time.  And, more generally, no longer do we put the onus of navigating a learning curve on the user.  Instead, we look to lure users by making things as easy as possible.

Ten years ago, a coarse expression described people’s take on this responsibility.  I’ll offer the safe-for-work version: “RTM” or “Read the Manual.”  Ten years later, we have seen the death of RTM culture.  This applies to APIs and to user experiences in general.

Read More

Jul
23

By

Manual Code Review Anti-Patterns

Category: The Life of a Programmer Tags: , |

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

Jul
21

By

DaedTech Now Brought to You Over SSL

Category: Announcements |

I’ve had an item on DaedTech’s Trello board for a good, long time now.  Switch over to using SSL.  And, fear not those of you who enjoy this blog!  You can now browse confidently, without worrying that some impostor is feeding you misinformation about expert beginners, journeyman idealists, and other random neologisms that come out of my twisted mind.  Take that, internet evildoers.  I can almost sense everyone’s relief from here.

What Does This Actually Mean?

I started to call this header, “How SSL works,” but I got bored before I even finished typing that sentence fragment.  You can read a primer about it, if you’re so inclined.

The 10,000 foot explanation is that it’s a mechanism for making your browsing a private conversation between you and DaedTech.  For instance, say that you were sitting in an airport a week ago, and you browsed to my blog.  Your HTTP request and DaedTech’s response would happen in plain text.  Anyone else in the airport sufficiently motivated to do so could eavesdrop on the back end forth and even execute a man in the middle attack.  As I said before, they could have deliberately fed you misinformation about expert beginners.

Or, perhaps more importantly, they could eavesdrop on your credentials if you had an account on my blog.  That’s really the idea of SSL — it aims to make communication private and not subject to these sorts of interposition and alteration schemes.  By installing SSL on my site, I have now prevented that from happening.  When you browse DaedTech, you now do so over HTTPS, all communication encrypted and my SSL certification verified.  This latter concern means an outside agency says, “you can believe that this is DaedTech and not an impostor.”

Contrary to the green locks and the “secure” wording in the URL bars, however, this does necessarily mean “you’re all good.”  Scott Hanselman summed this up well in a tweet.

Read More

Jul
20

By

A Look at the History of RDBMS

Category: Language Agnostic Tags: |

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 Monitis’s offering for all things related to website and networking monitoring.

If you had to pick a unifying technology to bring all developers together, then you could do worse than selecting the relational database.  Of course, no topic can truly unify all developers.  But most of us that have written code for any length of time, have at least dealt with a database in some capacity or another.

And, why not?  We could boil software down to two core components: data and behavior.  So, just as we all learn programming languages to express behavior, we also learn some means of recording and persisting our precious data.

When we put enough of this data together in some organized format, we have a database.  When we organize that database in a manner known as “relational,” we have a relational database.  And then, when we add functionality for managing and optimizing access to that relational data, we have a relational database management system (RDBMS).

No doubt you have some familiarity with these products.  They include such industry mainstays as Oracle, Microsoft’s SQL Server, PostgreSQL, and MySQL, among others.

In fact, they blend so seamlessly into the scenery that you can easily take them for granted.  But where did they come from and why?  And, how have they evolved over the years?  Today, let’s take a look back at the history of the RDBMS.

Read More

« Older Posts
Newer Posts »