Slashdot Mirror
The Career Programmer
What's with the title? The Career Programmer: Guerilla Tactics for an Imperfect World is a gem of wisdom in a sea of dry, academic books on the software development process. It seems to mix equal parts of any software process book, Dilbert, and Sun Tzu's The Art of War. The development "process" that most developers find themselves enduring today isn't too dissimilar from the "process" that developers have endured for the life of our industry. Management specifies deadlines before they specify requirements, and frown when programmers start designing instead of immediately typing. There are a lot of things wrong with this, but the problem persists.
For this problem, there is at last a real answer. Duncan, a developer himself, brings the wisdom he's gathered during the course of his career to bear on the problem. Surprisingly, he succeeds. With exquisite humor and wry wit he prescribes remedies for the variety of ailments that beset the software development process. The Career Programmer helps software developers in the areas where they are often weakest, from dealing with the politics of an organization, providing estimates that are real, and coping with the realities of management driven timelines. In short, all of the things you never learn in any school except the school of hard knocks. If you want to avoid the endless death march, have a life outside your job, and gain credibility by delivering your software on time and under budget, this book is for you. This book is intended for software developers of all skill and experience levels, no matter which language or operating system they might use.
The Career Programmer differs from most books on the development process in several ways. First, and most importantly, it is a pragmatic book. There are no pretensions to developing the "one, true process" that is better than all of the rest. It concentrates on strategies that work. Different environments require different strategies, and this book doesn't ignore the impact of office politics on the development process. Many developers already know how to develop software in a perfect world, but few are allowed to gather requirements in sufficient detail, take adequate time for design, develop test plans or any of the other important aspects of development. There are a variety of reasons for this, and this book covers them well.
Second, this book provides much-needed balance to books that focus only on the development process, by reminding the reader why the company they work for is in business. Obviously, it's not to let you play with the latest cool tools, despite the attitudes of many developers I've known. Learning to appreciate what motivates the managers and executives at your company is vitally important if you want to succeed. They pay the bills, and you work for them. That makes them important, even if they can't code a bit. Last, succeeding in spite of your boss sometimes requires you to fly under the corporate radar to be successful. Like any good guerilla, you do your best work when you aren't noticed.
What's in the book? The first section of the book, "Software Development in an Imperfect World," introduces the reader to the realities of the corporate world. For someone just out of college, this section is bound to be a rude awakening. They probably didn't understand why Dilbert is so funny, either. However, there is a lot of information in this section that will be useful for veteran developers, especially those who feel that they shouldn't have to "play politics." Playing the political game doesn't have to mean you stab people in the back, but it sure helps if you don't want to be on the receiving end. This section lays out the issues and problems that are dealt with on a daily basis in many companies. If that sounds depressing, never fear, help is on the way.
The second section of the book, "Guerilla Tactics for Front Line Programmers," examines the development process, step-by-step over the life of a project, and provides useful, practical information on how to succeed in spite of the hurdles placed in your path. The reader is guided through requirements gathering, design, estimation, development and testing with an eye toward fixing the perceptions management often has about the development process. If you can convince the people you work for that it is in their best interest to let you gather requirements, design and test, in addition to writing code, you have achieved a great deal.
The best parts of this book are the chapters "Effective Design Under Fire," and "Managing Your Management." Again, both are practical approaches to real problems. "Effective Design Under Fire" alone is worth the price of the book. This is a tremendously pragmatic approach to the problem of limited time for design. I wish every developer I knew understood the concepts here. Frankly, the approach used in the book can make you look like a guru, both to your coworkers, and to your boss. Simply put, it works. "Managing Your Management" is also very valuable, with an emphasis on learning to speak the language of the folks you work for. Sometimes a good guerilla must blend in.
The Summary Something different than the run-of-the-mill development process book, The Career Programmer: Guerilla Tactics for an Imperfect World will allow you to gain control of your software projects. It provides pragmatic, useful information that will allow you to push your organization toward successfully delivering software on time. Even junior programmers can affect the development process when they follow the guidelines in this book. Chris Duncan's humorous writing style makes this a very enjoyable read.
Table of Contents
- Software Development in an Imperfect World
- Welcome to Corporate America
- Business Is War. Meet the Enemy.
- Good Coding Skills Are Not Enough
- Guerilla Tactics for Front Line Programmers
- Preventing Arbitrary Deadlines
- Getting Your Requirements Etched in Stone
- Effective Design Under Fire
- Practical Estimating Techniques
- Fighting for Quality Assurance
- Keeping the Project Under Control
- Managing Your Management
- Corporate Self-Defense
- Controlling Your Destiny
You can purchase The Career Programmer: Guerilla Tactics for an Imperfect World from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
Good job, finally a good book review on slashdot that I actually read completely and enjoyed. This book seems like it would be good for a lot of slashdoters who come online and complain about corporate politics and stressful situations in the workplace. I think a lot of tech people have trouble dealing with business types who don't understand the technical difficulties they face daily. I am still in college, and I have spent this summer as an intern in an IT department and have learned a lot about corporate politics, it's a bitch. I'm buying my copy now.
Visualize the world of wine
I think most techies would agree that the political & managerial aspects of IT/IS projects are by far the most difficult. Under the pressure that management brings to "get this up and running," it's only natural for budgets and estimates to be built around what are really best-case scenarios. The hard fight has to be taken on early, though, to make management understand that they can ask for a quick, well done, and cheap project, but they'll only get 2 out of those 3 qualities at best - they can't have it all.
A $10 million dollar project that was budgeted for $8 million is usually considered a failure - if that same project had been estimated up front at $11 million, it would be hailed as a success. And while management may balk at those estimates ("it has to come under $X"), that's when the techie has to dig in his/her heels and say that in their professional judgement that's what the cost will be and at that point whether the project is worth doing is for managment to decide.
Stop by my site where I write about ERP systems & more
They pay the bills, and you work for them. Is that why they blocked /. on the firewall?
My problem? I was perfectly gruntled, until some numbnuts came by and dissed me.
It's more expensive at bn.com. Amazon has it for 10 bucks less.
/sig
Sadly, the title of the book is becoming an oxymoron in the USA.
nohup rm -rf ~/. >& zen &
or is that in the next revision?
I'm about to graduate college, and my limited experience with offices and "networking" have convinced me it's something I really dislike. Is it better in small companies? non-profits? Or am I just being naive about human nature. Thanks.
Step 1. College
Step 2. Job
Step 3. Realize job sucks
Step 4. Write Book
Step 5. Profit
Were those too many steps?
I argue sometimes that corporations and 8 layers of politics are a bad place to design software.
But it's infeasible to get the kind of resources like a tape library, a giant SAN devices or an expensive switch in your bedroom.
At the end of the day open source programmers are happy, but they will always be limited by their own wallet.
so you can come up with great ideas, and have the owner's idiot laid off nephew implement them and get all the credit and raises.
Office politics and networking aren't dirty, they're just ways of keeping your face and name in people's minds as a positive, can-do sort of person.
Another review and interview with the author is available at
v iewGuerilla.htm
e erProgrammer.htm
Interview with the Author
http://www.vbrad.com/pf.asp?p=Reviews/books/inter
Book Review
http://www.vbrad.com/pf.asp?p=Reviews/books/brCar
Yeah, I was gonna say pretty much what the first poster said, but I hate "Me, too!" posts.
/., or for any forum for that matter, then read this review. Study it. Learn from it.
So, I'm telling honestpuck, who writes some of the shittiest reviews I've ever read, to study this review. It's good, almost perfect. In fact, it would be perfect if you cut it off at the "What's in the book?" section. Well, you could leave in the Table of Contents, but that isn't necessary.
If you're thinking of writing a review for
Just be sure to wear the gold uniform when you beam down -- you know what happens when you wear the red one.
Though I agree with the sentiment, make management understand that they can ask for a quick, well done, and cheap project, but they'll only get 2 out of those 3 qualities at best, there's often a complicating component of the developer's temperament and experience.
Many experienced developers will not accept an answer of, "Okay, I want Fast and Cheap, because I don't care about quality." They might sign on to the project expecting to blast out some code, but find it hard to cut corners on quality.
Many inexperienced developers will not accept an answer of, "Okay, I want Fast and Good, because the ultimate customer won't quibble about cost." They are probably not yet capable of developing a high quality product (above a certain complexity) without considerable care.
Many developers of any experience level have trouble delivering when offered the answer, "Okay, I want Cheap and Good, because we're not in the critical path of another schedule." Work on the project will expand to fill the time available, honing and polishing and improving. Or the project will be rushed to get it out of the way to do more interesting things with other projects.
[
When this book came out a year ago, I bought it, but was in the middle of massive death march. Frankly, the first three chapters depressed me! It hit a little too close to home. Of course, I wasn't sleeping either, and that turned out to be more important than reading.
I need more coffee... I read "death march" as "death match" and it still made sense, what with the "wasn't sleeping" and all..
Am I the only one still boycotting Amazon?
(cue chirping crickets)
-- http://frobnosticate.com
...you're a SICK, SICK, CANIBAL, and -
*cough*
If you're interested in seeing some of his work before throwing down cash, check out his his articles over at CodeProject.
Pro Developer: Creating Your Dream Project
Pro Developer: Throwing Money Out the Window
Pro Developer: Improving Your Career In Any Economy
Pro Developer: This is Business
Pro Developer: Delivering Quality Software
Vacancy for signature. Apply within.
Someone must has a deal. The review I sent in pointed to Amazon, and it was one of the things that got "edited" before being posted. If I'm wrong, one shouldn't have to go back too far to find a review that points to Amazon for purchase info. Right?
*** Sigs are a stupid waste of bandwidth.
I'm sorry.. maybe it's just me. This reads more like an advertisement than a book review. Did the reviewer say one critical thing about the book at all?
"you all know how to get certain things out of your carrear"
Yeah, open the trunk.
I'm probably going to pick this book up because I'm not only curious as to what I'll learn, but curious as to what similar and dissimilar lessions the author and I may have had.
The hardest lesson for me was that a lot of being a Programmer (job) has NOTHING to do with being a Programmer (activity). Once you realize it and even embrace it, you can do quite well, perhaps even better than you expected. But the hard fact is that all the coding and programming ability in the world won't save you from non-programming issues.
"The Sage treasures Unity and measures all things by it" - Lao Tzu
Some of us don't live our lives based on what some organization tell us to do, and organization which has its own problems and idiosyncracies. I'd prefer to save $10, and do something useful with it, like donating to groups pushing for modernizing patent laws.
To be more concrete on the issue: The problem is not that Amazon obtained a patent to one-click shopping. The problem is with the system for granting them the patent. If I were to boycott every company that holds broad patents, I would be left with very few commercial choices. I won't boycott a company for doing everything they can legally do to gain competitive advantage, that is their responsiblity to their shareholders.
-- Fighting mediocrity one bad post at a time.
as soon as I get out of work :)
--
I recomend killing yourself now, saves time.
"this is the gloaming"
radiohead
From my experience managing programmers: the programmers themselves are more of a limiter than either the budget or the corporate environment around them.
Even worse than arguing with management and not getting the time necessary to write a proper spec is getting the time to write the spec and then going to the programming team, asking for an estimate, and discovering that your senior programmers (10+ years experience) are unable to gauge how long it will take them to get the programming done. What really opened my eyes to this problem was reading Watts S. Humphrey's book, "A Discipline For Software Engineering".
If you're a professional programmer, then before you start pushing management for time to do things right, make sure you can hold up your end of the bargain.
I think a lot of tech people have trouble dealing with business types who don't understand the technical difficulties they face daily.
In many companies, developers restrict themselves to the development environments only. Many have never had to support the product they develop and most have never talked to an actual customer of the product they develop. I worked for a team that rotated developers into support, sales, and put some on a real, live customer site. In the beginning, we were hated, but many developers came to appreciate what they learned and became better developers because of it. Developers seem just as unwilling to understand the business side as the business side seems unwilling to understand developers. Both camps benefit from understanding the other.
Sheesh, somebody get this man some Prozac!
If your organization is bigger than 2 people you will encounter politics.
I believe you mistyped "1 person".
JP
...realize the world doesn't begin and end with the development environment.
...are willing to actually talk to customers and realize they are the sole reason for the developer's existence.
...are willing and able to support their own products.
...have actually implemented and customized in a production environment.
...have at least one good friend in the sales and support force.
He posts the same content-free review for every book (with slight mods to fit the book topic).
(Yes, I understand the concept of a bot performing mindless repetition, but it's still fairly ridiculous to mod him/it up.)
I want to drag this out as long as possible. Bring me my protractor.
Dick. :)
Your neighbour ought to get off his fat American burger chomping ass and employ himself doing something productive instead of suing his boss for stress.
"Avoid the small company that has been around and small for years. Such companies are often run by a clique of "founders" who like things done exactly they way *they* want and will not listen to any other suggestions (even if the survival of the company is at stake). A stagnant company has the worst politics."
That's one way to look at it. An alternative is that the founders realize the disadvantages of a larger business structure, and deliberately keep things small. As a post above you points out, bigger isn't always better.
One of the best reasons to network with other people in your field is to get a feel for how the job is different from place to place.
--------------
Together, we will drive the rats from the tundra.
Like "computer science" or "Microsoft Works".
...
I've been convinced for some time that the best programs are not written by career "programmers" but by people looking for innovative ways of solving problems. If you understand the problem *inside out* - and you would if you work with the problem every day - then programming a solution is a series of fairly well defined steps.
Of course, this approach won't necessarily scale up to big problems, because such non-professional programmers will have to read round the topic to optimize make their solution solve the problem efficiently - but a common-all garden problem solver can learn this skill.
My job title is "e-Commerce Analyst" but I spend a lot of my time writing programs to solve problems. My boss decided that this was preferable to the "career programmer" who might not always know the particulars of the problem but knows a great way to show a tree-view of a relational database with editable nodes
"It's not your information. It's information about you" - John Ford, Vice President, Equifax
"It's simple economics. Now what if some of these corporations offered relocation to existing employees, then what? Would some programmer cry foul over moving to India and making $25k (US) per year over there. $25k (US) in India would have you living like a kind."
Actually it's much more than mere economics, and goes back to about the '30s. Rather than trying to explain a complicated subject here, go read this book (your public library should have a copy).
I'm worried that there will not be any jobs when I finish school. With programmers jobs leaving like the textile jobs of the '90s.
1. Locate nearest wealthy white community.
2. Find house with nicest lawn in community from step 1.
3. Identify person caring for lawn in step 2.
4. ???
5. PROFIT!!
Even less at Overstock.com only $16.99 + $1 shipping at overstock
-- these are only opinions and they might not be mine.
"Fast, Cheap or Good. Choose One"
If you haven't noticed, EVERY SINGLE /. BOOK REVIEW points to bn.com. I hope that /. collects either:
/. could do such a disservice to their readers. bn.com is almost always WAY more expensive than Amazon. How much more does bn.com pay its affiliates than Amazon ?
1) a goodly chunk of the difference between bn.com's prices and Amazon's in its affiliate payments,
2) a big fat lump-sum affiliate payment for always linking to bn.com
At least that way we could rationalize how
Unless you are a superstar rookie. I came out of college into a small company (5 when I joined) and is now at about 10. Most of those folks were support folks so I was able to come in and pretty much lead the charge on the development side. In order to be able to do that though you need to be able to spend huge amounts of time on just work and be able to teach yourself everything and anything. The only time I deal with the politics is when in contact with outside large companies.
The subject sais it all except:8 &loc=106
http://www.buy.com/retail/product.asp?sku=3087286
set softtabstop=4 shiftwidth=4 expandtab nocp worlddomination
Sounds interesting. I will read it when it comes out in an electronic format such as Safari. Or does anyone know if it is already available elsewhere?
..if he didn't find anything wrong with the book? It just wasn't a stinker. Very few people like reviewing stinkers anyway because they're usually boring, and there are a lot of them. Really, I think that's why most of the book reviews on /. tend to be positive. Now, I do think that a professional reviewer would be obligated to review stinkers too, but these guys are volunteers.
Please mod this post only if you think others should/n't read this. I have enough ego^H^H^Hkarma. Thanks!
I was invited, by the CS department at my alma mater, to come back and speak a year after my graduation. They wanted me to give a talk about the 'real world' to those getting ready to graduate and enter the market. I remember covering many of the topics outlined in the chapter titles of this book. I was really honest.
When I got done the students where kind of "ashen faced". Oddly, I never got invited back to speak again...
and here are the same searches on Amazon
I was so disgusted with Overstock's search feature that I decided to screw the savings and just 1-click order it on Amazon. Way to go, Overstock!
Brien
Perhaps interestingly, I've found that B&N almost always has cheaper CD prices than Amazon.
Your neighbor should read this book. Maybe he'll be able to keep a job by correctly delivering projects and managing interoffice politics, then...
...or is that hitting a little close to home??
For context, 500 dead/day with no sign of improvement = quagmire, as in Vietnam. Much less than 1 dead/day on avg, with locals starting to run things and the potential for a stable, free Iraq != quagmire, but == incremental success.
By the way, "record unemployment" is just plain ignorant. By any historical standard, we're awfully close to full employment. Not all that long ago (think "Carter"), the unemployment rate, inflation rate, and interest rates were all well over 10%. I suppose it's too much to ask AC's (or others) to actually check to see if what they're saying remotely resemble truth, but whaddayagonnado....
Don't even get me started on grammar/spelling (at least four obvious errors in a 25 word post, would that be "record illiteracy"?)
The reviewer has actually done a useful job of literary criticism here, I believe.
If you think that "to criticize" is synonymous with "to complain about" or "to belittle", you may well be a good candidate for technical management.
"Skill shows through where genius wears thin." -Wittgenstein || Religion: uniting aviation and architecture.
Do these sort of problems still arise in open-source projects?
I agree 100% that that is reality. However, it is a bad thing for the US as a whole in the long run, something our government will realize and react against at some point. (Why do you think the EU exists?) The system "we" built, the high-tech interconnected world, is leveling the playing field world-wide, good for the vast majority of humankind, but bad for us.
Cheap, efficient shipping has moved much manufacturing overseas, and will move most of the rest. Technical interconnectedness will move "white-collar" jobs overseas at a startling rate. Companies cannot be faulted for doing what is required to survive. But the result will be a rise in the standard of living in many "third-world" nations, and a lowering of our standard of living over the coming decades. It may not be terribly swift, but it is the future.
Europe is attempting to forestall this through their EU moves and attempts to level the playing field economically (in their favor) through international accords. But we are already seeing the death of the stranglehold unions have on manufacturing in Europe, the writing is on the wall for the liberal holidays and other social practices. The EU surely hopes that by letting in the eastern European nations, they can use them as a valve to get cheaper labor and production costs yet maintain control over them and retain tax revenue, and live as much as they can within the walls of the EU for as long as they can. It won't work.
I fear greatly for the future of "first-world" nations. We have aging populations, declining birth rates, fewer taxpayers to pay increasing government funded burdens (health care, pensions, welfare for old people, so on). Governments pay you to have kids in some dying European nations. Our standard of living will fall as high-paid careers move overseas to nations which compete with far lower expenses, far lower population ages, equivalent talent-pools and education, and nowhere to go but up (on the standard of living pole). We'll be left with service-industry jobs, selling products (designed by a dwindling cadre of professionals who direct off-shore professionals) to people with less and less money to spare.
Get used to it.
As a professional developer with YEARS of experiance, I have to say I am so bloody tired of people trying to make a [bad!] analogy between software development and building houses.
Building a house is not a complicated undertaking. In fact, often house building is undertaken with a considerable amount of unskilled and semi skilled workers. Perhaps this is the case with some software projects as well, but asside from this, the critical difference is that pretty much anyone can see progress when a house is built whereas in a software project, very often things are almost invisible.
Too often in software development there are huge learning curves and a moving target. Often real science has to be done. None of this applies to house building.
Humprey starts his book by talking about putting an addition on a house. If there were an analogy to be made - then it should be in the conceptual process of designing the addition and not on the construction of same. Typically in the building process, design work is not considered to be part of the construction process and in fact you can actually buy the blue prints for a house off the shelf.
This is almost the exact opposite of systems/software development. Often in systems development the "analysis" of the problem is lumped in with the implementation and when it is not, the analysis phase is often so badly botched that it is practically usless.
To illustrate this, on one major project I was involved with, consultants were hired and paid an incredible sum to "do the analysis". After 2 years they had not produced a single line of code. As for their analysis? Well, the truth of the matter is that after two years those people had not even identified the problem!
Systems development is unfortunately somewhat a seat of the pants endevour. Yes, planning is necessary but it is also necessary to get into it and get your hands dirty as soon as reasonably possible. The reason for this is that until you try certain things you can never know they won't work. As Burns wrote: The best laid schemes of mice and men gang aft a-gley.
If house builders were faced with blue prints which were as bad as most "systems specs" they would throw their hands up in horror and probably offer to strangle the designer. House building is far more forgiving and far more routine than software development. Hense, trying to use house building as an analogy for systems development is pretty questionable at the best of times.
I prefer another title for The Career Programmer: Guerilla Tactics for an Imperfect World. "Programming for Packleds"
27b-6
I read this a year or so ago. The book makes some good points, but the poor writing makes the book a struggle to get through (and I wouldn't consider the good points presented worth it). You'd be much better off reading Debugging the Development Process and learning more about how your bosses are looking at you.
--dan p.
Learning to cope with a manger who does not allow sufficient time for gathering requirements, design, or testing is a defensive strategy. The pro-active worker will realize that such a manager is incompetent and fire him.
Here are some strategies for firing your boss that I have seen work:
1. Undermine him. If your colleagues are all convinced your boss is incompetent then you can collectively pound on him. Petition him for more time to do your job right. If he gives in, then he is learning and maybe not so dumb after all. If he continues, then you can collectively proceed to step 2.
2. Go around him. If you can make an ally of a senior employee, such as the CTO, and convince him that your boss is incompetent then you are home free. It's just a matter of time before he is fired.
3. Smack him around. Be nice to your boss when nobody else is around. But in meetings, especially when his superiors are present, bring up a concern that your group could do much better work if a better process were in place. You are setting a trap. If your boss makes the mistake of defending the current process, you have to be ready to convince everyone in the room that the current process is amateur, foolish, and symptomatic of an incompetent manager. In order to pull this off, you will need to be much smarter than him, be able to refer to successful development projects in your other jobs, and perhaps have a few allies in the room who can do the same.
If a group of programmers succeeds in firing their boss, it is very likely that their new boss will be selected from their own ranks. This can be a positive step forward for the group. Work together to find someone who understands process and is also skilled at diplomacy.
I am getting my money back a year later since IT sales have gone south. I have been on the bench for 6 weeks. Best tan for and Irish/Italian American who works in IT and lives in the Northeast, I might add. :)
Despite the grim sales forecast HQ still plans to retain me based on my performance last year. Which in large part I owe to the concepts I found in the book. Previously in years past, I found my interest in the industry waning because of draconian tactics used by management. This book rejuvenated me. It gave me the mental tools to deal with the PHB's and brought me a whole great deal more understanding of my situation as a trench programmer. Can't say enough about the book and have reread parts since I first purchased.
A hand up and a foot on every chest...
Sounds like a rant by someone who moved up a corporate ladder only to hit no-man's land and spend the rest of his days stuck doing the same thing, never moving up nor down.
In reality, there are entrepreneurs and there are grunts. If you're not in the mood to bet your shirt, put your balls on the line, cash out your life's savings on a long shot, you're a grunt and can't expect to have any leverage. Your bosses took risks. For every one there were thousands who failed and lost everything. You on the other hand have a reasonably stable income and less stress. Having stable income and a full head of hair in exchange for sometimes abusive leaders is reasonable in a capitalist world.
Projects and teams come and go. You can't get too attached to either. What matters is that you're programming.
How about a chapter at the end called "Transitioning your career from Software Engineer to McDonalds Burger Flipper". I think that applies to more programmers today than any of the other chapters.
Outdoor digital photography, mostly in New Engl
Now to answer your question about bringing those people down here, do you know how much redtape is involved in bringing someone over here? Do you have any idea about the costs of this, let alone the mention of doing so only to have that person leave for another co. the minute they get here?
Remembering the dot com boom, people in Santa Clara were working for 10 different companies in one year, and the attitude of those hiring them, was "Well if he worked for some many companies, he must be that good." bullshit. Why bring someone down into a revolving door of employment when most would rather remain where they are.
MoFscker
...if you have a security clearance.
There is development going on here that will never EVER be shipped overseas.
I am very small, utmostly microscopic.
I've been working in the computer industry since 1978, which included long stints at HP and Sun in the HP-UX and Solaris Networking/Operating Systems Organizations From my perspective the scenarios that are dicussed in this thread and many others are due to both the flexibility of software development and the rigidity required to develop the desired software, resulting in a continuous conflict that few teams are ever able to resolve. The processes and practices used by most companies in silicon valley are still stuck in the 1980's. The infratructures used to support development efforts at most companies are also stuck in the 1980's. Case in point: Most popular source control tools are based on SCCS, RCS and ClearCase (think Apollo DSEE from the 80's). Most popular editors are based on Emacs, Vi. Most popular IDEs are based on Microsoft and Borland from the 1980s. Most user interfaces are based on 1970's and 1980's look and feel (think HTML forms, think Microsoft, think Apple) One other key issues I've observed in silicon valley when it comes to software development: We have architects of technology but we don't have architects of product. To test this out in your situation, try to determine who owns the software development lifecycle and who owns the product. BigusKramicus
A lot of people who speak a lot of different languages live in them too! Go figure. Maybe has something to do with the fact that there is a lot of commerce and culture and etc. going on in them.
Note the capital "W".
"Your bosses took risks." What a crock of Young Republican cheerleading. In every large company which I had internal exposure, what was promoted was low-risk mediocrity. No surprises, you are promoted. Surprises, good or bad, are not liked. A good surprise gets you a end-of-year plaque at the Christmas party, and a bad on gets you fired. In the end there are people who are expert at covering up, adjusting numbers, and a few smart ones who are lazy but can turn up the heat when necessity calls.
Independant work in a startup or as a consultant / contractor is the way to go. Don't get yourself into a position where one big company is more than 1/3 your work though, because then the organization poison starts doing it's work.
I did the same thing, but ended up at Buy.com, and was disgusted by their shipping prices...
Bought it anyway, though. Scheduled to arrive: October 2007, but I saved 3 bucks!
/sig
Let's look at that realistically...
1. If I moved to India and accepted a job for $25K, that is almost immediately actually > $50K American. The reason is taxes. The group that measures how long Americans work to pay off their tax burden (the name escapes right now, STFW) estimates that the average American worker works until July to pay off the taxes, slightly more than 50%.
2. Now, why doesn't India tax their people at the rate America does? Another quick search on the Web shows that we have sent more than $55 Billion in foreign aid to India over the last 20 years. America built the infrastructure that allows them to train people to take American jobs and, as you put it, "live like a king" on their lower wages.
Damnit, I resent the fact that I am being taxed out of the market for technical jobs AND that my tax money is subsidizing those that I have to compete against!
You will still encounter politics.
Hey, your paycheck's got to come from somewhere, and that means you will have to deal with people.
"It's a very tangled subsystem." --Windows kernel guru
I haven't read the book but I noticed one of the chapters is "Getting Your Requirements Etched in Stone". I have been adding last minute requirements to my programs my entire career. At first I thought we were doing something wrong. But after a while I realized that people are fuzzy about what they want, they communicate imperfectly, and requirements change. The more accurate your requirements, the better, but unless you are writing a compiler or something, incorrect requirements are a fact of life. If your requirements are etched in stone, you are writing shelf-ware that nobody wants.
Over time, I've learned to write more modular, object oriented code so that a change in requirements can often be dealt with in one object rather than requiring a large scale re-write. Changes in requirements doesn't bother me as much as it use to.
Average unemployment rate under Reagan was higher than under Carter. Average inflation rate under Reagan was higher than under Carter.
"Even worse than arguing with management and not getting the time necessary to write a proper spec is getting the time to write the spec and then going to the programming team, asking for an estimate, and discovering that your senior programmers (10+ years experience) are unable to gauge how long it will take them to get the programming done. "
So essentially you believe the abstract claims of a book author more than you trust your own people. The complaints about programmers have been going on for years. Is it really likely that we are mostly incompetent or that our education is fatally flawed and all we need is a few simple rules to straighten us out?
Or is it more likely that we are no better or worse than any other workers and we perform fairly well under real-world conditions?
In my view, wishful thinking is human nature and the nature of management makes it more susceptible to that siren call then other roles. The fact is that managers probably have little power to move a deadline regardless of the accuracy of their people's time estimates.
Perhaps the time has come to drop the politically-correct scheduling phase, and just admit that we all know the due date and that has nothing to do with the amount of work required to get the job done.
Honesty is the ultimate discipline.
Consider working in a regional IT center of a large company. If you are accomplished and you attach yourself to a critical process, you can set yourself up as a small "fiefdom" and be mostly left alone.
Paying taco that hard-earned bread has its advantages, doesn't it? You can type all that out way in advance and just SPRING IT when the article comes out. NICE WORK!
It's humorous and demonstrates the ridiculousness of the Slashbot Slashdot moderation scheme. Loosen up.
So essentially you believe the abstract claims of a book author more than you trust your own people.
It's not about not trusting my staff, it's about having spent 10 years doing systems development before becoming a manager, reading a book that makes you realize something I hadn't realized on my own, and then applying that new idea. In other words, it's about learning and becoming a better manager, a better person, and a better developer.
The "use it or lose it" mentality is not nearly as strong with patents under U.S. law as with trademarks under U.S. law, but there does exist the doctrine of laches.
Will I retire or break 10K?
I'm a 'Business Analyst' according to HR. What does that mean?
I talk to people who do the same job everyday, and find ways to streamline the process for them. This is normally by writing programs. ie: Generate a report that means they don't need to log onto three different systems manually. Make a job press button instead of three screens of acknowledgements. Stuff like that.
People generally generally like it when I come and sit next to their desk. Things are about to get easier for them.
Yay me!
The hardest lesson for me was that a lot of being a Programmer (job) has NOTHING to do with being a Programmer (activity). Once you realize it and even embrace it, you can do quite well, perhaps even better than you expected
...things just aren't the way you'd imagined them to be you can (1) Accept and learn to enjoy the fact that you have a job where you are reasonably well paid to keep sharp at programming (or whatever your skill is) during the day and live the dream at night by working on Linux or just enjoying time with your family or (2) Recognize that this isn't a utopia and you might need to sacrifice a little to live the kind of life you want. Which means ... taking a risky cut in pay for a smaller company or even taking the plunge and starting your own, waiting tables or working at a temp service typing to pay the bills during the lean times.
...just my humble, soon to be modded down, two cents...
Amen brother! Preach on!
The thing that is really shocking me (it shouldn't, I know...) as I read these comments is how entrenched all of the coders seem to be in their prima donna mindsets. "I am a programmer, I want to be able to apply my artistic and creative flair," as if the marketing department managers don't want to push the envelope and do something really off the wall like they've seen in this month's trade journal... or the human resources people don't want to do the sort of in depth interviewing and cutting edge personality screening they read about happening at the best companies... or the accountants don't want...
You all* work for companies -- in a recessession, with global competition nipping at your heels. Companies that have clear objectives that they set. They may be "corporate". They may seem "unrealistic". They may feel impossible.
* (Except for those of you who are currently pursuring non-corporate paths... but then this thread isn't about you, is it?)
You want impossible? My city is dealing with a $40 million budget shortfall. (Hell, in California they have a $40 billion (with a b) dollar budget defecit!) They've slashed the library hours. They've stopped projects. They've cut services. They've cut the number of firefighters that we have on the streets to fewer than any other major US metro area. I don't agree with the funding cuts. I don't think the library board or fire chief agreed with having to reduce their staff to an impossibly low level. But the directive came down.
Remember, you are given a salary and health care and whatever else by company X in exchange for your performing service Y. They don't care that you secretly dream of doing something aesthetically pleasing. They want to get something out the door. They believe you can help with this so they hired you. You are part of their overall plan. If you can honestly see yourself as a visionary who can help them do something even better... something that will make their widget** an even better widget... by all means do this. Don't go "under the radar"... Don't sneak around breaking rules. Do things the right way -- and if you have to do something different, make a business case for it. Explain how this will make their widget better. Just like Rebecca from accounting or Pete from sales would do.
** Face it, what your company produces is a widget... unless you believe otherwise, but if you do, then you don't need this pep talk!
If you are working with a corporation (school/government/etc.), understand that you are one piece of a team. Non-programming things will always get in the way. That's the way it works. You don't have to work in the corporate world but that is the way it works for most of the real world. What you choose to do with that knowledge is up to you.
And if, in the end, things still don't sit right
I would have to say that explosives are the most abused technology in all of history.
Unless your prepared to move to India, upgrade you qualifications to a masters or doctorate degree and work for US$6000 a year or less, forget about programming as a career working for a large corporation.
OK. So did your new knowledge result in accurate time estimates from your experienced programming staff?
my company currently has a purchasing freeze on. :)
Company: "We support continued learning."
Engineer: "Ummm... I need this technical reference to do my job."
Company: "Sorry -- the purchasing freeze started yesterday."
Engineer: "Really? I didn't know the last one had lifted."
The interesting thing is, that when I went to b&n, they had no stock. Amazon on the other hand appeared to have heaps.
What a long, strange trip it's been.
The average inflation rate under Reagan (from 1/81 to 12/88) was 4.65%
source http://inflationdata.com
Carter definitely worse here, twice as bad.
The average unemployment rate under Carter (from 1/77 to 12/80) was 6.53%
The average unemployment rate under Reagan (from 1/81 to 12/88) was 7.53%
source http://www.neatideas.com/data/data/UNRATE.htm
Reagan incrementally worse here, about 15% different. More importantly, since I assume you're arguing that policies affect these numbers, are that Carter's unemployment rate was about as high when he left as it was when he entered, while Reagan's was consistently under 6% for the last 18 months of tenure
Additionally, the sum of these two (two thirds of the "misery index" - too lazy to remember/research the third - interest rates?) leads to 16.26% for Carter, and 12.19% for Reagan. Clear winner - Reagan.
Apology accepted.
Google's an amazing thing - you could have checked the numbers yourself in 2 min, rather than spouting nonsense. Note that I didn't make the comparison to Reagan, you did. I merely said that the numbers under Carter were miserable, which even most Democrats admit...
Actually, I think some of the offshoring is driven by hype and marketing from companies that provide offshore development services.
It reminds me a lot of the internet boom. Back then, you had tech pundits, consultants, and biased market research firms talking about how every company had to get online, or they'd risk being 'Amazoned', and have somebody beat them online and grab their marketshare.
As a result, there were lots of lame-ass, poorly thought out internet efforts, which were mostly profitable only for the consulting firms that did the work. Billions were wasted.
Now, you've got guys from these offshore services companies using the same rhetoric. They say that if you don't go offshore, your competition will do it first; implication being that you'll be doomed.
I think the offshore services firms will do quite well, but I think companies will waste many billions before figuring out what really works, and what they really need, rather than just going offshore due to panic, marketing, and rosy scenarios.
Unemployment numbers are always under reported, some people just have to live off savings and cant get benefits, or are forced to work some crap job 2 days a week, (thats not positive employment) , some just go into crime, (more profitable). But today most sjobs are service type, not real productive type jobs that MAKE STUFF, and theres a lot of people working for uncle sam. Whats the point of full employment if 80% of it is casual labour/part timers, earning below mean salary levels.
Liberty freedom are no1, not dicks in suits.
It's really sad when a book title contains a misspelled word. "Guerrilla" is the correct spelling. I went to the B&N site, where they had a small image of the cover, and it's wrong there.
Enby in Waltham