A little rant on the software industry?

Here's a reply to:
http://channel9.msdn.com/ShowPost.aspx?PostID=314711#314711

Look Pace, I'm worried that you're getting some mixed advice here. So I want to give you both sides here.

1. This behaviour is not abnormal in the development field. Moving jobs is not a guarantee that your problems will go away. However, I'm not saying that you should stay, read on
2. The MCTS designation is an excellent goal to pursue. It demonstrates dedication to your craft to both your current and future employers.

You are on the right path with #2, however, you are not on the right path with #1. But the problems are deep and complex and probably worth a couple of chapters in a good book, so bear with me on the quickie version (using your quotes). The fundamental thing to understand is that people know very little about programming and what's more, they have no mass or understanding of the complexities.

One problem I have making things here is that a lot of the people dont actually know what they want. That makes it hard to get some sort of spec to then turn in and program.

This is common, users have a difficult time pinpointing their needs. Not only do not they not know how to program, they've never analyzed their own processes that thoroughly. Your job as a Systems Analyst is to bridge this gap, your job is to convert process into programs.

This involves documentation and meetings and drawings and designs and flow-charts and e-mails back and forth, etc. If you are the only Programmer in your company, then you are also responsible for being the Systems Analyst, just like you're responsible for being the Tester and the DBA and the Architect. If you can't take this, then you will not be successful at your company, leave now, go to a software consulting firm and tell them that you only want to code. This will limit your salary and may limit your career advancement but you'll be comfortable. Truth is, we have lots of programmers out there, but very few people who can bridge the gap between programmers and users.

Now, if you want to make things better, then the onus is entirely on you! When you go in on Monday, make the decision that you will not work on anything that doesn't have a written spec. Cover your own a$$! You don't want to get chewed out at meetings, so write stuff down. When you have client meetings, take notes, take meetings minutes, send them out to attendees, get people to comment

If you get any flack whatsoever on this, tell your boss that you cannot work from a verbal spec. Tell them that if it isn't worth writing down, it isn't worth programming. If they persist, ask them "who's the software expert"? If they can't trust you to do the job they're paying for...?

The point is, it's your job to get the spec before you do any work. It's your job to get stuff in writing. You may be annoyed that people are yelling at you but you have do your job and stand your ground.

after all my work, that these "codes" are for internal purposes? Holy wtf!?!?! when were you going to tell me this? Why in the 10 meetings I have had trying to talk you out of this havent you mentioned this?

And this is what I'm talking about. Do you have minutes from the last 10 meetings? Specs? Documents of any kind that this manager has seen? Because you have to tell the manager that he's just changed the spec and you have to back that up!

How do I know in the future if something I am asked for is correct or wrong?

So I think you get the idea by now. WRITE IT DOWN! B/c that's your job and that's how you're going to cover your ass.

I want someone to give me a detailed or at least basic spec for me to work off. Instead I have to interpret what they say, which is often full of business speak and BS and make something based on that.

So that's the problem then, you're definitely at the wrong spot. You see, your bosses are angry at you b/c they think that your job is to interpret what they say and make it happen on the computer. But you don't want to interpret what they say. In fact it sounds like you want them to magically come up with a spec and all you have to do is program.

But that's the whole problem, they can't program! They don't know how to convert their BS-speak into computer code, that's why they hired you. Of course, you can only program if you know their business. So you have to bridge the gap, you have to understand their business AND you have to interpret that business into a computer system.

It's a two-way street here Pace, you feel like you're getting messed around AND they feel like they're getting messed around. They don't understand your business and you're not helping them.

Somebody has to step up and fix the problem and hopefully, by now, you understand what that is, b/c you're the only one who can fix it. You're the computer expert, you're the guy with the degree that says you know how to make computers work.