Archive for the ‘Philosophy’ Category

Crafting vs Untangling

Saturday, April 26th, 2014

One of the things I think a lot about during my day job is what motivates people to passion, particularly software developers working on a large integrated system. I’ve certainly learned a lot over the years about the differences between people’s worldviews and styles, and met many developers who derive their satisfaction from technical work in all kinds of ways that never would have even occurred to me.

The most interesting axis of differentiation I’ve run across is the spectrum between engineers who like to craft, build, and own new things on the one hand, and engineers who like to unravel deep and intricate mysteries on the other. These are not mutually exclusive, but I’ve found that everyone has a comfortable spot somewhere on the continuum where they can derive maximum joy from their time spent at work.

Build from scratch

Engineers who are fundamentally crafters have a┬ásimilarity to the stereotype of a “startup developer” – the desire to be in on the ground floor, see the fruits of your labor, and have a big hand in the direction of a product. Pride of ownership is a big part of job satisfaction, and being publicly viewed as the creator of something is a deeply satisfying ego boost for these folks. They tend to enjoy demoing their feature and working with customers to implement it, even when those become long tasks that take them away from future programming.

Reveal the mystery

On the other hand, engineers who are problem solvers at heart find pride in their ability to understand what no one else can, and dig to the heart of an existing issue more quickly than other people. They can thrive on pressure and get their joy from the “aha” moments that happen in private, as another layer of the puzzle falls away and they reach deeper understanding. These folks can easily be happy doing systems programming on a large codebase, where there is complexity by the truckload for those with the desire to untangle it.

Be true to yourself

My (limited) experience has been that the majority of programmers fall into the first camp. The desire to craft brand new seems to spring naturally out of the engineering mindset, so this tends to be the comfortable mode of working for computer science students and new graduates. The ability to self-identify on this spectrum and choose work that best fits your personal bent is an under-appreciated talent that more software developers should spend time honing. I expect that reaching a better understanding of this concept would be helpful for most developers’ job satisfaction and avoid burnout or boredom that might otherwise be unexplained.

 

Trustworthy Advice and Mental Process

Monday, May 13th, 2013

We just got back from a trip to Alaska, and in a moment of vacation-induced clarity and relaxation, I discovered a gap in my mental model that I didn’t know existed: I don’t have a process to go back and ‘edit’ the trustworthiness of advice when I later┬álearn that the advice-giver is untrustworthy. I found this to be a pretty fascinating brain problem and I’m enjoying thinking about solutions to it.

Here was the scenario:

  1. We get on a tour bus to see the cultural history of Ketchikan. I give the tour guide the benefit of the doubt and assume he’s an informed guy since he’s worked here for 6 years giving the same tour.
  2. As we drive around the touristy parts of downtown, he points out a candy shop that sells chocolate-covered oreos and says that they’re delicious. At this point I’m assuming he’s correct and I’m envisioning something gooey, melty, and decadent. We plan to go get one once the tour is over.
  3. The tour goes on for a few hours, and our guide proceeds to toss his credibility out the window bit by bit. We learn interesting cultural nuggets like: “Bill Clinton signed an act to create the Tongass National Forest Preserve in the 1970s”, “There’s a boat stuck in the mud, must have been stranded at low tide”, and “Here’s Ketchikan’s tanning salon.” It becomes apparent pretty quickly that he’s not exactly the man for the job.
  4. Afterwards we still go to the candy shop to try a chocolate-covered oreo. It’s pretty terrible, unfortunately – just bland confectioner’s chocolate crusted onto a regular oreo out of a package. Not exciting in any way.

As I’m eating the disappointing oreo, I realize that I’m not at all surprised that the tour guide’s recommendation was poor and not well-thought-out… but the problem was, once I learned that his credibility was low, I never went back and added any suspicion to my mental concept of “we should go get a chocolate-covered oreo”. I’m fairly confident I would have been hesitant if he’d mentioned it at the end of the tour, but it never even occurred to me that it was an issue because I had already filed away the original fact before ever learning that he was untrustworthy.

This was a fairly scary realization for me; it seems likely that I’m leaving context clues on the table when taking advice from people and then acting on it much later. Fortunately it’s rare for my opinion of someone’s trustworthiness to drop so significantly, but I suppose it must happen sometimes. I’m not sure that I always even maintain the link between the nugget of information and the person who told it to me, depending on how much time has passed.

So far the best solution I’ve come up with is to focus specifically on the problem case: a major drop in the trustworthiness of someone I’ve met. If I run into a scenario like this, I hope to go back in short-term memory and do the editing based on that index while I still remember more details about the linking. This seems like a more pragmatic use of mental energy than trying to remember who told me each piece of information for eternity, but it doesn’t handle the case of a trustworthiness drop far into the future once short-term memory is exceeded. I’m not sure I have a viable solution for that scenario other than increasing my general skepticism up front, which I’m very hesitant to do.