Tag: Earn Trust

Trump Card

Trump Card

I’ve had the opportunity to perform a bunch of job interviews in the past couple of years. It’s been a tremendous learning experience, and I’ve enjoyed contemplating the various psychological factors that go into both interviewing and being interviewed.

My quip from a few days ago was mostly tongue-in-cheek (sorry, dear wife), but if you do want to impress me in an interview, take some time to tell me everything you don’t know. Yes, you read correctly. I want to hear about your ignorance.

You see, there’s a well-documented psychological phenomenon called the Dunning-Kruger effect. It’s a cognitive bias where the incompetent person, due to their incompetence, lacks the skill to evaluate their own shortcomings, and hence overestimates his own capabilities (the opposite effect is known as Imposter Syndrome). I’ve seen these play out time and time again as I’ve evaluated job candidates; in fact, I know of no quicker way to get a general sense of a person’s skill. Besides, describing shortcomings demonstrates humility and self-awareness, two valuable personality traits in any field.

The domain of software development is immense; no single person can possibly know even one-tenth of one percent of what can be known (we’re all only human). The best developers know this, and can describe the boundaries of their own knowledge. Those who cannot probably have no idea what they’re doing.

Developers Have Personalities

Developers Have Personalities

The first 12 years of my career I worked for a large defense contractor. One of the perks of a big company is opportunities for training, and in 2009 I had the privilege of taking a year-long “front-line” management class. Some of it was corporate drivel, but a surprising majority I found useful. One area of focus was on personality testing and analysis.

Why would that be of importance to managing a software team? Well, as I’ve said before, software is written by humans, and understanding how to get the best work out of said humans is a critical part of management. One way to do that is to learn the personalities of each member of the team.

During the training we used the Myers-Briggs Type Indicator, but the new hotness is the Enneagram. I’ve listened to a podcast and have also started a book on the topic, both of which were particularly focused on the spiritual aspects of self-understanding. But I think there’s plenty of cross-applicability to the world of management, and I look forward to exploring that in the coming days.

P.S. I walk the line between INTJ and INTP, and am either a Five or Nine (still figuring that one out).

More Pascal

More Pascal

“If we look at our work immediately after completing it, we are still too involved; if too long afterwards, we cannot pick up the thread again.”

A big challenge for managing a software development team is the problem of context switching. Interruptions in general are productivity-killers, and it’s especially true of a discipline that requires sustained focus like coding.

But in addition to small-scale interruptions (of the 5-15 minute variety), large-scale switching of priorities can also have a disastrous effect on productivity. I’m thinking here of diversions of the 1 day to 1 week variety. Frederick Brooks couldn’t have been more right:

“How does a large software project get to be one year late? One day at a time!”

(You have read The Mythical Man-Month, right? If not, get thee to a library immediately. It’s required reading for anyone in the software profession).

I do my best to take the above warnings to heart, but it can be tough in the day-to-day realities of production bugs and last-minute requests. One way I try to mitigate is to serve as the buffer between my team and these sorts of interruptions. No doubt there’s a huge cost to my productivity, but I can plan for that when I recognize it as a critical part of my role.

Pascal’s observation has a second application to software development, one held in tension with the “no interruptions” philosophy: sometimes a developer needs to take a break from her current tasking to get refreshed and refocused. This can play itself out in a number of ways, whether it be jumping from front-end to back-end development for a few weeks to avoid getting pigeon-holed, to taking a half-day to go through a tutorial on a new technology, to simply grabbing coffee for 30 minutes and getting out of the cubical. Project planners would do well to build in significant amount of “productive diversions” into their roadmaps, and front-line managers should not get grumpy when they don’t see developers at their keyboards 9 hours straight.

Ultimately my philosophy is simple: trust your team to be professionals, and let the results be your guide.