Are you proud of your code?

An anonymous reader writes: I have a problem and I am hoping /. group therapy is the cure, so get on with the +5 comments, post haste! I am downright embarrassed by the quality of my work; specifically, my code. It is buggy, slow, fragile, and a nightmare to maintain. Documentation, requirements, automated tests? Does not exist. Do you feel the same way? If so, then what is holding you back from realizing your full potential? More importantly, what if anything are you planning to do about it? This picture, which many of you have already seen, captures several project failure modes. It would be humorous if it weren't so depressingly true. I enjoy programming and have from a young age (cut my teeth on BASIC on an Apple IIe). I have worked for companies large and small in a variety of languages and platforms. Sadly the one constant in my career is that I am assigned to projects that drift, seemingly aimlessly, from inception to a point where the client runs out of funding and the project is abandoned. Like many young and idealistic university graduates I hoped to spend my life programming passionately, but ten years later I look in the mirror and see a whore. I'm just doing it for the money. Have any developers here successfully lobbied their company to stop or cut back on 'cowboy coding' and adopt best practices? I'm not talking about the methodology-of-the-week, I'm referring to good old fashioned advice like keeping SQL out of the UI layer. For the big prize: has anyone convinced their superiors that the customer isn't always right and saying no once in awhile is the best course of action? Thanks in advance for your helpful advice.

Hate to say it, but...

[palegray.net]

Perhaps you should seek employment where programming isn't your primary job, or work for a company that doesn't rely of software development as a primary means of generating revenue.

I've worked a lot of jobs where my job title wasn't "programmer" or "developer", but I was given a large amount of freedom to develop quality in-house tools to solve very specific data manipulation or communications problems. Some of these internal tools became successful small projects in their own right, and I got the satis

Work for UTC

[arnwald]

Seriously, they are large and it was a pleasure to work for them.

T.

Real-life programming

[kabz]

I'm a real-life programmer, and sure, there are always times when you might get in a project that has some problems. Personally, if you can demonstrate your ability, you *will*, if you are good end up in a position where you can have a large enough influence to do some of the things you want.

If you're a good programmer, you should get to a place where you will be mentoring more junior programmers and from this point, you can be a good position to do some great work.

Good Luck!

What I want to know is....

[SirLurksAlot]

Why in the world you're bothering to ask /. about this? You've admitted that you are aware that your code sucks, you know that it can be improved. I also find it hard to believe that after 10 years working in the industry the quality of your code hasn't improved.

If so, then what is holding you back from realizing your full potential? More importantly, what if anything are you planning to do about it?

I think this is a question you should be asking yourself. If you know what is wrong with your work, stri

Teach to Learn

[BiscuitCreek]

I'm usually mentoring a new programmer who I hope will eventually take over the code I'm writing. I write with that in mind. Explaining along the way makes the code better. Structure helps newbies. I do get lots of nice comments about my code. And it generally works and lasts. Teach someone to write code and your own code will get lots better. Pet peeve about other folks code - saving a few letters makes functions, variables, etc absolutely mystifying. Classic... "OPhone". We spent days working on this thi