8

I recently took a position at a new company. I have experience as a full stack developer for 5+ years. From my understanding of my new position, my main focus will be mobile development but I will also be tasked with work on the server, and web client as well. After getting through all the interviews and the high level talk, I was able to get a look at the code and architecture. I am not impressed and quite scared as the technology stack is old for every platform.

My major concerns are:

  1. Languages versions are no longer supported for almost half a decade if not more with new versions available with constant talk about how new versions will break the code base.
  2. Server’s OS is also no longer supported for several years and new version are available but also is calmed that updating will break the applications.
  3. I believe I can count the number of open source libraries on my hands for each platform, they are also no longer supported and have been deprecated for years.
  4. The MVC framework is outdated by a second version which is a rewrite but no one seemed to know that when I mentioned it. I was also told I would not need to read up on this framework which surprised me.
  5. Copying and pasting of entire application platforms for expanding into new potential markets which I believe will create a maintenance nightmare.

In my previous jobs, we were using the latest technology and constantly updating. I enjoy using new technology as I play around with them outside of work and love sharing the information with my coworkers who are interested in talking about it. Unfortunately there are just a couple of people who share that interest at this new job.

I have a gut feeling that staying this course would not expand my career in the direction I want and would do more harm as I would like to be a software architect one day. Would managers or senior developers think that staying at a company like this be harmful to one's career or development skills?

Improve this question
5
  • 5
    That depends - do you hope for a future of being recruited into positions filled by scanning resumes for versioned tool names? Or do you hope for a future of being hired to solve challenging problems?
    – Chris Stratton
    Commented Feb 3, 2018 at 22:29
  • 1
    I like your perspective. I would prefer to be hired to solve challenging problems rather than keywords and buzzwords. My suggestions for the mobile application have been heard and the original owner of it is quite excited for those changes.
    – RandyDev85
    Commented Feb 3, 2018 at 23:02
  • Dealing with incumbent technology and helping figure out where it is strategically useful to modernize and where it is not can be fascinating, and a very useful capability you can play up in how you describe your role. But it's not work everyone enjoys, and it's not something the more blindly algorithmic recruiting efforts will understand.
    – Chris Stratton
    Commented Feb 3, 2018 at 23:10
  • 1
    I would have to say, someone leaving a company, especially after a short time, on account of the technology stack being used would be a huge red flag to me in an interview. As an interviewer, you are asking yourself, how well would this candidate "fit", and to be sure, there will always be things in need of updating, in every company.
    – Joe Stevens
    Commented Feb 4, 2018 at 8:53
  • Thank you for your insight. I have never been on that side of the interview process and am just kind of blown away at some of the practices I have been seeing. Your response sparked some curiosity from the perspective of the interviewer. What would your top 3 things you look for during an interview process?
    – RandyDev85
    Commented Feb 4, 2018 at 21:35

3 Answers 3

Reset to default
8

Your decision is really based on one factor.

How are changes viewed.

Having obsolete technology is not bad in itself. Having obsolete technology but refusing to update is.

Improve this answer
1
  • Thank you, I would agree. I will look into that more that just checking version numbers.
    – RandyDev85
    Commented Feb 4, 2018 at 21:36
4

If you can write good code in any language, you can write good code in any language.

It is true that your experience with certain technologies will help you get on board with companies who are still using those technologies. Be advised that old technologies are still more common than you may at first have thought; my company's flagship product is coded in COBOL, and we are just now replacing the NT4-based customer-located application servers with Windows 10-based servers.

A thing is not broken merely because it uses old technology, and if a thing is not broken, don't fix it.

Improve this answer
2

What you've described doesn't sound like a "old technologies" problem. Old technologies are great - they're almost all I use and I've made a lot of money with them.

Out of date stuff isn't the end of the world as long as you control the deployment environment, which this company seems like it does.

The concern from me comes from point 5 - the Copying and pasting. But that's not an old-technology problem; that's a short-sighted leadership problem. Once I fixed such problems at an old position of mine, and I received great praise for fixing them, and learned deep things and arcane bugs about the technologies we were using as a result.

You could learn a lot here - or even be responsible for driving best practices. If you work with them to fix these issues, then you might find yourself a very good home. If you don't like it, then I wouldn't worry. As long as you were productive, your resume will look good. You added value and gained experience.

And if they waffle on that, then I wouldn't stay. Not because of a supposedly out of date codebase, but because this type of product and development experience doesn't seem to be what you want. You seem to want to experiment and be free-form, but this company seems more of the "don't fix what ain't broke" mentality.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .