Hacker News Reader

Comment by SandB0x | Hacker News Reader

Dead end jobs destroy transferable technical skills. I've witnessed miserable scenes. Many people are stuck maintaining large pieces of poorly written software. They forget how to actually program because their work involves very little development, and becomes all about knowing how the specific piece of software works (and the company's admin procedures) so that they can fight fires and make minor changes.

Escape involves gathering the confidence and the determination for self study, so that applying for another job is even a viable option. Skunk-works type projects at work are strongly recommended.

View on HN

They forget how to actually program because their work involves very little development, and becomes all about knowing how the specific piece of software works (and the company's admin procedures) so that they can fight fires and make minor changes.

Great point.

Perceived value of a programmer at a start-up: Quality & quantity of software built and shipped.

Perceived value of a programmer in a legacy enterprise IT department: Knowledge of existing code base and ability to get things done with it.

I think we need a new name for these type of jobs, then. They're not actual programming positions, since development tends to be about solving problems.

Maintenance and production are two lexicographic options that somewhat relay the scope of the position: higher than data-entry, lower than engineering. Much in the same way that a front-end is not necessarily a web developer.

Maintenance is what the current discussion is about, but production should be considered as well: it's about interfacing with the existing tools to extend without fixing any of the serious architecture issues. As in a web producer. Or, someone who produces plugins for a given architecture, requiring extensive knowledge of the system but with no access to improve or modify said system.

I would call it a programming position, at least in my case.

Most of my time is dedicated to maintaining a legacy application that is horribly written, but my time is mostly spent either trying to come up with inventive ways to code around the existing design decisions, or trying to come up with a way to improve the design without disrupting service.

It's very challenging to do well, but it is definitely not fun.

Code Janitor.

I break things down into Developers and Hackers. A Developer tends to create new foundations using existing and documented API's. A Hacker works within a system, and focuses more on existing code and what it actually does than documentation. Hackers tend to be worth more in the short term, Developers tend to be worth more in the long term.

In some countries, programmer time marked "Maintenance" is expensed while that marked "Production" is depreciated over x years for tax purposes, so companies want their programmers to log their activities as "maintenance". If the auditors come, it had better have been maintenance. Perhaps the only real way to develop production code is work for a startup, but the recruiters won't be impressed if you want to go back to a large company later on.

I would remove the word "Perceived" all together (I can attest to it now and Ive only been here a month!). The other thing you missed with the value of a programmer in a legacy enterprise IT dept - ability to handle beauracracy and politics (i suppose thats one part of getting things done).

I did three years of maintenance programming on a proprietary enterprise Java Big Feaking Web App framework, fighting fires and making minor changes. I learned more about engineering in those years than in college, first job, and building two software businesses from scratch. Possibly combined. YMMV.

I learned a lot in the six months or so (of the job I have in mind), but it very quickly plateaued and from then on it was all very much self-directed learning, automating as much of my work as possible and writing tools to make my life easier and to learn new technologies. But there's only so much of that you can do without sufficient external challenges.

Most colleagues did nothing of the sort and were roughly as productive without developing any broader skills, as far as any performance evaluations showed. It's spending an hour performing repetitive manual changes to some code, or spending 55 minutes doing it programatically in Vim and gaining some precious Vim-fu in the process. The output is the same at the end but the programmer isn't.

When there is no further scope to learn from my work (apart from pipe dream re-write projects that never materialise) and I am not doing any significant critical or analytical thinking, I leave. It sounds like your place had a lot more to teach you.

You always learn a lot in your first job, whatever it is.

I think the job he referred to was not his first job

Oops, you are right. I misread.

Still your statement stand corrected. We learn a lot from our first job that is.

Writing and maintaining terribly-designed software is actually a really great way to learn software design. It makes it so that when you read about a technique or pattern, the application of that pattern is very real to you, in the sense of "Oh, if we had done this on component X of product Z, it would have prevent bugs like Y."

Understanding what to avoid can be as valuable as having an idea of what specifically to do. I feel like I'm learning a lot about the software development and management fields where I am now, mostly because I'm starting to realize why some things are so important as I learn about ways that the system can be terribly inefficient even while following the letter of Best Practices.

At least, I'm telling myself it's valuable experience so I can stick it out for the next six months.

This assessment is spot on. I'm in this situation now. While I haven't forgotten how to program, my skills have plateaued and have been at this level for far longer than I'd like to admit.

I eventually realized that I needed to get out. I've sent out my resume and interviewed, but have had little success. I really had no idea how bad off I was until I started interviewing at other companies. I can't overstate the value of "practice" interviews. I wish I had done a few practice interviews before starting the process with Google because I did very poorly when I had a phone screen with them. That was a major confidence killer. After the Google failure I interviewed with Apple and went pretty far into the process. I felt like the interviews went really well (phone and on-site), but it didn't work out. I did a few other phone screens with companies after Apple, but nothing came of them. Ugh.

With a family to support I have to stick it out until I find something else. I really want to start my own company, but I can't afford to quit my current job. In the meantime I'm squeezing in work on side projects where I can. It's pretty depressing and stressful.

Practice interviews are definitely important because interviewing skills are not improved by work experience - they are improved by interviewing experience.

Interesting side projects are also really valuable. They can demonstrate individual initiative, show competency in different technologies/practices/industries, and provide interesting talking points in your interviews.

There's a whole lot of Lexapro at the other end of that tunnel. Get out as soon as you can.

Wow, your sstatement read like the past six months for me. Good luck.

Thanks. Were you able to escape?

Those aren't necessarily untransferable skills. You can always bill yourself as being able to get up-to-speed on a new codebase quickly and pitch yourself to corporations that need someone to battle their existing, horrible codebase. They need people that can be productive within their codebase.

An additional plus is if you're good at pushing incremental change to the existing codebase to get it under control. (e.g. my company has a large pre-existing Perl codebase, some of which mirrors functionality of various modules/packages on CPAN -- some better, some worse -- and there is a lot of internal push to move towards things like Moose, Try::Tiny, etc where possible for newer classes, etc)

I would say a lot depends on your perspective. If you are aware of the situation and the specific environment you are trapped in, you can nonetheless extract a lot of transferable skill from that kind of work. You just need to look beyond the surface

Reply on news.ycombinator.com