5 ms·

Dead end jobs destroy transferable technical skills. I've witnessed miserable scenes. Many people are stuck maintaining large pieces of poorly written software.

• edw519 16y ago
  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.
  • sudont 16y ago
    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.
    • Periodic 16y ago
      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.
    • Florin_Andrei 16y ago
      Code Janitor.
    • Retric 16y ago
      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.
    • vorg 16y ago
      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.
  • flashgordon 16y ago
    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).
• pyre 16y ago
  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)
• patio11 16y ago
  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.
  • SandB0x 16y ago
    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.
  • kirubakaran 16y ago
    You always learn a lot in your first job, whatever it is.
    • ks 16y ago
      I think the job he referred to was not his first job
      • kirubakaran 16y ago
        Oops, you are right. I misread.
        • l0nwlf 16y ago
• ulf 16y ago
  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
• throwaway_plat 16y ago
  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.
  • LiveTheDream 16y ago
    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.
    • deleted 16y ago
      [deleted]
  • Florin_Andrei 16y ago
    There's a whole lot of Lexapro at the other end of that tunnel. Get out as soon as you can.
  • wheaties 16y ago
    Wow, your sstatement read like the past six months for me. Good luck.