Interview with Christopher Duncan, author of "The Career Programmer: Guerilla Tactics For An Imperfect World"

Interview with Christopher Duncan Author of "The Career Programmer: Guerilla Tactics For An Imperfect World"

Christopher Duncan wrote an excellent book on how the programmers can not only survive and prosper in the corporate world but also have fun while they are at it, deliver quality software, avoid late nights and bad pizza. We, here at vbRad.com, always strive to write our own ticket, thus our interest in this book. Enjoy.

Q:	First of all, what possessed you to write this book. Not in terms that the market needed it, but in terms of what was the straw that made you think that this story needed to be told?
A:	It wasn't any one particular event that triggered it. I've been a contractor for years, and time after time I kept running into the same corporate lunacy. It occurred to me that most of the time, programmers lives are turned upside down not because of technical issues, but because they don't know how to play the corporate game (or feel that they shouldn't have to). I was president of a sales and marketing company in the 80's, and so I've learned how to maneuver. I thought what I've learned over the years might help other programmers deal with management, since the tactics have worked for me in my own jobs.
Q:	What are the most insane things you've ran into while consulting at these corps?
A:	I'd like to report bizarre events that would be shocking to programmers everywhere. Truthfully, though, I suspect it's all too common. Since you've read the book, you've heard some of the better ones already. For instance, working night and day to implement an inter company replicated database system serving & distributing to 30 cities, meeting the deadline, and then having the company immediately scrap the app because the web became trendy and they thought they should centralize it all on one box and use a browser based Intranet. Or the time I was tasked (pre Internet) to write an inter city communications subsystem, but the president of the company decreed that I should transfer the data via floppy disk and Fed Ex. A lot of technical decisions made for completely non technical reasons.
Q:	Yeah, that's a good one. There is a joke out there: What's the fastest way to move 500MB of data? Fex Ex.
A:	I think I read the sequel to that: "When Bad Things Happen to Good Floppies"
Q:	Chris, with regard to down-sizing happening mostly everywhere, what it your opinion of mega-corps offloading software development to third world countries such as India, Philippines, etc… My question has mainly to do with effectiveness of such a move, given the time-zone differences, distances, different cultures, etc… Have you seen any evidence of this being effective or disastrous?
A:	Well, the programming business being an international community, I'm quite accustomed to working with people from all over the world. And of course, the compiler couldn't possibly care less about national or cultural differences. However, a recent experience I had with a web hosting company points out some difficulties that farming out to different parts of the world may entail. I was dealing with a hosting company in Canada (I live in the US). Their technical support was email only, and it was a region of Canada where French was the primary language and English was secondary. In the scenario you mentioned, time zone differences dictate that much of the correspondence will happen via email. This can get cumbersome in a hurry. In most of my jobs, I've worked with a lot of developers from other countries, for whom English is a second language. Since I've never gotten off my tail to learn any other languages, communications were sometimes difficult just due to language constraints. However, being face to face, able to walk to a white board, use body language, etc. helped to bridge the gap. Via email, however, you don't have these options. My support experiences with the web hosting company were essentially a nightmare for communications reasons alone. I'm not sure I'd want to manage a software project from the other side of the planet. At least not until everyone's fluent in Esperanto.
	By the way, I'd like to offer an additional thought regarding the downsizing we're experiencing. When times are good, techies can afford to ignore certain political realities because they're in such demand. However, when times get tight like they currently are, I think it's more important than ever for us to learn how corporations play the game so that we can either keep the job that we really need at the moment, or know the ropes to landing the next one in a tough market. Technical skills alone are not enough.
