Ed: And the act of making software is the act of learning. So the second time you try to learn something, you’re gonna learn it better and faster.
Andy: Absolutely. You’ve already prepared the bed, as it were. And jokingly, a lot of people say, “What’s the best thing I can do to enhance my code?” and I say, “Take a big magnet to the hard drive.” That’s the number one issue for code cleanliness ’cause you will tend to do it much more straightforward.
Ed: Yeah, but like anything else, though, there’s -- there’s the flip side of that, because if you’re developing something really complex, over the years, you get the bug fixes in there and a lot of other people are working on it, but sometimes it’s very attractive and seductive to just say, “Let’s just throw everything out and start again from scratch.”
Andy: That’s another tension where developers love to do that. The reason they love to do that is because they know they can do it better this time. Certainly on large systems, where you’ve had a lot of different people’s input, you need to weigh, okay, “Are they all in that same position to contribute again?” or “Do we not have that opportunity anymore?” It’s different if you’re talking one or two people versus a 10- or a 50-person team.
You know, that introduces a new dynamic there. If you got the same 50 people together and they all have learned and know better than what they did the first time, then, yeah, you might be better off scrapping that first two-year effort and replacing it with a new six-month effort. But if 45 of the people have moved on, then that doesn’t work out so well.
Ed: How important is it to let your understanding of the business of software and the perceived demand for specific skills inform where you invest in stewarding your skillset?
Andy: Well, that’s all a question of managing what we call your “knowledge portfolio,” and this is a concept that was put forth in the original Pragmatic Programmer book -- that everything that you know is part of your knowledge portfolio and, like a regular portfolio, this is something [where] you want to play with the balance of risk and reward, return on investment ratios.
Something that’s new and hot, if everyone’s doing it, then it’s actually fairly low-risk. You could be assured that we will get some kind of a gig out of it ’cause everyone’s doing it, but it’s also fairly low-reward. You’re not gonna get handsomely rewarded, because everyone else is doing it. Something like Java in the very early days or Ruby perhaps or Erlang now -- there’s a lot of risk associated with it.
You could invest heavily in it and it might turn out that no one ends up using it. It could be a flash in the pan or it could be the next hot thing, so you’ve got a high risk but a commensurate high return on investment if that’s the thing that pans out.
If you got involved in Java back when it was Oak and in the very early days and positioned yourself there, you’d have done very well for yourself. You could get involved in whatever the latest hot thing is this week and who knows?
Andy: That might turn out to be the next hot thing; it might not. So like anything else, it’s a mixture of trying to balance that—the risk to the reward ratio.
Andy: What Dave [Thomas] and I have long suggested in our seminars and our writings is you want to balance yourself out, learn a couple of each. Learn some high-risk, high-reward things in case it pans out, but pad the stable out with some fairly sure bets of, “well, there will always be a need for XYZ,” and balance it out that way.
Ed: How does that relate to outsourcing?
Andy: As long as you’re problem-solving, making decisions, helping the business grow as more of a business consultant, you’re probably going to be much more tied into the business and have greater longevity than if you’re just a replaceable code monkey, one of a hundred that’s not thinking, not doing anything particularly valuable.
Those are the jobs at the very bottom. They’re the first to get outsourced to whatever the next country is on the outsourcing list. An interesting side note there -- one of the most interesting books that we came out with on career development is entitled My Job Went to India and All I Got Was This Lousy Book by Chad Fowler (Pragmatic Bookshelf, 2005). And the title was meant to be somewhat tongue-in-cheek because, obviously, there’s a lot of concern about jobs being outsourced to India, to other low-priced countries, and the whole book really takes the tack of “Here’s what you need to do in terms of career development so that yours is not the job that gets outsourced. Here’s how to market yourself internally. Here’s how to make sure that your boss and the powers-that-be understand what it is you do that adds value to the organization, where do you add value that others don’t” -- all this sort of approach, and I think that’s really quite valuable, because at the end of the day, you have to add some proven value to the organization or it’s their responsibility to replace you.
Everyone harped on India because they were the first out of the gate to attract outsourcing, but the irony is I’ve got a few friends who run outsourced operations in India and they’re quite concerned because they’re losing business to the next set of countries down the rung -- Eastern Europe, Vietnam, Southeast Asia. Other places are filling in. They’re fighting the cheapness war and winning, and so it goes. Those will get comfortable for a while. Then they’ll lose out to the next rung down the ladder, and on it goes.
Ed: It’s clear, then, that the organizational structure of a company has an impact on job security. How about developer productivity? Can you give me an example of where it has a negative impact?
Andy: This is a popular dysfunction in some companies, where the maintenance folks are on a different budget than the developer folks. There’s no incentive for the developers to write bug-free code. There’s incentive for them to write code fast and get it the hell off their plate. So that is not an optimal way to structure your organization.
There are actually a lot of oddball things like that, that have nothing to do with software development. Instead it has to do with some accounting rule somewhere and how it affects the dynamics of what the team can do and what they’re paid for that ultimately affects the code. There are whole classes of organizational dysfunctions that just stem from accounting rules, oddly enough.
Ed: Speaking of accounting, how organized are you in your personal life?
Andy: My desk is neither spotless nor [a] pigsty. What I tend to do is organize by piles, very much pile management, so I’ll have a hot and important pile and maybe several stages of archived piles or different topics. But I find trying to sort it to any real finer grain ends up being a waste of time, and not sorting at all becomes a problem where you can’t find stuff. So I take a predictably pragmatic approach and sort it in fairly large-grained piles -- enough so that if I need to find something, I may not be able to put my finger right on it, but it’s kinda like “bucket sort.” I can go to the right bucket and within a quick linear search be able to locate it fairly rapidly.
Ed: Do you keep a journal?
Andy: Not in the diary sense, but I do keep a Moleskine notebook with me at all times. So you always want to have something with you to jot down on. I’ve got mind maps in it, bullet lists, thoughts, designs, archive stuff. It’s more like an engineering journal, but really more like a notebook. Not like a diary. It’s useful for me to reload context. You know, “I figured this out once… I don’t remember what conclusions I came to. What were the constraints, what were the issues? Oh, yes, that’s right.” So it’s like a quick memory reload for important thoughts that you had.
Ed: How about a day planner? Do you use one of those?
Andy: I do not.
Andy: I use the calendar app on the Mac, which synchronizes with my cell phone, and it beeps at me when I have to do something.
Ed: What are some things you can say about how to successfully do schedule negotiation with a client, and how do you ensure that you and your client agree on a schedule that’s realistic?
Andy: I think -- in general terms, I think the best way to manage that is to take small bites. I had a very demanding client some few years back where it was a very difficult sell. They wanted to know two years from now what I’d be doing on a Tuesday… and clearly that was going to become a problem. We had a couple of heart-to-heart talks and I said, “Listen. Let’s just try it this way.” And I gave them the Agile song and dance and ended up just trying to say, “Okay, let’s just do this -- let’s take this one step at a time,” and really ended up doing what looked more like scrum than anything else. I’d start off with a backlog, just a private list on my Wiki of “here’s the things I’m gonna do next and you tell me what’s most [important]” -- it’s really a matter of relationship building more than anything else. That’s how people get to trust you. That’s how they know that you’re not trying to pull the wool over their eyes. So we ended up developing a relationship where they came to know that if it was something that they deemed important and of high relevance to them, something they needed fast, they knew that they would tend to get it pretty quickly, within a week, within two weeks.
It’s as much a matter of training the customer to know what your speed is as anything else. Once they get a flavor for it, then you say, “Oh, that’s gonna take us a long time. Can we do something else in the meantime or can we break that apart? What are our choices here?”
What you need to do by whatever means is train the customer. When the Agile folks say “work closely with the customer,” that’s really what it means. It means “gain their trust.” Let them see how you work, how fast you work, how fast your team works. Get them to have a reasonable set of expectations of your capabilities.
With that kind of relationship, negotiation is not adversarial. It’s “Hey, we both want your company to make a lot of money and succeed. Otherwise, we’re all out of a job, so what can we do to make this happen?”
Ed: Right. It’s kind of just realizing that we’re all on the same team.
Andy: Yeah, exactly. Exactly, and that’s a hard road for some folks to go down. Especially in a larger, more bureaucratic organization, there is very much the idea that it’s not all the same team.
Ed: Small teams, big teams—in every team, collaboration is vital to success. How does one increase one’s proficiency at collaboration?
Andy: I think it’s the same answer as how to increase your proficiency in anything, and that’s do it.
Ed: Practice. Okay.
Andy: Practice. Practice. Practice. You know, “How do you get to Carnegie Hall?” “Practice, man, practice.” That’s the joke, but that’s really it. This is something I harp on in my talks: “go with experience.” You know, experience really is the best teacher, so you want to set yourself up to be able to play with stuff, be able to work with it, be able to do it, ’cause, otherwise, even just reading about it, it’s not the same.
Ed: Right. Okay, well, what do you when you’re on a team that is having trouble with collaboration? How would you approach improving the collaboration when it’s determined that the collaboration is the problem?
Andy: I get them to talking. Anytime I’ve gone and consulted [with] a team where they’ve had those sorts of communication issues in between themselves, the number one thing that seems to help is something like a scrum standup meeting. It’s a daily meeting. It’s very focused on the agenda. You answer your three questions and you get the hell out of there. It’s not some lengthy meeting or discussion or diatribe. You don’t problem-solve; you don’t discuss. You answer the scrum three questions: here’s what I’m doing today, this is what I was doing yesterday, here’s what I plan to do tomorrow, here’s what’s in my way.
The idea is [that] whatever is in your way the manager takes as his to-do list, and you just go bop, bop, bop, bop around the room, and now everyone knows what everyone else is working on [and] if there’s an issue with that, but they don’t need to be working on it ’cause you did something similar last week, or you decided with somebody else that that’s not the way this project is gonna go or whatever. Now you’re aware of it. You know what everyone else is doing. You know what they were working on yesterday; you know what they’re blocked on. This person needs a QA machine. This person needs you to finish what you’re working on. You know, whatever it is, you get a sense of everyone’s pace, everyone’s velocity, because you hear day after day, “I’m doing this, now I’m doing that, now I’m doing this other thing.” You can tell if somebody’s falling behind.
It’s a really, really effective way just to get everybody playing on the same page. And then from there, you can do the little spur-off meetings, say, “Okay, well, let’s -- let’s work this out. Let’s solve this problem,” you know, whatever it takes. So that is the number one way to kick-start getting a team to communicate with each other.
Ed: Let’s close up with some personal questions. What sort of student were you in college?
Andy: Curious. I was a curious student.
Ed: All right. How much stock do you place in GPA and other traditional academic measures of success as a predictor of real-world success?