On The Value of Naive Inquisitiveness
Few experiences are as panic-inducing to a geek as viewing an error message during reboot right after trying to “fix” the computer.
As a child, I once got in my head that I needed to organize the files on my dad’s Mac. In my mind, “organize” meant make sure that all the files were aligned to a grid, nice and square. This would have been a pretty achievable and low-risk goal, except for one pesky uncooperative folder. For some reason, this one folder had some two files that, no matter what I tried, wouldn’t align to a grid. Naturally, I tried deleting them (the obvious first approach to solve this problem), but they always came back, unaligned, taunting me. After a few weeks of this, I found a utility which claimed it could delete anything. I tried it and, sure enough, it really deleted them. Folder organized! Mission accomplished!
Except that when I rebooted the computer it wouldn’t even turn on. Turns out that my dad had the entire hard drive encrypted by Nortons SomethingOrOther, and I had found my way to the system folder and deleted the two files necessary to decrypt the computer. Whoops.
My dad was pretty torqued about this, naturally. I was banned from using a computer ever again. In a moment of clarity (the likes of which I never experienced again, unfortunately), I put forth the following argument: If he wanted to ban me, he should have done it earlier. Now that I’ve screwed up, though, I know what I did wrong, and I won’t do it again.
He thought about it, agreed, and reversed the ban.
That happened over 20 years ago, and the experience resonated with me pretty powerfully. You can’t be afraid of the computer. Try things, and even (sometimes) break things, but be willing to poke around and see what you can do. I’ve learned that you have to respect the machine, the same way you respect anyone; if you don’t know what you’re doing and the machine tells you not to do something (e.g., deleting a crucial file); don’t do it until you’ve researched enough to understand what you’re doing and know the consequences. Sure, you’ll break things occcasionally, but you’ll learn to make those experiences less painful (backups!) and you’ll fix them, and you’ll learn things along the way.
It’s a general life lesson, which applies equally to this situation: if you replace “fear of unknown” with “respect for unknown”, you’ll learn things you never thought possible.
The Inestimable Value of the Posthoc Review
Few events provide the raw satisfaction and relief as the completion of a large project. You’ve been working on something for months, keeping track of dozens of details, monitoring timelines, considering all the possible ways that things can go wrong, and now it’s all finished. Sure, there’s going to be bugs that crop up after the fact. Undoubtably, there will be questions, training, support, feature requests, refactoring, and all the other stuff that goes on with supporting released software and development of the inevitable 1.0.1 bugfix release. Even so, there’s still a wonderful feeling of satisfaction that comes with the sending of the “we’re live!” email.
Right after release, the most important task is to celebrate. Working on any project that will eventually be released to the public is often be highly stressful, and an environment that doesn’t celebrate it’s successes is a sad one indeed.1 However, when the party’s over, your next most important job is to perform an informal post-hoc review. Depending on the complexity of the task and the number of people involved, this can take anywhere from a half-hour to a few days. No matter what, though, you should perform this review… the yield from this nigh-negligible time commitment is immeasurable. Some of the benefits we’ve seen in our group:
- Clear the air: Long group projects bring out both the best and the worst in everyone. By providing an outlet for criticism—both good and bad—you help keep everyone sane and, hopefully, in good spirits. In our experience, we had lots of comments (positive and negative), and the atmosphere of “we’re here to make sure we do an even better job next time” helped avoid anyone taking anything personally.
- Improve trust: People generally want to do a good job. The posthoc will result in clear opportunities for improvement for everyone, which when executed upon will help build a more cohesive, trusting team. (Do note, though, that by doing a posthoc you are committing to executing on the feedback. If you don’t, you will not only lose all credibility, but you’ll be acting kinda like a jerk. Don’t be that guy.)
- Know thyself: I love Donald Rumsfeld’s “unknown unknowns” quote, and this helps me take it to heart. Discussing the groups (and my own) strengths and weaknesses helps us improve as a team and as individuals.
During one posthoc performed by our group after the recent completion of a project, the discussion was so beneficial that it not only recharged everyone on the team, but led to us tackling the next projects with a renewed energy, knowing that we’re getting better each time.
Our posthoc had only one rule: comments must be directed at tasks/processes, not people. Even failures on a one-man task may have been due to poor task assignment or lack of support from group rather than individual shortcomings. The posthoc is the place for group discussion on group efforts, not group discussion on individual performance.2 When the discussion is over, the group should know where the group succeeded and where the group failed.
The actual execution of the posthoc was straightforward:
Before the discussion, we compiled a list of aspects of the project we wanted to review. For us, this included the following:
- Technology: Did we use the right tech? Did we take advantage of it correctly?
- Project Management: Were everyone’s roles clear? Was there confusion on tasks? Were deadlines realistic?
- Communication: Were the right people informed at the right times? Did everyone in the group know what they needed to know? Did you communicate well with customers?
You probably want to make your own list of relevant items.
- In the meeting, we would go through each of the areas we had thought of in step 1 and ask people to think of things that went well and things that didn’t. We would sit quietly and think for a few minutes, writing our ideas on yellow sticky notes, which we would then post on the wall. Having a few minutes dedicated to reflective thinking is pretty nice and helped get everyone involved; even the quiet folks who don’t talk much during meetings aren’t averse to writing things on notepads.
- When time was up, we’d discuss each item the “went well” bucket, do the same for the “didn’t go well” bucket, and then move on to the next topic. Note-taking is encouraged by everyone.
In our group, the whole process took about one hour, and it soon became apparent that everyone was learning something during the exercise. While working on a project, you’re often far too deep in the weeds to step back and notice the most obvious problems. The posthoc exercise lets all those little “issues” come to light.
The best part is that, unless you were planning on closing the company immediately after release, you can immediately take the lessons learned and apply them to the next project, or even towards ongoing work on your newly released project. The payoff is immense, and the effort required is so small—one discussion—as to be negligible. I’ve been in the work environment for a few years now, and this one post-hoc discussion has been by far the most informative and fruitful discussion I’ve had since I began my professional career. I can’t recommend this practice enough!
My postdoc advisor, Nathan Urban, would pop a champagne bottle whenever someone in the lab published a journal article. Not only did everyone get a celebratory drink, but the cork would always shoot up and make a nice dent in the ceiling tile. A few years of this practice had generated quite an attractive mural of celebratory ceiling damage. ↩
As a manager, one approach to individuals critiquing each other is to ask the group members to email you directly with any comments on each of their teammates (again, after the project is completed). You can then group these together and deliver them to the individual, anonymously, during a private session. The drawback is that this requires significant trust from the teammates, which the manager may not have yet developed. ↩
The Microsoft Tool For The Job
Many technophiles have a special disdain for Microsoft. I’ve been using Microsoft “stuff” for over two decades, but only within the past two months have I been able to articulate the underlying reason behind that disdain, and I can now state it in a single sentence:
The vast majority of Microsoft tools intentionally avoid the title of “Best Tool For The Job”, instead favoring the title of “Easiest Tool For The Job”.
This is most evident in an ingeniously infuriating tool named Microsoft SharePoint. Sharepoint allows anyone to create a website using pre-built templates. You can make documents repositories, wikis, lists of… whatever you happen to want to list, issue trackers, even just a departmental homepage. The problem is that the quality of these sites are all exactly the same: very mediocre. They don’t outright suck, as measured by the fact that they all accomplish their stated purpose. The wiki acts as a wiki. A fairly difficult-to-use, ugly, and slow one, but a wiki nonetheless. The issue tracker lets you track issues, provided you don’t mind the lack of standard issue tracking features and the abysmal user interface.
These things are all fine so long as you’ve never used a good implementation of whatever functionality SharePoint is trying to replicate. Consider the issue tracker having used a number of actual issue trackers, ranging from Bugzilla to Trac to Github Issues, SharePoint sucks. Without even bothering to list the deficiencies—that would be a long, boring post all by itself—it’s perfectly clear that this is truly the poor man’s Issue Tracker.
To pick on a different Microsoft tool, this mentality of “Easiest > Best” is even more apparent with Microsoft Access. No matter what task you’re performing, creating a database in Microsoft Access is the wrong way to do it. There are countless other alternatives that are more capable, powerful, robust, and significantly faster. Again, Microsoft Access is definitely not the Best tool, it’s the Easiest.
For power users, this is death by a thousand paper cuts. Seeing people regularly deciding to use inferior tools just because “well, we know how to use them better than we know how to use anything else, so meh, it’s good enough” is painful to watch. “A little training, a little education,” we think to ourselves, “would make these people so much more efficient.” Unfortunately, with such an easy crutch to lean on, most users of Microsofts software never even realize the crutch is there, despite the fact that it slows them down every step of the way.
That is the source of my disdain. Microsoft, creator of the invisible crutch.
The Wish List
You’re looking for a job. In reading through the job listings, you notice that many seemingly entry-level corporate positions have these oddly extensive and specific requirements, such as “three to five years work experience” coupled with “two years experience in the <whatever> industry” and “knowledge of XPR, EGS, CPP, and MMCS methodologies” or something similar. You click away in exasperation and wonder to yourself, who do they think they’ll find with a posting like that? What kind of entry level person has that type of knowledge and experience?
You’re missing something very fundamental here: the vast majority of low- to mid-level corporate job postings are actually just wish lists. Some manager in some corner of a large organization realized that they need more people to do whatever specific job it is that he manages, and wrote a posting for that task. Do you know how to do that task? Of course not. Very few people do. This is even more true regarding familiarity with software packages; the majority of software packages used by large corporations are highly specialized, used by a very small group of people in a very specific industry.
So, our manager has a problem: the talent he is looking for doesn’t exist. How can he solve this problem? Oftentimes, he’ll take one of two possible approaches:
- The manager will craft a very detailed and specific job listing, carefully outlining what the perfect candidate would look like, in the hope that people who apply will have some, if not all, of the posted requirements.
- The manager will slap together a very generic job listing—sometimes provided to him in template form by HR—detailing the typical skills possessed by people in the positions similar to the one being posted, and hope that the candidate can be trained.
These differing approaches reflect two different approaches to hiring.1 In both cases, though, they’re unlikely to find the “perfect person” for the job, and they’ll have to train later on. With that in mind, even if you come across some bizarre job description that appears to describe a mythical creature that doesn’t exist, don’t be deterred from applying to a position that sounds promising.
The first is an attempt to weed out via the job posting, hoping to only receive applications from candidates with the necessary skills. The second relies more heavily on the phone screen and interview process to identify talent, with the downside that many more resumes will be received, and more time will have to be dedicated to the hiring process. ↩
Some interesting wordplays I thought up while on the bus recently.
The wording of red-light district legislation:
sin tax syntax
An end-user license form allowing others to use your unique chemical:
formula form ULA (or formula ULA form)
Making disparaging comments about a poor report card:
degrade D grade
Competition for the best criminal psychological test:
con test contest
What neural growth hormones attempt to do:
attract a tract
Warehouse that contains information on length of business lifecycles:
store age storage
Two musicians riding on the back of a male cow:
ensemble on some bull
When a new army conscript uses a racial slur:
ensign “n” sin
Two years of blogging
To improve a skill requires practice, practice, and more practice. Two years ago as of this past June, I decided to work on improving my writing, and I started this blog. I wanted to share some thoughts on how this exercise is going so far.
Writing takes a lot of time. I definitely did not appreciate how long it takes to write before I started. Most of my posts take between an hour and a half and three hours of often disjoined writing until I have something that is half-decent. I’ve learned the value of outlining, writing, reading, re-doing the outline, write some more, etc. None of my posts have come out well on the first draft; every single one has had at least three revisions of each paragraph.
You don’t know what you like until you try it. I spend a lot of (read: way too much) time on Hacker News. At the outset, I wanted my audience to be the Hacker News audience. I’ve been successful, to a small extent, in that a good number of my posts have made it to the Hacker News front page. As I developed my writing, though, my writing started to focus more on different topics, that interest a different audience. I’m still trying to really determine the types of topics I enjoy writing about; I suspect this is a common theme among novice writers, the long search for the topics they feel most comfortable writing about.
I think about writing a lot more now. As I go through the various experiences of my day, I find myself thinking “that would make a good blog post” very often. As a result…
My thinking has evolved. Previously, I would do my best to understand “things” for myself; reading the news, learning a new trick, going through some funny/sad experience at work/home/life in general would be an effort in trying to understand what’s going on for myself. Now, I find that I’m asking myself, “how would I explain this concept or argue this point to a larger audience?” This approach of explaining ideas from a different angle has helped me thinkg through concepts and arguments more deeply, and get a better understanding of when I really understand something.
So far, it’s been fun. Here’s hoping I can keep this up for a few more years!
I’ve recently started doing something I haven’t done for a long time: read books. The two that I’ve recently finished are Good Boss, Bad Boss and Contagious, and I’m currently working through A Random Walk down Wall Street and The No A****** Rule. While reading, I’ve noticed a clear pattern in the writing style: all of these books are written like storybooks. The chapters comprise of one short story after another, each one between a paragraph and a page and a half long, often making the same point over and over and over again. The next section will be the same: a basic idea, and then dozens of stories illustrating the point over and over again.
This works. People don’t remember endless streams of facts, they remember stories. More pointedly, they remember stories that they find interesting and/or relevant. This is why all good public speakers know to make liberal use of stories, jokes, and anecdotes when talking; the audience enjoys it more, and will remember it better than a simple recitation of facts. A good friend of mine who frequently gives talks as a motivational speaker told me that a good speech “begins with a joke, continues into a story, and then ends with a joke.” What about content, I asked? Make your jokes and stories convey your content, he said. People want to be entertained, not lectured. Entertain them, and you’ll convey your message much more powerfully.
This isn’t my usual type of blog post, but rather a reflection on something interesting that happened to me last night…
I whistle. A lot. Mostly while walking down the street, but also while doing housework, while driving, quietly to myself while thinking, etc. (I keep this next to my desk to remind me not to whistle at work. So far so good.)
Last night, as I was walking home and whistling some random tune, a woman across the street practically yelled at me, “you’re the best whistler I ever heard!” I laughed, thanked her, and continued home. Two blocks later, as I was walking up to my house, some guy who was entering the apartments turned to me and said, “you know, you’re really good. That sounds very nice.”
While two compliments in one walk is a new record for me, this isn’t the first time that people have made comments like that. Whistling in public is pretty passé nowadays, and the sheer novelty of it elicits interesting responses from people. Last summer, whistling while coming home from a walk, a young lady sitting sitting on the steps in front of an apartment building commented, “you know, you just made my day.” I regularly get comments asking why I’m in such a good mood.
When I was a kid, I used to comment to friends that life needs a soundtrack. Nowadays, life does have a soundtrack, via iPod earbuds. The problem is that it’s completely confined to the individual. We can’t hear each other’s music. That’s definitely a pretty philosophical approach, to be sure, but still, I think it’s kind of sad.
It seems that people appreciate hearing someone else’s life soundtrack. I’m not referring to their favorite playlist. I’m talking about the soundtrack reflecting their mood, their week, their personality. Humans are deeply empathetic; if it looks like I’m having a great day, that’s often enough to put a smile on your face, at least for a moment. Everyone has their own worries and stresses, but getting a peek in someone else’s life—even if just through a snippet of a cheerful-sounding whistle—reminds you that things are generally pretty good in the world.
"Free" can be pretty expensive
It’s well-known in the IT world that free, open source software often incurs a hefty cost—the cost associated with supporting that software. You can replace Microsoft Office with OpenOffice or abandon Mac OS X in favor of Ubuntu, but if your users are familiar with the commercial packages—as most users are—then all you’ve done is transfer the cost from “purchasing” to “support”. This is not to say that it’s never cost-effective to move to open-source, but it’s definitely not “free”. In this instance, the cost of open source is lost productivity for both the users and the IT department. I know this, and you likely know this as well. I would venture to suggest that this is common knowledge within the tech circles at this point.
With that being said, I find it striking that I rarely hear the reciprocal argument—that paying money for software will result in a cost reduction—being brought up by the technically inclined. Heck, I’m guilty of this myself; I’ll download some free software that I’ll likely never really use without a moment’s consideration, just because it’s free, but I’ll think long and hard considering whether it’s “worth it” to spend $10 on a piece of software, even when there aren’t even good alternatives available.
A funny-because-it’s-true Dilbert strip highlights the problem here; everything has to be compared to the alternative. In most cases, the alternative is “whatever I’m doing right now”, which likely isn’t all that great. The short-term (but quantifiable) goal of not spending money overrides the long-term (more ephemeral) goal of being productive.
If you’re using something free, when someone brings to your attention a paid alternative, don’t disregard it just because it costs money. Even from a monetary standpoint, you may be better off with the alternative.
For my son’s tenth birthday, I took him to a major league baseball game. I haven’t sat through a complete baseball game in decades, so this was almost a first-time experience for me.
First off, lets get one thing out of the way: raw baseball is boring. Scientific studies have shown1 that over 90% of baseball is comprised of something other than baseball; watching the scoreboard, doing the wave, watching the drunk guy yell at the players and passing helicopters, etc. Mostly, though, you’re waiting for things. Lots of waiting. If going to a baseball game involved nothing more than watching baseball, I can’t imagine anyone would actually watch it.
The thing is, the Major League Baseball people realize this. A good game will last three hours, with maybe five minutes of actual action over the entire game. What kind of fan wants to sit through that?
The answer, as it turns out, is an entertained fan. While watching the game, I noticed that every 30 seconds—sometimes even less than that—something happened. Maybe they played some chant (“bum bum bum, let’s go Bucs!”), or maybe they had some dude throw tee-shirts, or maybe they played some snippet of a song over the sound system, or maybe they had men dressed up as Pierogies run around the stadium in the most ludicrous race in the history of mankind. Strikingly, the vast majority of these involved the audience in some way. They put pictures of random fans up on the display, causing other fans to think, “hey, I’m a fan… if I do something now, maybe I can get up there!” They run raffles involving ticket stubs, or seating sections, or outrageous clothing. Whenever a ball is hit near the fans, the ball girl will toss it into the crowd. They show trivia questions on the display board. They have fan interviews, lots of fan interviews. All this stuff is meant to not only keep you entertained, but keep you wanting to stay in case the next “thing” may involve you. It’s subtle but very effective.
I went from the game to a committee meeting for a non-profit at which I’m a volunteer, and I brought this idea up there. We are trying to maintain the enthusiasm of our volunteers, and this experience drove home the point that maintaining engagement requires lots of planning, work, and effort. Running an activity every 30 seconds over a three-hour period takes some serious advance planning. Keeping volunteers involved in a project, or keeping customers interested in your product, or even keeping yourself motivated about your latest personal growth project, requires a lot of advance planning. When that initial effort is put in correctly, the result can really shine.
I’m a Scientist™, and I studied it today during the game. (I thought about it twice, just so I could say “studies” instead of “study” in the above sentence.) ↩