Q:	That's so true (about ignoring realities in good times)
Q:	In the book you describes various types of programmers (my description was right on target). In your experience, what is the usual make up of a programming dept? In my experience, you have 1 or 2 gurus (you know the technical guys, some even with thick glasses). Then you got the maintenance programmers who have been there forever because no one else knows that 1970 VAX system. Then you've got the programmers, who never should have been programmers. Does my experience mirror that of the rest of the corporate world?
A:	You just described every shop I've ever seen. It's amazing how much common ground there is among shops. Of course, there are other common players as well, such as the poor junior programmers who don't even know the rules yet, let alone the game, and end up suffering the consequences.
Q:	I am just amazed how many people do programming that never should have been that.
A:	Well, a lot of people have come to me over the years asking how to become a programmer because the money is decent. My advice to them is consistent. You either love coding, or it's tedious as hell. If you don't love it, run away from the business, fast. With the deadlines, stresses, pressures, and general mismanagement of the business, if you don't love the art of programming, it will be a miserable existence for you. Check your nearest law school.
Q:	Good advice. I work in a corporation where large projects are fairly well defined beforehand, and they have to be agreed on and approved by about 20 people. Thus, these projects take about a good year before a single line of code is written. The real world requirements of business, though, demand quickly apps here and there, which are done clandestinely, below anyone's (of any power, that is) radar. These projects usually have no spec, need to be done yesterday and they grow hair very quickly at an exponential rate. There is also huge pressure to finish them fast, lest someone finds out about it. How can programmers control their destiny in such an environment?
A:	Once again, you've described a scenario I see over and over again. Well, at least the clandestine part. I don't see many shops with the kind of structured process you describe. That's really one of the things that I focus on here. In a shop where things are done "the right way", you'd have everything well defined. When you're trying to kick out an app quickly, for whatever reason, that's when you need to be able to manage requirements in a politically savvy manner, do design in an extremely compressed format and have a realistic grip on how long it will take before you can show someone results (in order to stave off whatever lunacy prompted the incognito development to begin with). This situation is really the driving force behind the techniques I describe in the book.
	I've been in these situations so many times, I had to start coming up with ways to manage my development effort while maintaining a low political profile at the same time. And much of what I do truly follows the philosophy that Business is War. I approach these situations with a strategic and tactical approach, viewing the corporate structure as the enemy. Sounds a little dramatic, but in reality such battlefield tactics are quite effective in the business world.
