I'm not interested in support. I just want to write new code

Question

Buried deep in an interesting old thread was the assertation "I'm not interested in support. I just want to write new code".

Now, as adults, we have all gone through that phase, but, in reality, how could someone have talked us out of that attitude sooner?

My first thought is "then write good code that doesn't require you to support it".

Could any better advice have been offered?

---

For what it's worth, I am now "middle aged" and after my first 5 preofessional years of only being interested in code, I became more interested in design, then system architecture, then in the whole development cycle plus tool chain & SQA Processes. I always have, and always will, code in my free time as a hobby, but professionally it offers me little challenge.

Answer 1

Support usually means the code has been refined and used quite extensively. Reinventing the wheel means you're almost gauranteed to overlook something which had previously been solved in supported code.

Answer 2

On your day job you will always HAVE to support code you or your collegues wrote. Also, on some projects there are several levels of support, which may be able to close issues before they will hit you.

You may write something at home which does not need to be supported just for fun.

Answer 3

Supporting somebody else's code is hard. Especially when this code is broken. But as always there are also pros not just cons. As a support engineer you have to be better at coding then your predecessor. You have to understand where this crappy code went wrong. Understanding somebody else's mistakes will teach you not to do them in the first place. Also, fixing spaghetti code and making it clean could be very gratifying and give you a sense of achievement (I took this sh*t and make it clean and beautiful, yeah!).

Personally, I have to fix other people's defects, usually the hard ones. After all, when my code works as expected, I have a pleasurable feeling of satisfaction. And this is actually why I am doing my job... :)

Answer 4

The kid at the top is the one who writes new code. The rest of the guys are the REAL MEN.

Answer 5

"Support is golden"

Isn't it a known fact that people do value good service more than good product? See microsoft.com for confirmation.

Whether you like it or not, support is what the real value of your efforts come from, at least from the customer's perspective. So that, maintainability is what the value of your code should be evaluated by.

That's what the good software architecture needs for.

Answer 6

I had assumed that the OP didn't want to maintain his own code - what an attitude - hence my advice to write maintenance free code in the first place (as if such a thing were possible; but at least you can reduce the need for maintenance and can take some of the sting out of that which you need to do).

Other posters here seem to have thought that he didn't want to maintain other people's code. Unfortunately, that's part & parcel of the job. The best that he can do is to encourage others to write code which needs less maintainer (by prompting reviews, automated testing, ect) and is easier to maintain, by pointing out potential maintenance problems during code reviews (and insisting on clear, well laid-out, modular, well-commented, code with meaningful class & variable naes, etc).

Ultimately, you have to take the rough with the smooth & those interview questions about being a team player aren't just empty questions. If you want to grab all the glory and never get your hand dirty you are likely to be disappointed – and to find others willing to help you when you have problems.