Slashdot Mirror
The Pragmatic Programmers Interviewed
jpkunst writes "An interesting interview at the O'Reilly Network with Andy Hunt and Dave Thomas, authors of The Pragmatic Programmer, who recently started their own publishing company. Many topics are covered. Dave has this to say about outsourcing: 'To get job security, developers need to position themselves as highly effective business-value generators, working with the rest of the company to solve common goals. If you sit in your cube waiting for a spec to be thrown over the wall, then you may be in for a wait -- that spec might be in an envelope on its way to Bangalore'"
Let's see him try to send that spec through email. hehehe.
But seriously. System adminstrators seem to be about the only job you can't send overseas. The real programming jobs are all done in India these days, with planning and scheduling handled to a lesser extent in the U.S. since the collapse of the dot.com boom.
I don't begrudge the engineers in India, I actually think they are doing a very huge favor for most of us left in the U.S. They are relieving us of the cost of developing simple UIs and basic programmatic functionality while allowing us here at home the ability to spend time designing instead of coding. We can then send our designs overseas to the programmers in Inida for implementation.
But system administration still can't be outsourced. Programming can be, but sysadmin'ing and program designing (what's the right word??) can't be done by foreigners. It's got to be done right here at home by people whom we trust implicitly.
I have been pwned because my
'To get job security, developers need to position themselves as highly effective business-value generators, working with the rest of the company to solve common goals. If you sit in your cube waiting for a spec to be thrown over the wall, then you may be in for a wait -- that spec might be in an envelope on its way to Bangalore'
The man is so right on. I went freelancer a year ago myself. I have to stick right to the processes and problems in order for my IT stuff to deliver results that count. That's when IT work starts to be fun, actually has a meaning, produces happy customers and - on top of that - brings in the cash. I can only second what he says.
We suffer more in our imagination than in reality. - Seneca
Anyone notice that in their efforts to use outsourcing, companies are willing to commit themselves to levels of specifications that are just insane? I'm doing this right now. I'm writing up specifications that are so detailed it would be just as easy to write the code. Of course, if I was writing the code I would be discovering bugs at the same time and problems would be corrected sooner. I figure the number of our analysts is equal to the number of analysts and coders we'd have needed for a similar local project. All the money spent on outsourcing could have just been spent on documentation.
Outsourcing in my limited (just this 1 project) seems to be a good way for consultants to draw a fat fee while they manage the outsourced project. It is like watching someone buy something expensive but they're happy because they saved 20%. Not posting anon just in case this will get me fired and force me to move on.
t
To get job security, developers need to position themselves as highly effective business-value generators,
..and since nobody knows what the (*&%#)@$ that means, it provides every company with an automatic, built-in excuse to fire anyone, anytime, for any reason.
Business 1
Employees 0
working with the rest of the company to solve common goals.
Goal of the company: fire everyone as quickly as possible to save money so we can afford extra buffalo wings with our catered lunch.
Goal of the employee: to try and stretch seven weeks of stagnant, inadequate wages to pay for 12 months of rent, since ain't no FUCKING WAY this job is going to last two months.
Companies and employees no longer have common goals because middle management has put a great deal of thought and effort into making the workplace a toxic, hostile, adversarial environment which makes it much easier to keep the Just-In-Time-Fired(tm) policy generating quarterly revenue savings and bonus checks.
Working 80 hour weeks for piss-wages in a 19th century management structure is way way WAY past obsolete, and the workplace is a festering sphincter of liars, cheats and misery. Let's talk about fixing it instead of trying to be a "team player." We could start by replacing office politics with something that doesn't actively and constantly diminish good ideas and positive thinking.
Oh, and yes, I'm bitter.
I'm also right.
Business isn't willing to pay for products, innovation and careers, so we get brands, mortgage commercials and layoffs.
I am a programmer, but my main value to employers is that I spent ten years working in other capacities: management, sales, construction grunt work, you name it. As a result, I usually don't *need* specs from analysts or product managers, because I usually have more business experience than most of them and can figure it out for myself.
Most of the programmers I've worked with lack this experience, and as a result end up having to be told what to do because they don't understand the full context of the problem they're being asked to solve. They often come up with elegant solutions to the wrong problem...
>> position themselves as highly effective business-value
>> generators
Yeah, just like our bosses, let's talk about how "highly effective" we are and how much "business value" we generate. Let's do it INSTEAD of work, because that's what management seems to have been doing very successfully for the last decade.
How about BETTER MANAGEMENT? How about managers who, in fact, know what the fuck they're doing and have come from the very bottom, not straight from some stupid MBA program. Where the heck are you going to get them if all your "very bottom" is in India? Do you seriously think that folks who have no idea how software is built can successfully manage Indian technies? Think again then, "highly effective business value generator".
It's inspirational to realize that software consultants actually do what they do for money.
"Don't repeat yourself"
Durr.
"Think about the kind of work that can be effectively outsourced (where "effectively" is used in the context of some manager's opinion). Can they ship stuff offshore that can be specified down to some fine level of detail? Yup! Can they send repetitive, rule-based, highly constrained stuff overseas? You bet! The stuff that will stay is the stuff that involves more intuition, and more interaction. To get job security, developers need to position themselves as highly effective business-value generators, working with the rest of the company to solve common goals. If you sit in your cube waiting for a spec to be thrown over the wall, then you may be in for a wait -- that spec might be in an envelope on its way to Bangalore."
It's fun maintaining code from India. It's also fun to tell your customers and your boss what the program should do. You should try both sometime.
"Explain how agile processes can reduce risk. Explain how lightweight approaches can earn value faster. And explain how they should outsource the mundane stuff, and leave their talented pool of in-house developers free to work on the next revolutionary change to the company's business."
These are the same people that advocate nightly builds and all that other crap that just gets in the way. All you have to do to make a software project successful is have at least two people who don't suck at life working on it, and have them delegate the boring work to the people who thought going into computers would make them rich - all consultants do is take common sense and dress it up so it sounds good to management, and in turn, management gives them a shitload of money. I've never heard of a software house suddenly turning around and not sucking because "we hired a consultant, and his strategy was fricking awesome, and suddenly we were making products that like didn't suck, and it was pretty cool." Managers only hire consulants if their teams aren't making the numbers they should, so they can therefore justify the lower productivitivy of their teams by saying that they're "adapting to the new vision/strategy/paradigm," and that's usually enough to buy them a year of suckage until upper management wises up - and knowing upper management, that rarely ever happens.
Performance really doesn't play an issue in outshoring to India - if your job's so simple a monkey could do it, your job's going to get outsourced, regardless of your performance. You can't really match cost efficiency of someone who lives in a country with 1/10 the per capita income. All you have to do is pray for the language barrier and hope the companies who are employing offshoring all get burned when they need to maintain the code - I think it's a fad, but I've been wrong before.
problematic programmer? I thought maybe they interviewed someone from Microsoft!
I work in an IT department of a large company. The reason I'm confident that I can't be outsourced is because I'm not just a programmer. I do design and business analysis as well, meaning that I use technical tools to solve problems for the business. You cannot outsource problem-solving, because it requires communication with and knowledge of the business and its problems.
Even if 100% of programming were outsourced, application design and specification will always be done on-site. If businesses go this route, then what will happen is a meta-programming specification language will emerge. On-site 'analysts' will produce a 'document' in this specification language, and this will contain around 50% of the complexity of the finished application, which is why it will need to be in a very precise and well-defined language.
In order to communicate with a computer, you need to be extremely precise and know what you're doing. There's a complexity of information problem, because a computer can be told to do basically anything. I can't type one line and get a complex program. In the same way, I can't just tell a programmer 'write me a database app which does our accounting' either. I have to communicate my knowledge and requirements to the person. Depending on their prior understanding of the problem, that will be anywhere from 25% to 75% of the information in the finished program. You save a little because humans are (variously) intelligent, but really, you have the same problem--communicate the rules and behaviour of the application.
I like programming computers because it's an interesting way to solve problems. But it's my problem-solving ability which gives value to my company, not my ability to type in C.
We hired some chimps from a huge international consultancy. The document they produced is so piss-poor we are on our sixth draft. In the time this has taken (2 months) with two very expensive consultants working full time and two in-house developers checking their work part-time, we have
The threat of offshoring has been massively over stated. More and more companies are seeing that this process (send the requirement to India) is simply not cost-effective. It may take some time for all PHBs to see this but it will happen. That's business.
There is (hopefully) a happy ending. The outsource providers tendering for this gig are charging in the region of 700UKP/day (about $1200/day) for a Java programmer with about 3 years experience (I'm not making this up). Most say that they can cut that cost by about a third if we offshored. Well, gee, that's still more expensive than hiring some local contractor with 7 years experience who can sit down and talk to the business people. We're getting "buy-in" from management to save money and not offshore. We'll have a decision soon and it looks good.
Agile methodologies will be the saviour of the Western programmer.
--- "We've always been at war with Eastasia."
Coders in banks need to learn about interest and amortization, coders in nuclear facilities need to learn about half-lives and gamma rays, coders for phone companies need to learn about telephony, coders for mom and pop stores need to know about mom's left-hand arthritus (so avoid F1-F8).
Not only is it relevant or valuable for coders to understand the context of the business they are in, it's vital. In fact, code-sense should take backseat to business-sense (although informed by coder-logic). Too often a tech solution will be shoehorned in when a practical solution based on knowing the business will do.
One time I stopped a restaurant manager from uprooting and reconfiguring all of his networked terminals and printers the day before a national holdiay in favour of a solution involving no more than a sideways abacus sitting on the bar. It wasn't a technology problem, it was an information problem. For that day, and that day only, blender drinks were being made at the beer tub, not at the bar. Problem was, orders for blender drinks were printed out at the bar, not the beer tub. The plan was to rejig all the printers and terminals so that the beer tub would have a printer, and then to reconfigure the POS software to route blender drinks to the beer tub. This sounded like a lot of hassle for one day, and knowing the 'stability' of the POS system, it was a recipe for disaster. The beer tub was in clear view of the bar. All the person there needed to know was how many of 3-4 different blender drinks to make. My solution was this: get a colourful child's abacus and mount it horizontally, so the beads slide from left-to-right. Each row represents a different drink (yellow=pina colada, red=strawberry daiquiri, etc). When an order comes up in the bar, the bartender slides the appropriate bead(s) over. The person at the beer tent can see this, and make the drinks. The server collects the drinks and slides the bead back. At any time, the person in the beer tub knows how many of what kind of drinks to make, and nothing had to be rewired or reconfigured or coded. And it worked like a charm.
Of course, over the years I've come up with a lot of elegant solutions to a lot of wrong problems, but never regretted it once. Usually, a good solution to the wrong problem is about 70% of the solution to the right problem, and even if it's not it invariably ends up being the crucual 30% of some yet unforseen problem. Software's cool that way.
One problem that comes of being a competent and experienced coder is that managers assume you know everything and assume that they don't have to know anything, rendering them (more) useless.
The question I always ask myself before starting any coding is: "Is this going to let the user go home early? Or work late?"
Look, you sound like a kid I used to know (me) so let me offer you some helpful advice. This whole thing about "business value generation" is why you have a job in the first place, and until you understand it you're going to spend the rest of your life going from one de-.com-posed job to another. The days when companies would keep people around on the theory that they would somehow, someday make the company money are long since gone. On the other hand, if you really, consistently, solve your bosses' (note the plural) problems, you will never lack for work and never get fired.
I speak from experience. In 1998-2000, I was a consultant (UNIX systems, Networks, perl programmming.) In 2000, I read the tea-leaves, looked at the business cycle (you know, the thing Clinton claimed to have defeated) and came to the conclusion that it would be a good time to work for a major corporation who /might/ keep paying me through the recession. So, I looked at my clients - people who knew and would appreciate my abilities and compensate appropriately - and picked one to go to work at. Had no problem getting a job there, even though I suspect I was the highest salary in my group.
Unfortunately, the company I chose was WorldCom. I spent two years looking over my shoulder, waiting for the axe to fall, while it hit people all around me. But I also spent that two years fixing the problems that my bosses' wanted fixed -- and making sure that when I had an initiative or something I wanted to do, I explained it to them in terms of /their/ problems, not mine. So, it wasn't "this mail server setup is a huge kludge and I'm sick of messing with it and its obsolete and I want to replace it with something better" but "I'm fixing this mail server now, but we could've prevented this crash with a small investment of hardware and free software, thereby avoiding client downtime." At the end of the day, I was one of the lucky few who kept their jobs.
Why did I keep my job? Because, in the minds of my management and their management, I was a "highly effective business value generator." The people who lost their jobs didn't necessarily have fewer technical skills than me (although, frankly, a lot of them actually needed to go), and they certainly weren't disliked or unloved. What they didn't know was how to connect their job to the interests of the corporation. (N.B. Don't stab people in the back trying to get noticed. In fact, you should try to make them look good just as hard as you try to make you look good.)
So learn this lesson and learn it well: despite what 100 years of syndicalism, liberalism, socialism, and -- dare I say it -- labor unions may have led you to expect, your job as an employee is to produce business value that can ultimately be translated into money. The company does not exist for the purpose of caring for its employees or establishing a social safety net - it exists for the purpose of increasing shareholder value. If you can do that - increase shareholder value and make sure your boss knows you do it - you will /always/ land on your feet, even if you do happen to lose your job for a while.
That's part one of getting rich. Part 2 is "always saved 20% of your gross income in quality stocks." Part 3 is "don't be a jerk. Take care of people and they'll take care of you." Part 4 is, "have fun, whatever you do, because nobody likes a whiner."
"He who would learn astronomy, and other recondite arts, let him go elsewhere. " -- John Calvin, commenting on Genesis 1
I'm fixing this mail server now, but we could've prevented this crash with a small investment of hardware and free software, thereby avoiding client downtime
/always/ land on your feet, even if you do happen to lose your job for a while.
No, you aren't, because a) you don't have the authority b) the person who does have the authority won't approve it and c) the suggestion causes several people to complain that you aren't being a team player because everyone else in the department agrees that management was brilliant for approving the current mail server.
I've spent a few minutes in the cubicles. I know the basics.
If you can do that - increase shareholder value and make sure your boss knows you do it - you will
I automated a job that saved our company about 2,000 man-hours once. The resulting shitstorm of office politics led to one of the managers screaming hysterically at us in a five-hour process improvement meeting saying that if we ever made the management team look stupid again they would dock our paychecks.
The controversy continued for four months. The database team decided my idea was good enough to include in the next set of test procedures. The other teams all disagreed. Upper management had to be called in from their golf games. My guess is that half a million dollars was spent in meetings and overtime over those four months.
It was later explained to me, two of my co-workers and the entire database team (in a very slow, politically-correct voice) by an HR representative (unspoken threat: open your mouth again, and you're fired) that we should write a memo explaining our idea and send it to our immediate supervisor for approval before starting any new work.
We later found out that the Department Director (a Senior VP) with the unanimous approval of the entire senior management committee and several members of the BOARD OF DIRECTORS SPECIFICALLY ORDERED all of the group managers to ignore all such requests no matter how simple or worthwhile they may be. Those who made more than three suggestions in a month were told, in writing, to stop "wasting time on non-core projects" or re-assigned.
Two dozen people quit. Five were repeatedly threatened with their jobs, one to the point of having to go on disability for depression. Everyone else just kept quiet. The atmosphere in the office from that point forward was indescribably gloomy.
That was one of my few successful attempts to really do anything useful at a large company, or "increase shareholder value." I personally saved the company about $100,000. The company spent over half a million $ arguing about it and treating us all like idiots.
It is just further proof that competent, smart, skilled employees are not welcome in the workplace.
Business isn't willing to pay for products, innovation and careers, so we get brands, mortgage commercials and layoffs.
I got hired by a large software company to perf/stress test the app that was a mix of windows app and a webapp (very complex DHTML, custom ActiveX controls in some places, can run in online or offline mode, the latter is integrated with Outlook).
So I was a low level guy, and a new guy on the block to boot. I've done a quick evaluation of available tools and the only thing that could accomplish the task the way I liked it (and the way it made sense) was Mercury Interactive Load Runner. The only problem was - it was $150K for a license, and nobody was going to spend this kind of money on performance.
So after whining to the management for a while, I sat down and wrote my own replacement for this $150K tool that did all I wanted.
You know what happened next? You've guessed right, I got attacked by the management, Dev manager in fact (I hope he burns in hell when he dies). And dev manager and product unit manager were pals, so no matter what I did, the Dev manager would have his smalltalk with PUM and bring whatever I was doing to a grinding halt.
I've done this thing anyway (weekends, overtime) and shipped two versions of this god damn product with it. Dev manager eventually got fired for not being careful enough with his language when talking to customers.
My career got screwed, though. I only got one promotion on that team despite busting my ass REAL hard and delivering world-class "business value".
The moral of the story - you either fuck the product and do what the management says, or you fuck the management and yourself and do the right thing. There's no third way out. The way I see it, it's always better to get fired for doing something than for doing nothing.