Q:	Many corps (some of which employ my friends) have this practice of fake testing. In other words, employees, that are in the business department and have other more-pertinent duties, have been recruited to do QA. However, they don't have time nor do they want to deal with it, so the software goes to production untested and rubberstamped by the business dept. What are some of the strategies around delivering quality software in this situation?
A:	Lack of testing has been the bane of software development since the first company decided to hire programmers. The first line of defense in the fight for QA is to win the hearts and minds of the resources who were allocated to this fake testing procedure. They aren't techies, they have no QA training, and in the beginning they don't care for the task at all. The secret lies in making these people feel like a respected and highly valued part of the development team. When they see what a huge difference their personal efforts make in software quality, and they feel the appreciation for the programmers who won't have to chase a bug at 3 AM, then suddenly they're your allies. Enthusiasm skyrockets, and they become a part of the team, officially or not. At that point, you have a fighting chance.
Q:	Quite different from what were taught in college. All right, on to my lone, somewhat related to programming, question. Basically all the software I and many others have ever written for large corps has been essentially the same: get some data from the database, do something with it, throw it back to the database. How does one prod (convince or torture) the management to get interesting projects?
A:	Actually, you touched on that briefly when you were mentioning clandestine development. Being a mercenary, there are some contracts that can't be over quick enough, and others I'd like to keep. In the case of the latter, I end up sticking around because prior to the end of the current project, I've evaluated what business problems exist, what the realistic timeframe is, and then propose a practical, time effective software solution. Management is usually thrilled to have someone propose a solution instead of just complaining about problems. Of course, while I'm solving their problem, I'm including the state of the art stuff that I think is cool, because inevitably that's features that the users themselves (who are also not on management's radar) appreciate.
	In fact, most programmers could be working on cooler stuff. They just never realize that with a minor amount of initiative & a small sales pitch, they could define their own projects. The coolest programs don't necessarily go to the best coders (there are tons out there better than myself). They go to the guy that hustles up the project.
Q:	That's true, but does not work often enough. I've tried to get a project going in .NET, but was denied. Part of the reasoning was that the deadline is looming, it would take me long to get up to speed with .NET and that I would simply be playing with .NET on company time. Lame, but that's corporate life.
A:	Well, I don't always win. However, a lot of it has to do with how you pitch the project. There's an old adage from my marketing days, "Sell the sizzle, not the steak". What that means in our context is that I often pitch the end results rather than concentrating on which technologies I'll be using. When ActiveX controls were the new cool thing, I naturally wanted to work with them (there's a year of my life I'll never get back). I proposed a system to a telco I worked for to automate the development of custom apps that were written for each client. I described a form editor that business specialists (non programmers) could use to lay it out, doing simple drag & drop operations. I wanted to do some fun stuff with tree controls, so I also told them that there would be a visual logic builder that would walk them through the process (wanted to play wizards, too). They bought it, and I and a couple of top notch programmers got a year and a half's worth of fun work out of it. Had I instead talked about ActiveX controls, tree controls (new at the time), Wizards, etc. it would have spooked them and they would have gotten nervous about technologies they didn't understand and the time it would take to implement. Sometimes the best thing you can do is not overload them with information. That points out another sales adage when making a pitch: KISS No, not the boys in makeup - Keep It Simple, Stupid.
	By the way, you mentioned that this is stuff that we don't get taught in college. An interesting thing that's happened is that some of my friends have read the book just because I wrote it and they wanted to see what I was up to. They aren't techies, but do work in corporate world. Surprisingly, they relate to almost all of it.
Q:	I guess on some level everyone in a large company pretty much gets treated in the same manner, sans the techie stuff.
A:	Yeah, most large companies act in an identical behavior, techie or not. And that's the point of much of what I teach - learn to play this game, and it works most everywhere.
Q:	The chapter on corporate self-defense is brilliant - it is a mirror image of the wars at my place of employment. The predators in the jungle look meek by comparison. Now somewhat unrelated question. How do you deal with burnout? Even if you are amazingly excited in the beginning, several years of toiling in a cubicle will take a lot out of you.
A:	Burnout? Er, what do you think prompted me to start writing?
	Seriously, I've dealt with burnout a lot over the years. Like most programmers, I'm very passionate about programming, which is a polite way of saying obsessive. Sometimes the best thing you can do is just walk away. There are years where I code all day at work and then code all night on a pet project. Then there are months or even years where I don't touch a line of code after work. I plug in the guitar, turn the Marshall up to 11, and do my best to terrify the neighbor's cat. The best defense against burnout is finding other things in life to spend time on that don't require a computer.
Q:	I see. I think every now and then you gotta step back and go work for a startup, except there are very few around. Ok, last question. On the scale of 1 to 10, what is importance of the following in a corporate work place: coding skills, social skills, politicking skills, some other skills I've missed.
A:	I'll answer this question twice, because the answer depends on who you ask. To the typical programmer (who because of this is often little more than a stationary target in corporate war games), the priorities don't even require thought. Coding skills are all that matters. Everything else is a distraction to be avoided and / or ridiculed as insignificant. My second answer is from the perspective of what's going to further your career goals (which usually involve money and playing with cool projects & technologies). Like it or not, boys & girls, here's how it shakes out in the Real World. Political skills matter more than anything else. Without them, you'll be doing maintenance on a 1960s era COBOL reporting system. Social skills are closely tied to that - if you can't play nice in the Reindeer Games, you'll have no allies, and you're toast. Brush up on your COBOL. The other skills, unmentioned, are more technical - you absolutely must learn how to manage your development effort. That means design (in however much time you have), estimating (or it's a continual Death March) and general organizational skills. This stuff ain't sexy, but it'll kill your project quicker than a depth charge if you don't have them. Finally, when it's all said and done, you have to be up to par technically. This is backwards to most techies, I know. I wish it were otherwise. However, an average coder who has mastered the other business skills will always outflank the technical deity who practices isolationism. If you can find a company where this is otherwise, save me a seat!
Q:	Ok, thanks for the interview. The book is great. Are you writing any others?
A:	Hey, thanks for having me. It's great fun talking to someone who's obviously been through the same wars. And I appreciate the kind words about the book. I'm working on a new one, a collection of programmer war stories contributed by folks like us. If I can insert a plug, there's a link to the forum where everyone's sharing their stories on the book page of my company site: www.ShowProgramming.com/TheCareerProgrammer.asp - just click on the link for Programmer War Stories (I'm switching hosting companies and that link will change, hence directing them to the book page). This book will be a combination of fun tales along with some practical advice on how some of these horror stories could have been avoided by using some covert tricks. It will be an Apress title as well.
Q:	Excellent. Thanks for the interview, good luck with the new book. Certainly, let us know when it comes out. Now, it is time for me to get back to the jungle.
A:	Just keep an eye out for that attack Chihuahua. He gets a little cranky towards the weekend. Thanks, Robert!
Q:	Thanks, bye.