I am nerd
Tim Collins almost managed to pin down international super nerd Michael Lopp – call it a ‘virtual’ interview with one of the key speakers at the Wellington’s Nerd Nirvana – Webstock.
First, a biography:Michael Lopp is a Silicon Valley-based engineering manager. When he’s not worrying about staying relevant, (Michael works with ‘ultra relevant’ Apple), he writes at the popular technology/management weblog, Rands in Repose. Michael also published a book called ‘Managing Humans’ which explains that “while you might be measured by your projects, you will be successful because of your people”.
Michael surfs whenever he can “because staying sane is a full time gig man.” (OK, I added ‘man’ – couldn’t resist really).
Now, the questions:
Why make the long trip to speak at the Webstock event in Wellington?
I’m of the opinion the Webstock event is one of the best run web slash technology slash nerd culture conferences out there. When you combine the art with which the organizers run the event along with the strong sense of community you feel with the attendees, it’s a no brainer to make the flight to Wellington.
How would you summarise the key points from your presentations?
My presentation is entitled “Being Geek”. I explore the geek and nerd culture and what’s happened to it now that it’s become mainstream. I walk through the geek psyche and point out obvious aspects of personality that we nerds may have forgotten because we’re so used to them.
My talk is really about nerds at work and nerds at play. Hope its fun.
How is the ‘Managing Humans’ book good going? Plans for any more?
‘Managing Humans’ continues to do well. Whenever I go to a conference like Webstock, I get to talk with folks who have purchased the book who always have interesting questions about how to apply the book to their own particular career. That’s my favorite part.
Regarding more books. The first thing you do when you write a book is say, “I’m never doing that again.” So, of course, I am. I’m working an book on geek culture for O’Reilly which I should really be writing right this very second.
From your experience, Is Silicon Valley ….
a. a really cool place to work (and live)
b. overrun with nerds
c. something else entirely?
Can I choose all three? What I always say about Silicon Valley regarding it as a place to live and work has to do with opportunity. You want to be a engineering manager who loves to surf, but wants to live in the redwoods? Ok, you can do that. You want be an mobile application developer who can’t stop getting tattoos and wants to live in the city? Done.
There is so much variety in terms of both places to live and things to do, I can’t imagine living anywhere else.
N.A.D.D. seems to describe a rapidly growing part of the global community (and probably most of the attendees at Webstock).
a. did you invent this term?
Yes, I coined the term, but it’s roots are in the well-known acronym of A.D.D. (“Attention Deficiency Disorder”)
b. how should non-NADDs approach you and go about getting something from you?
My first suggestion is to first know whether the person you’re dealing with is afflicted with Nerd Attention Deficiency Disorder (“NADD”). You need to capture their attention quickly or else they’re going to mentally wander. I delete long rambly voice mails almost instantly. Yes, I would rather move onto the next thing rather than listen to someone verbally stumble through their poorly articulated thought.
It’s rude behavior, but I’m in a hurry.
c. talk business with you?
The same rule applies. Grab my attention by being clear and articulate. Get to the point. Not only do I have N.A.D.D., I also have a lot to do and if you need something from me, respect my time and my feux-neurosises.
Our annual bloggers predictions event was held recently in Wellington, what are your predictions for 2009 under headings of ‘Technology’ and ‘Business.’ What excites you about the year ahead? What about five years ahead?
My personal opinion is there is going to be huge culling of the irrelevant of the next year and that’s going to be painful. However, a culling kills bad ideas, but also makes room for others to exist. I mentioned at my last Webstock presentation that it’s just not that expensive to get an idea out there in front of a lot of eyeballs. Software is cheap or free these days. Bandwidth to just test your great idea isn’t that expensive. I’m excited to see what strange bright ideas emerge from the rubble of this current economic meltdown. I’m certain there are coming, I don’t know what they’ll be, but I’m certain we’ll be impressed.
As for further out, I’d like to be storing my bits somewhere else… in the cloud if that term floats your boat. I think the idea that you’ll have anything resembling mass storage in your home will seem kind’a silly. Like baking up your photos on floppy drives.
I also like to think web-based applications are only going to continue to blur with desktop applications. My test has always been: when do we get with the power and flexibility of say, Photoshop, via the web? Long ways to go there.
Any advice for ‘Start Up’ businesses?
Again, my personal opinion here. I have two pieces of contradictory advice for start-ups. First, pick one great idea and boil it down to it’s simplest case and do that idea. Don’t wander. Don’t think about the next version, just nail that idea. Wandering around doing three things “OK” is a waste of time and money. I think Twitter’s approach is one of the best examples of the “do one thing well” strategy.
The other piece of advice is be willing to turn on a dime. If your basic idea isn’t working, have the professional courage to find another idea. It’s can be expensive switch, but it’s better than pouring a year of your heart and soul into an idea that just isn’t taking off.
And what will you do ‘for fun’ before leaving New Zealand?
I was unsuccessful in getting my surfing on during my last visit, so the goal this time around is to find some sweet surf and relax.
Lopp’s blog can be found at www.randsinrepose.com and is worth a regular visit – here is a brief excerpt;
The Larry Test:
Larry was pissing me off.
We were a year into a two-year development process. Far enough along to have confidence that we could do it, but not far enough to be sure when we would get there.
Features were claimed to be done, but each build of the product was a study in broken and frustration.
So I’d ask Larry, “Why doesn’t this feature work?”
Larry’s lengthy answer demonstrated his deep knowledge of the product, his confidence in his team, and incontrovertible evidence that they were making progress and that the feature would work “real soon now.” Larry would convey this confidence and I’d leave the conversation swimming in a pleasant sense of managed calm, but a day would pass, I’d install the next build, and shit was still broken.
I knew if I walked into Larry’s office I’d get the same fire hose of comforting reasoning regarding why we weren’t done. I also knew if I waited another 24 hours to see another pile of broken bits, I’d lose it, so I stopped, took a deep breath, and wrote myself a short list.
Seven bullets. Each representing a feature that needed to work. Not done, just working.
I took the list into Larry’s office and handed it to him: “This is the Larry Test and you need to pass it.”
Done has a lot of definitions, depending on where you’re standing in the building. Marketing thinks you’re done the first time they see a working demo. Program managers think you’re done when the deadline arrives. QA thinks they decide when it’s done because they’ve got fancy metrics to define doneness: “No high priority bugs found in the software for a week.” Ok, fine metric, but for engineering, done happens long before all of these definitions.
The issue is that an engineer’s definition of done is the perfect set of code, and left to his own devices, an engineer will endlessly improve the code on the mythic journey to done.
It’s never done. For any large project with many personalities in play, at best it’s always good enough. Sorry.
This is not an argument for mediocrity. You can toot your horn about quality and only be good enough, but I guarantee — I promise you — that you will ship with significant piles of two types of bugs: the ones you know and the ones you don’t. Engineers have an innate sense of where those bugs are, and if you don’t tell them to stop, they will merrily continue towards their goal of total elimination of all bugs.
This is why, when the time is right, you indicate to your team you’re done, and I use the Larry Test.
(Read the full story at http://randsinresponse.com/archives/2009/01/18/the_larry_test.html)








