Ricardo – Team Economics

My previous post was about starting out with a small team, and some ideas on leading it. The next few posts will talk about a few useful tools that I use in developing and shaping a team.

Eat The Rich by PJ O'Rourke
A Good Econ Book

I didn’t do well in either macro or micro-economics in college. I was working my way through the liberal arts to find out what I was good at, and it turned out not to be econ. In college, however, I always enjoyed reading P.J. O’Rourke’s books. I was too young to see the cynicism, and so I read pretty much everything he wrote for several years, laughing out loud all the way. It wasn’t until I read Eat The Rich that I finally found one thing in economics that I can use practically daily: Ricardo’s Theory of Comparative Advantage. Now, I can’t do O’Rourke’s writing on this justice (Eat The Rich, Page 104-123), and I highly recommend reading it (along with all his books published before around 2000 – I haven’t read any since then), but I think it’s useful to discuss. Continue reading “Ricardo – Team Economics”

The Small Team

In my last post, I wrote about the choice between specialists and generalists on a team, using the metaphor of role-playing games to illustrate it. Now, I’m going to write a bit, over the next few posts, about my practical experience building and growing teams. This isn’t meant to be a guidebook on team development, or anything, but more of my approach and philosophy on team building.

D&D 1st Ed rulebook.
It’s all been downhill since then…

Sure, I also happen to have another awesome picture for this post that I feel reinforces my credentials in Role Playing Games, but that’s a total coincidence, I swear. Yes, I do just have these books lying around my office.

 

At many jobs I’ve had leading teams, I’ve started with somewhat small teams. For illustration purposes, the team I’ll describe will be an example, and not really any particular team I’ve actually had. Continue reading “The Small Team”

Pity the Wizard

Might and Magic 2
Note that this is the Apple IIgs version. #hardcore

At times, I’ve felt the temptation to equate the development and growth of a team to that of a party in a Role Playing Game. But, while the RPG analogy does have some striking resemblances to real life, it is better for telling us about pitfalls than about actual good practices. They are both similar in that you start out a Role Playing Game with little knowledge of your task, and build a party based on intuition. As the game progresses, you realize that your party design is not exactly aligned to the tasks that you are confronted with. Continue reading “Pity the Wizard”

Risk, the Developer, and Patton

Every developer has been confronted with the request, ‘Take your best guess,’ in working their way through a problem. Now, this puts an engineer in a very hard position. Many teams are conflicted when it comes to taking chances: you can take any chance you want, as long as you only pick the right solution. That makes it very hard to put a developer in that position, since it’s not really a guess if the only allowed outcome is 100% success. Continue reading “Risk, the Developer, and Patton”

Books about Software Development: Life the Universe and Everything

Most readers will be intimately familiar with Douglas Adams’ work. If you’re not, it’s definitely worth a read. One item that relates to engineering and project planning that always springs to mind too late in a project was a concept he included in Life, The Universe and Everything: The ‘SEP’ – ‘Somebody Else’s Problem’.

This concept is basically a sort of cloaking field where people ignore something by assuming it’s somebody else’s problem.

“An S.E.P., […] is something that we can’t see, or don’t see, or our brain doesn’t let us see, because we think that it’s somebody else’s problem. […] The brain just edits it out; it’s like a blind spot.”

Douglas Adams. Life, The Universe and Everything, Chapter 3 Continue reading “Books about Software Development: Life the Universe and Everything”

Four Quadrants

A while ago I was in my car, listening to the radio, and the Beatles came on. I’ve never really been into them, but I have respect for them and their influence on music. I started to think about my likes and dislikes in four quadrants as sort of a silly thought experiment:

Four Quadrants
Four Quadrants

On the Y axis is my level of respect for something, and on the X is how much I like something. Continue reading “Four Quadrants”

Fear and Software

Several years ago, as a consultant, I had the opportunity to work with a client on modernizing their Quality Assurance processes. At the time, I was at the phase of my career where I viewed QA as just ‘testers’. They were sort of secondary characters in a play that starred programmers. Like the ponies in the Lord of the Rings. Important, sure, but they didn’t get their own swords or anything.

So I took a deep dive in to Quality and started at (close to) the beginning, with W.E. Demming. He was one of the first Quality gurus, and became known for his work in Japan following WWII (he has a wikipedia page). The one thing that really resonated with me from researching him was his idea that you had to drive out fear from engineering. At the time, I was still in the ‘bugs are bad’ phase, and because of that, made all the classic mistakes in programming. I wasn’t good at testing my own work, and wasn’t particularly good at telling our testers where to look for bugs. I also viewed testers more as impediments to my amazing software being released than as allies. Continue reading “Fear and Software”