How to deal with being mislead in a company after recent hire [closed]

The name of the pictureThe name of the pictureThe name of the pictureClash Royale CLAN TAG#URR8PPP





.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty margin-bottom:0;







up vote
5
down vote

favorite












I was recently hired into a new job as an application developer. I have over five years experience as an application developer. Post hire, I realize what I was lead to believe at the interview is far from the reality I was greeted with on the first day. The company had been pursuing me for almost three months before I went in to meet their hiring manager. Since starting, I've come to realize a few things about the company. First, I'm the only developer, expected to rewrite an entire application that is over six years old and has never been properly designed to begin with. No version control, no design methodologies, no checks and balances for application management, and no documented long term roadmap for how the application should be redesigned



Additionally, I feel stuck in a place between upper management who has redesign and modernization aspirations for the application and a director I immediately report to who doesn't even work in the office, is not much of a coder and is not so eager to stop building onto the current cumbersome system because he seems intimidated by the idea of new technologies that are out of his realm of expertise. With their current application using a technology not even 5% of the market uses, and no concrete timeframe for application redesign, I feel to be here for the long term would actually be damaging my long term growth potential as a developer, short of me maintaining side work developing applications on modern technologies like .Net and Ruby. Just curious if others have had similar experiences and how they dealt with such situations.







share|improve this question














closed as off-topic by Jonast92, mhoran_psprep, Michael Grubey, The Wandering Dev Manager, Telastyn May 10 '15 at 22:57


This question appears to be off-topic. The users who voted to close gave this specific reason:


  • "Questions asking for advice on what to do are not practical answerable questions (e.g. "what job should I take?", or "what skills should I learn?"). Questions should get answers explaining why and how to make a decision, not advice on what to do. For more information, click here." – Jonast92, mhoran_psprep, Michael Grubey, The Wandering Dev Manager
If this question can be reworded to fit the rules in the help center, please edit the question.












  • Please note that we can't give you specific advice here. Only you know your situation well enough. I would suggest rewriting to ask for general suggestions.
    – DJClayworth
    May 10 '15 at 15:16






  • 9




    Be advised that developers almost always have a bias towards abandoning something they don't like before fully understanding it - see here for an example
    – user2813274
    May 10 '15 at 15:22






  • 2




    Hi Alex, welcome to the Workplace. This is a Questions & Answers site, so please make sure you have a clearly stated question that can be answered. It is important not only for you to get the answer you need but for others landing on this page as well.
    – Pavel
    May 10 '15 at 17:21






  • 3




    Alex, you say you were misled. What explicitly did they tell you that turned out not to be true? Or did you just assume things that you thought were normal?
    – DJClayworth
    May 10 '15 at 18:07






  • 1




    I was informed there would be a total of three developers working on revamping the application; two currently on staff and myself being the third person. Post hire, it turns out there aren't 3 developers; just one who isn't even touching the app and moved on to solo freelance work, then the person I report to who informed me they don't have plans of coding the application, just acting as a remote manager; which thus leaves just me.
    – Alex
    May 10 '15 at 18:11
















up vote
5
down vote

favorite












I was recently hired into a new job as an application developer. I have over five years experience as an application developer. Post hire, I realize what I was lead to believe at the interview is far from the reality I was greeted with on the first day. The company had been pursuing me for almost three months before I went in to meet their hiring manager. Since starting, I've come to realize a few things about the company. First, I'm the only developer, expected to rewrite an entire application that is over six years old and has never been properly designed to begin with. No version control, no design methodologies, no checks and balances for application management, and no documented long term roadmap for how the application should be redesigned



Additionally, I feel stuck in a place between upper management who has redesign and modernization aspirations for the application and a director I immediately report to who doesn't even work in the office, is not much of a coder and is not so eager to stop building onto the current cumbersome system because he seems intimidated by the idea of new technologies that are out of his realm of expertise. With their current application using a technology not even 5% of the market uses, and no concrete timeframe for application redesign, I feel to be here for the long term would actually be damaging my long term growth potential as a developer, short of me maintaining side work developing applications on modern technologies like .Net and Ruby. Just curious if others have had similar experiences and how they dealt with such situations.







share|improve this question














closed as off-topic by Jonast92, mhoran_psprep, Michael Grubey, The Wandering Dev Manager, Telastyn May 10 '15 at 22:57


This question appears to be off-topic. The users who voted to close gave this specific reason:


  • "Questions asking for advice on what to do are not practical answerable questions (e.g. "what job should I take?", or "what skills should I learn?"). Questions should get answers explaining why and how to make a decision, not advice on what to do. For more information, click here." – Jonast92, mhoran_psprep, Michael Grubey, The Wandering Dev Manager
If this question can be reworded to fit the rules in the help center, please edit the question.












  • Please note that we can't give you specific advice here. Only you know your situation well enough. I would suggest rewriting to ask for general suggestions.
    – DJClayworth
    May 10 '15 at 15:16






  • 9




    Be advised that developers almost always have a bias towards abandoning something they don't like before fully understanding it - see here for an example
    – user2813274
    May 10 '15 at 15:22






  • 2




    Hi Alex, welcome to the Workplace. This is a Questions & Answers site, so please make sure you have a clearly stated question that can be answered. It is important not only for you to get the answer you need but for others landing on this page as well.
    – Pavel
    May 10 '15 at 17:21






  • 3




    Alex, you say you were misled. What explicitly did they tell you that turned out not to be true? Or did you just assume things that you thought were normal?
    – DJClayworth
    May 10 '15 at 18:07






  • 1




    I was informed there would be a total of three developers working on revamping the application; two currently on staff and myself being the third person. Post hire, it turns out there aren't 3 developers; just one who isn't even touching the app and moved on to solo freelance work, then the person I report to who informed me they don't have plans of coding the application, just acting as a remote manager; which thus leaves just me.
    – Alex
    May 10 '15 at 18:11












up vote
5
down vote

favorite









up vote
5
down vote

favorite











I was recently hired into a new job as an application developer. I have over five years experience as an application developer. Post hire, I realize what I was lead to believe at the interview is far from the reality I was greeted with on the first day. The company had been pursuing me for almost three months before I went in to meet their hiring manager. Since starting, I've come to realize a few things about the company. First, I'm the only developer, expected to rewrite an entire application that is over six years old and has never been properly designed to begin with. No version control, no design methodologies, no checks and balances for application management, and no documented long term roadmap for how the application should be redesigned



Additionally, I feel stuck in a place between upper management who has redesign and modernization aspirations for the application and a director I immediately report to who doesn't even work in the office, is not much of a coder and is not so eager to stop building onto the current cumbersome system because he seems intimidated by the idea of new technologies that are out of his realm of expertise. With their current application using a technology not even 5% of the market uses, and no concrete timeframe for application redesign, I feel to be here for the long term would actually be damaging my long term growth potential as a developer, short of me maintaining side work developing applications on modern technologies like .Net and Ruby. Just curious if others have had similar experiences and how they dealt with such situations.







share|improve this question














I was recently hired into a new job as an application developer. I have over five years experience as an application developer. Post hire, I realize what I was lead to believe at the interview is far from the reality I was greeted with on the first day. The company had been pursuing me for almost three months before I went in to meet their hiring manager. Since starting, I've come to realize a few things about the company. First, I'm the only developer, expected to rewrite an entire application that is over six years old and has never been properly designed to begin with. No version control, no design methodologies, no checks and balances for application management, and no documented long term roadmap for how the application should be redesigned



Additionally, I feel stuck in a place between upper management who has redesign and modernization aspirations for the application and a director I immediately report to who doesn't even work in the office, is not much of a coder and is not so eager to stop building onto the current cumbersome system because he seems intimidated by the idea of new technologies that are out of his realm of expertise. With their current application using a technology not even 5% of the market uses, and no concrete timeframe for application redesign, I feel to be here for the long term would actually be damaging my long term growth potential as a developer, short of me maintaining side work developing applications on modern technologies like .Net and Ruby. Just curious if others have had similar experiences and how they dealt with such situations.









share|improve this question













share|improve this question




share|improve this question








edited May 10 '15 at 15:22

























asked May 10 '15 at 15:07









Alex

3,3561130




3,3561130




closed as off-topic by Jonast92, mhoran_psprep, Michael Grubey, The Wandering Dev Manager, Telastyn May 10 '15 at 22:57


This question appears to be off-topic. The users who voted to close gave this specific reason:


  • "Questions asking for advice on what to do are not practical answerable questions (e.g. "what job should I take?", or "what skills should I learn?"). Questions should get answers explaining why and how to make a decision, not advice on what to do. For more information, click here." – Jonast92, mhoran_psprep, Michael Grubey, The Wandering Dev Manager
If this question can be reworded to fit the rules in the help center, please edit the question.




closed as off-topic by Jonast92, mhoran_psprep, Michael Grubey, The Wandering Dev Manager, Telastyn May 10 '15 at 22:57


This question appears to be off-topic. The users who voted to close gave this specific reason:


  • "Questions asking for advice on what to do are not practical answerable questions (e.g. "what job should I take?", or "what skills should I learn?"). Questions should get answers explaining why and how to make a decision, not advice on what to do. For more information, click here." – Jonast92, mhoran_psprep, Michael Grubey, The Wandering Dev Manager
If this question can be reworded to fit the rules in the help center, please edit the question.











  • Please note that we can't give you specific advice here. Only you know your situation well enough. I would suggest rewriting to ask for general suggestions.
    – DJClayworth
    May 10 '15 at 15:16






  • 9




    Be advised that developers almost always have a bias towards abandoning something they don't like before fully understanding it - see here for an example
    – user2813274
    May 10 '15 at 15:22






  • 2




    Hi Alex, welcome to the Workplace. This is a Questions & Answers site, so please make sure you have a clearly stated question that can be answered. It is important not only for you to get the answer you need but for others landing on this page as well.
    – Pavel
    May 10 '15 at 17:21






  • 3




    Alex, you say you were misled. What explicitly did they tell you that turned out not to be true? Or did you just assume things that you thought were normal?
    – DJClayworth
    May 10 '15 at 18:07






  • 1




    I was informed there would be a total of three developers working on revamping the application; two currently on staff and myself being the third person. Post hire, it turns out there aren't 3 developers; just one who isn't even touching the app and moved on to solo freelance work, then the person I report to who informed me they don't have plans of coding the application, just acting as a remote manager; which thus leaves just me.
    – Alex
    May 10 '15 at 18:11
















  • Please note that we can't give you specific advice here. Only you know your situation well enough. I would suggest rewriting to ask for general suggestions.
    – DJClayworth
    May 10 '15 at 15:16






  • 9




    Be advised that developers almost always have a bias towards abandoning something they don't like before fully understanding it - see here for an example
    – user2813274
    May 10 '15 at 15:22






  • 2




    Hi Alex, welcome to the Workplace. This is a Questions & Answers site, so please make sure you have a clearly stated question that can be answered. It is important not only for you to get the answer you need but for others landing on this page as well.
    – Pavel
    May 10 '15 at 17:21






  • 3




    Alex, you say you were misled. What explicitly did they tell you that turned out not to be true? Or did you just assume things that you thought were normal?
    – DJClayworth
    May 10 '15 at 18:07






  • 1




    I was informed there would be a total of three developers working on revamping the application; two currently on staff and myself being the third person. Post hire, it turns out there aren't 3 developers; just one who isn't even touching the app and moved on to solo freelance work, then the person I report to who informed me they don't have plans of coding the application, just acting as a remote manager; which thus leaves just me.
    – Alex
    May 10 '15 at 18:11















Please note that we can't give you specific advice here. Only you know your situation well enough. I would suggest rewriting to ask for general suggestions.
– DJClayworth
May 10 '15 at 15:16




Please note that we can't give you specific advice here. Only you know your situation well enough. I would suggest rewriting to ask for general suggestions.
– DJClayworth
May 10 '15 at 15:16




9




9




Be advised that developers almost always have a bias towards abandoning something they don't like before fully understanding it - see here for an example
– user2813274
May 10 '15 at 15:22




Be advised that developers almost always have a bias towards abandoning something they don't like before fully understanding it - see here for an example
– user2813274
May 10 '15 at 15:22




2




2




Hi Alex, welcome to the Workplace. This is a Questions & Answers site, so please make sure you have a clearly stated question that can be answered. It is important not only for you to get the answer you need but for others landing on this page as well.
– Pavel
May 10 '15 at 17:21




Hi Alex, welcome to the Workplace. This is a Questions & Answers site, so please make sure you have a clearly stated question that can be answered. It is important not only for you to get the answer you need but for others landing on this page as well.
– Pavel
May 10 '15 at 17:21




3




3




Alex, you say you were misled. What explicitly did they tell you that turned out not to be true? Or did you just assume things that you thought were normal?
– DJClayworth
May 10 '15 at 18:07




Alex, you say you were misled. What explicitly did they tell you that turned out not to be true? Or did you just assume things that you thought were normal?
– DJClayworth
May 10 '15 at 18:07




1




1




I was informed there would be a total of three developers working on revamping the application; two currently on staff and myself being the third person. Post hire, it turns out there aren't 3 developers; just one who isn't even touching the app and moved on to solo freelance work, then the person I report to who informed me they don't have plans of coding the application, just acting as a remote manager; which thus leaves just me.
– Alex
May 10 '15 at 18:11




I was informed there would be a total of three developers working on revamping the application; two currently on staff and myself being the third person. Post hire, it turns out there aren't 3 developers; just one who isn't even touching the app and moved on to solo freelance work, then the person I report to who informed me they don't have plans of coding the application, just acting as a remote manager; which thus leaves just me.
– Alex
May 10 '15 at 18:11










2 Answers
2






active

oldest

votes

















up vote
7
down vote














No version control, no design methodologies, no checks and balances
for application management, and no documented long term roadmap for
how the application should be redesigned




..You mean the real world ? I hate to break it to you, but this is the status quo.



We often come into the workplace from academia, where we hear about many abstract and theoretical things.



Now , I'm not saying that it doesn't exist in the real world - this beautiful organization and system thing. It does... but it's far less available than you'd think. Even at the top firms, things can get crazy pretty fast.



Overall, I think you need to make the most of it. Do you have the leverage, to easily jump ship and find your ideal job?



Or are you still relatively early in your career? Would you perhaps benefit from gaining this somewhat "chaotic" experience? Perhaps you can "turn lemons into lemonade" ?



Also, that whole part about the "interview being different from reality"(c. ) , oh that is just marketing :-)



my two cents. good luck in your career !!






share|improve this answer


















  • 2




    I understand its not perfect. I've worked in other companies where It was a team of developers, which was the statement made here as well, but turns out I'm solo. Their internal application is using technologies 10 years old, over several hundred DB tables, an estimated 200,000+ lines of code spread across about 250 files and counting. I'm still trying to read through their code to see how everything connects. They don't really have the gusto to bring it into the present. In the end, how do you market maintaining a language skill hardly any other company is using?
    – Alex
    May 10 '15 at 16:13







  • 2




    @Alex: To rewrite that application, based on your description, would take a decent sized team (5+) a fairly long time (1 yr+) to handle. That represents a significant investment of money for what sounds like a small business. I'd say the odds of it happening are between slim and none.
    – NotMe
    May 11 '15 at 15:49










  • @NotMe. Exactly. When I worked on similar applications, it was a team of 4 of us. Usually 2 to write logic, classes and controllers, 1 to handle DB and 1 to handle UI, They expect one person to handle it all, and their wordpress system as well. This system is suppose to be there bread and butter for business and how they get everything done because they refused to use a commercial system that is industry supported.
    – Alex
    May 11 '15 at 16:07

















up vote
5
down vote













I was in a very similar situation. Eventually I had to leave the company, but that may not have been the best idea.



As Adel points out, you're going to see this in a lot of companies. When I left work, I started picking up some Freelance work to make ends meet and working under some of the contacts I had made. Out of the 7 Companies I've developed for thus far, none of them had any documentation, multiple versions of software scattered around the business and didn't even understand what a long-term roadmap was. The guys with money do not work with code, so they don't care about any of that stuff.



What I tend to do, if it's a fairly small project that has just became overcomplicated with time, is try to convince the client that it would be better to redevelop from scratch. Then put those documents together myself and comment the code. There's a lot of loopholes you're going to have to jump with this though.



First of all, as you've noticed... people do not like change. They like sticking to the comfort of old technologies, new stuff requires effort to learn. If you can show them that their part of it will remain practically the same, that will soften the blow. Keep the same UI elements, keep the same layout, keep changes with how they interact with the software to a minimum. (I also tend to throw out the words "Future Proofing" a lot, management seem to like those words. They tend to imply that they won't need to invest as much later down the line, which is true if you do it right).



Secondly, companies will always have doubts about something untested VS something they know works. There's a risk element, you need to keep this to a minimum and pull every fact that you can in your favour. If I come up against someone really reluctant to change, I tend to make them a little power-point with the strengths of the change. If you want to switch from some ancient language nobody uses any more, make sure the higher ups understand why everyone else has already switched to these new technologies. Use real-world examples to prove that it works.
How much quicker will it be to implement changes?
How many limitations will this remove?
How much more secure will the software be?
How much cheaper will future development be?
They're not going to care one bit about how much easier it is for you, or how much it will help you develop as a programmer... they want to see what benefits it has for them and the bottom line.



Lastly, make sure there isn't a genuine reason for it. One of the companies I developed for were handling logistics on behalf of another client. I wanted to change their software from Visual Basic 6 to .NET 4.5, only to find that their client required access to the code, and their tech guys only worked in VB6... so that was a complete no-go for upgrading. This stuff happens and then you just have to grin and bare it. You might find other technical reasons for this as well, such as having to interact with ancient software elsewhere in the business.



Also one last note. If you're going to write out documentation, make sure it's okayed with your superiors first. Even though it can be invaluable to programmers, there are companies that will see that as a major waste of your time and their money.



Good luck!






share|improve this answer






















  • Your answer makes a lot of sense. I'm trying to take that approach. My challenge is the physically non-existent director I report to is the bottleneck. The CEO wants to change to a different technology that is mainstream, but he gives the director a lot of headspace to act and that director is intimidated by anything outside of his limited scope. I was baffled when I asked him what kind of apps he builds on the side and he said he doesn't. He doesn't know what Ruby. Python, or C# is.
    – Alex
    May 10 '15 at 17:53










  • I find that you get this a lot. A lot of the guys I've reported to have only ever used one language and have absolutely no interest in programming outside of their 9 to 5. You'll likely find your Director wasn't originally a "tech guy" and simply got stuck with it at some point. This is pretty common. My original advice still stands on that situation. Make it seem like his job is going to be easier. It's much easier if you're using simple tools, such as Visual Studio, where you can showcase the Drag & Drop functions to make it look like he'll be able to stay on top of it.
    – Darryl_Holmes
    May 10 '15 at 19:16







  • 1




    I was in this situation as well and I agree with @Darryl_Holmes . When you walk into a company for a job chances are pretty high that your going to be sifting through a ton of code. Pretty much all non-tech founded companies have higher management that don't understand code, they just want results. What happens when there's multiple developers is that things get added and as time goes on and more developers swap out, things get changed even more. Little bits here and there, and because of time constraints or irritability, no one comments things as much as they should. Name of the game.
    – zfrisch
    May 11 '15 at 0:59


















2 Answers
2






active

oldest

votes








2 Answers
2






active

oldest

votes









active

oldest

votes






active

oldest

votes








up vote
7
down vote














No version control, no design methodologies, no checks and balances
for application management, and no documented long term roadmap for
how the application should be redesigned




..You mean the real world ? I hate to break it to you, but this is the status quo.



We often come into the workplace from academia, where we hear about many abstract and theoretical things.



Now , I'm not saying that it doesn't exist in the real world - this beautiful organization and system thing. It does... but it's far less available than you'd think. Even at the top firms, things can get crazy pretty fast.



Overall, I think you need to make the most of it. Do you have the leverage, to easily jump ship and find your ideal job?



Or are you still relatively early in your career? Would you perhaps benefit from gaining this somewhat "chaotic" experience? Perhaps you can "turn lemons into lemonade" ?



Also, that whole part about the "interview being different from reality"(c. ) , oh that is just marketing :-)



my two cents. good luck in your career !!






share|improve this answer


















  • 2




    I understand its not perfect. I've worked in other companies where It was a team of developers, which was the statement made here as well, but turns out I'm solo. Their internal application is using technologies 10 years old, over several hundred DB tables, an estimated 200,000+ lines of code spread across about 250 files and counting. I'm still trying to read through their code to see how everything connects. They don't really have the gusto to bring it into the present. In the end, how do you market maintaining a language skill hardly any other company is using?
    – Alex
    May 10 '15 at 16:13







  • 2




    @Alex: To rewrite that application, based on your description, would take a decent sized team (5+) a fairly long time (1 yr+) to handle. That represents a significant investment of money for what sounds like a small business. I'd say the odds of it happening are between slim and none.
    – NotMe
    May 11 '15 at 15:49










  • @NotMe. Exactly. When I worked on similar applications, it was a team of 4 of us. Usually 2 to write logic, classes and controllers, 1 to handle DB and 1 to handle UI, They expect one person to handle it all, and their wordpress system as well. This system is suppose to be there bread and butter for business and how they get everything done because they refused to use a commercial system that is industry supported.
    – Alex
    May 11 '15 at 16:07














up vote
7
down vote














No version control, no design methodologies, no checks and balances
for application management, and no documented long term roadmap for
how the application should be redesigned




..You mean the real world ? I hate to break it to you, but this is the status quo.



We often come into the workplace from academia, where we hear about many abstract and theoretical things.



Now , I'm not saying that it doesn't exist in the real world - this beautiful organization and system thing. It does... but it's far less available than you'd think. Even at the top firms, things can get crazy pretty fast.



Overall, I think you need to make the most of it. Do you have the leverage, to easily jump ship and find your ideal job?



Or are you still relatively early in your career? Would you perhaps benefit from gaining this somewhat "chaotic" experience? Perhaps you can "turn lemons into lemonade" ?



Also, that whole part about the "interview being different from reality"(c. ) , oh that is just marketing :-)



my two cents. good luck in your career !!






share|improve this answer


















  • 2




    I understand its not perfect. I've worked in other companies where It was a team of developers, which was the statement made here as well, but turns out I'm solo. Their internal application is using technologies 10 years old, over several hundred DB tables, an estimated 200,000+ lines of code spread across about 250 files and counting. I'm still trying to read through their code to see how everything connects. They don't really have the gusto to bring it into the present. In the end, how do you market maintaining a language skill hardly any other company is using?
    – Alex
    May 10 '15 at 16:13







  • 2




    @Alex: To rewrite that application, based on your description, would take a decent sized team (5+) a fairly long time (1 yr+) to handle. That represents a significant investment of money for what sounds like a small business. I'd say the odds of it happening are between slim and none.
    – NotMe
    May 11 '15 at 15:49










  • @NotMe. Exactly. When I worked on similar applications, it was a team of 4 of us. Usually 2 to write logic, classes and controllers, 1 to handle DB and 1 to handle UI, They expect one person to handle it all, and their wordpress system as well. This system is suppose to be there bread and butter for business and how they get everything done because they refused to use a commercial system that is industry supported.
    – Alex
    May 11 '15 at 16:07












up vote
7
down vote










up vote
7
down vote










No version control, no design methodologies, no checks and balances
for application management, and no documented long term roadmap for
how the application should be redesigned




..You mean the real world ? I hate to break it to you, but this is the status quo.



We often come into the workplace from academia, where we hear about many abstract and theoretical things.



Now , I'm not saying that it doesn't exist in the real world - this beautiful organization and system thing. It does... but it's far less available than you'd think. Even at the top firms, things can get crazy pretty fast.



Overall, I think you need to make the most of it. Do you have the leverage, to easily jump ship and find your ideal job?



Or are you still relatively early in your career? Would you perhaps benefit from gaining this somewhat "chaotic" experience? Perhaps you can "turn lemons into lemonade" ?



Also, that whole part about the "interview being different from reality"(c. ) , oh that is just marketing :-)



my two cents. good luck in your career !!






share|improve this answer















No version control, no design methodologies, no checks and balances
for application management, and no documented long term roadmap for
how the application should be redesigned




..You mean the real world ? I hate to break it to you, but this is the status quo.



We often come into the workplace from academia, where we hear about many abstract and theoretical things.



Now , I'm not saying that it doesn't exist in the real world - this beautiful organization and system thing. It does... but it's far less available than you'd think. Even at the top firms, things can get crazy pretty fast.



Overall, I think you need to make the most of it. Do you have the leverage, to easily jump ship and find your ideal job?



Or are you still relatively early in your career? Would you perhaps benefit from gaining this somewhat "chaotic" experience? Perhaps you can "turn lemons into lemonade" ?



Also, that whole part about the "interview being different from reality"(c. ) , oh that is just marketing :-)



my two cents. good luck in your career !!







share|improve this answer














share|improve this answer



share|improve this answer








edited May 10 '15 at 16:30

























answered May 10 '15 at 15:59









Adel

3,571104180




3,571104180







  • 2




    I understand its not perfect. I've worked in other companies where It was a team of developers, which was the statement made here as well, but turns out I'm solo. Their internal application is using technologies 10 years old, over several hundred DB tables, an estimated 200,000+ lines of code spread across about 250 files and counting. I'm still trying to read through their code to see how everything connects. They don't really have the gusto to bring it into the present. In the end, how do you market maintaining a language skill hardly any other company is using?
    – Alex
    May 10 '15 at 16:13







  • 2




    @Alex: To rewrite that application, based on your description, would take a decent sized team (5+) a fairly long time (1 yr+) to handle. That represents a significant investment of money for what sounds like a small business. I'd say the odds of it happening are between slim and none.
    – NotMe
    May 11 '15 at 15:49










  • @NotMe. Exactly. When I worked on similar applications, it was a team of 4 of us. Usually 2 to write logic, classes and controllers, 1 to handle DB and 1 to handle UI, They expect one person to handle it all, and their wordpress system as well. This system is suppose to be there bread and butter for business and how they get everything done because they refused to use a commercial system that is industry supported.
    – Alex
    May 11 '15 at 16:07












  • 2




    I understand its not perfect. I've worked in other companies where It was a team of developers, which was the statement made here as well, but turns out I'm solo. Their internal application is using technologies 10 years old, over several hundred DB tables, an estimated 200,000+ lines of code spread across about 250 files and counting. I'm still trying to read through their code to see how everything connects. They don't really have the gusto to bring it into the present. In the end, how do you market maintaining a language skill hardly any other company is using?
    – Alex
    May 10 '15 at 16:13







  • 2




    @Alex: To rewrite that application, based on your description, would take a decent sized team (5+) a fairly long time (1 yr+) to handle. That represents a significant investment of money for what sounds like a small business. I'd say the odds of it happening are between slim and none.
    – NotMe
    May 11 '15 at 15:49










  • @NotMe. Exactly. When I worked on similar applications, it was a team of 4 of us. Usually 2 to write logic, classes and controllers, 1 to handle DB and 1 to handle UI, They expect one person to handle it all, and their wordpress system as well. This system is suppose to be there bread and butter for business and how they get everything done because they refused to use a commercial system that is industry supported.
    – Alex
    May 11 '15 at 16:07







2




2




I understand its not perfect. I've worked in other companies where It was a team of developers, which was the statement made here as well, but turns out I'm solo. Their internal application is using technologies 10 years old, over several hundred DB tables, an estimated 200,000+ lines of code spread across about 250 files and counting. I'm still trying to read through their code to see how everything connects. They don't really have the gusto to bring it into the present. In the end, how do you market maintaining a language skill hardly any other company is using?
– Alex
May 10 '15 at 16:13





I understand its not perfect. I've worked in other companies where It was a team of developers, which was the statement made here as well, but turns out I'm solo. Their internal application is using technologies 10 years old, over several hundred DB tables, an estimated 200,000+ lines of code spread across about 250 files and counting. I'm still trying to read through their code to see how everything connects. They don't really have the gusto to bring it into the present. In the end, how do you market maintaining a language skill hardly any other company is using?
– Alex
May 10 '15 at 16:13





2




2




@Alex: To rewrite that application, based on your description, would take a decent sized team (5+) a fairly long time (1 yr+) to handle. That represents a significant investment of money for what sounds like a small business. I'd say the odds of it happening are between slim and none.
– NotMe
May 11 '15 at 15:49




@Alex: To rewrite that application, based on your description, would take a decent sized team (5+) a fairly long time (1 yr+) to handle. That represents a significant investment of money for what sounds like a small business. I'd say the odds of it happening are between slim and none.
– NotMe
May 11 '15 at 15:49












@NotMe. Exactly. When I worked on similar applications, it was a team of 4 of us. Usually 2 to write logic, classes and controllers, 1 to handle DB and 1 to handle UI, They expect one person to handle it all, and their wordpress system as well. This system is suppose to be there bread and butter for business and how they get everything done because they refused to use a commercial system that is industry supported.
– Alex
May 11 '15 at 16:07




@NotMe. Exactly. When I worked on similar applications, it was a team of 4 of us. Usually 2 to write logic, classes and controllers, 1 to handle DB and 1 to handle UI, They expect one person to handle it all, and their wordpress system as well. This system is suppose to be there bread and butter for business and how they get everything done because they refused to use a commercial system that is industry supported.
– Alex
May 11 '15 at 16:07












up vote
5
down vote













I was in a very similar situation. Eventually I had to leave the company, but that may not have been the best idea.



As Adel points out, you're going to see this in a lot of companies. When I left work, I started picking up some Freelance work to make ends meet and working under some of the contacts I had made. Out of the 7 Companies I've developed for thus far, none of them had any documentation, multiple versions of software scattered around the business and didn't even understand what a long-term roadmap was. The guys with money do not work with code, so they don't care about any of that stuff.



What I tend to do, if it's a fairly small project that has just became overcomplicated with time, is try to convince the client that it would be better to redevelop from scratch. Then put those documents together myself and comment the code. There's a lot of loopholes you're going to have to jump with this though.



First of all, as you've noticed... people do not like change. They like sticking to the comfort of old technologies, new stuff requires effort to learn. If you can show them that their part of it will remain practically the same, that will soften the blow. Keep the same UI elements, keep the same layout, keep changes with how they interact with the software to a minimum. (I also tend to throw out the words "Future Proofing" a lot, management seem to like those words. They tend to imply that they won't need to invest as much later down the line, which is true if you do it right).



Secondly, companies will always have doubts about something untested VS something they know works. There's a risk element, you need to keep this to a minimum and pull every fact that you can in your favour. If I come up against someone really reluctant to change, I tend to make them a little power-point with the strengths of the change. If you want to switch from some ancient language nobody uses any more, make sure the higher ups understand why everyone else has already switched to these new technologies. Use real-world examples to prove that it works.
How much quicker will it be to implement changes?
How many limitations will this remove?
How much more secure will the software be?
How much cheaper will future development be?
They're not going to care one bit about how much easier it is for you, or how much it will help you develop as a programmer... they want to see what benefits it has for them and the bottom line.



Lastly, make sure there isn't a genuine reason for it. One of the companies I developed for were handling logistics on behalf of another client. I wanted to change their software from Visual Basic 6 to .NET 4.5, only to find that their client required access to the code, and their tech guys only worked in VB6... so that was a complete no-go for upgrading. This stuff happens and then you just have to grin and bare it. You might find other technical reasons for this as well, such as having to interact with ancient software elsewhere in the business.



Also one last note. If you're going to write out documentation, make sure it's okayed with your superiors first. Even though it can be invaluable to programmers, there are companies that will see that as a major waste of your time and their money.



Good luck!






share|improve this answer






















  • Your answer makes a lot of sense. I'm trying to take that approach. My challenge is the physically non-existent director I report to is the bottleneck. The CEO wants to change to a different technology that is mainstream, but he gives the director a lot of headspace to act and that director is intimidated by anything outside of his limited scope. I was baffled when I asked him what kind of apps he builds on the side and he said he doesn't. He doesn't know what Ruby. Python, or C# is.
    – Alex
    May 10 '15 at 17:53










  • I find that you get this a lot. A lot of the guys I've reported to have only ever used one language and have absolutely no interest in programming outside of their 9 to 5. You'll likely find your Director wasn't originally a "tech guy" and simply got stuck with it at some point. This is pretty common. My original advice still stands on that situation. Make it seem like his job is going to be easier. It's much easier if you're using simple tools, such as Visual Studio, where you can showcase the Drag & Drop functions to make it look like he'll be able to stay on top of it.
    – Darryl_Holmes
    May 10 '15 at 19:16







  • 1




    I was in this situation as well and I agree with @Darryl_Holmes . When you walk into a company for a job chances are pretty high that your going to be sifting through a ton of code. Pretty much all non-tech founded companies have higher management that don't understand code, they just want results. What happens when there's multiple developers is that things get added and as time goes on and more developers swap out, things get changed even more. Little bits here and there, and because of time constraints or irritability, no one comments things as much as they should. Name of the game.
    – zfrisch
    May 11 '15 at 0:59















up vote
5
down vote













I was in a very similar situation. Eventually I had to leave the company, but that may not have been the best idea.



As Adel points out, you're going to see this in a lot of companies. When I left work, I started picking up some Freelance work to make ends meet and working under some of the contacts I had made. Out of the 7 Companies I've developed for thus far, none of them had any documentation, multiple versions of software scattered around the business and didn't even understand what a long-term roadmap was. The guys with money do not work with code, so they don't care about any of that stuff.



What I tend to do, if it's a fairly small project that has just became overcomplicated with time, is try to convince the client that it would be better to redevelop from scratch. Then put those documents together myself and comment the code. There's a lot of loopholes you're going to have to jump with this though.



First of all, as you've noticed... people do not like change. They like sticking to the comfort of old technologies, new stuff requires effort to learn. If you can show them that their part of it will remain practically the same, that will soften the blow. Keep the same UI elements, keep the same layout, keep changes with how they interact with the software to a minimum. (I also tend to throw out the words "Future Proofing" a lot, management seem to like those words. They tend to imply that they won't need to invest as much later down the line, which is true if you do it right).



Secondly, companies will always have doubts about something untested VS something they know works. There's a risk element, you need to keep this to a minimum and pull every fact that you can in your favour. If I come up against someone really reluctant to change, I tend to make them a little power-point with the strengths of the change. If you want to switch from some ancient language nobody uses any more, make sure the higher ups understand why everyone else has already switched to these new technologies. Use real-world examples to prove that it works.
How much quicker will it be to implement changes?
How many limitations will this remove?
How much more secure will the software be?
How much cheaper will future development be?
They're not going to care one bit about how much easier it is for you, or how much it will help you develop as a programmer... they want to see what benefits it has for them and the bottom line.



Lastly, make sure there isn't a genuine reason for it. One of the companies I developed for were handling logistics on behalf of another client. I wanted to change their software from Visual Basic 6 to .NET 4.5, only to find that their client required access to the code, and their tech guys only worked in VB6... so that was a complete no-go for upgrading. This stuff happens and then you just have to grin and bare it. You might find other technical reasons for this as well, such as having to interact with ancient software elsewhere in the business.



Also one last note. If you're going to write out documentation, make sure it's okayed with your superiors first. Even though it can be invaluable to programmers, there are companies that will see that as a major waste of your time and their money.



Good luck!






share|improve this answer






















  • Your answer makes a lot of sense. I'm trying to take that approach. My challenge is the physically non-existent director I report to is the bottleneck. The CEO wants to change to a different technology that is mainstream, but he gives the director a lot of headspace to act and that director is intimidated by anything outside of his limited scope. I was baffled when I asked him what kind of apps he builds on the side and he said he doesn't. He doesn't know what Ruby. Python, or C# is.
    – Alex
    May 10 '15 at 17:53










  • I find that you get this a lot. A lot of the guys I've reported to have only ever used one language and have absolutely no interest in programming outside of their 9 to 5. You'll likely find your Director wasn't originally a "tech guy" and simply got stuck with it at some point. This is pretty common. My original advice still stands on that situation. Make it seem like his job is going to be easier. It's much easier if you're using simple tools, such as Visual Studio, where you can showcase the Drag & Drop functions to make it look like he'll be able to stay on top of it.
    – Darryl_Holmes
    May 10 '15 at 19:16







  • 1




    I was in this situation as well and I agree with @Darryl_Holmes . When you walk into a company for a job chances are pretty high that your going to be sifting through a ton of code. Pretty much all non-tech founded companies have higher management that don't understand code, they just want results. What happens when there's multiple developers is that things get added and as time goes on and more developers swap out, things get changed even more. Little bits here and there, and because of time constraints or irritability, no one comments things as much as they should. Name of the game.
    – zfrisch
    May 11 '15 at 0:59













up vote
5
down vote










up vote
5
down vote









I was in a very similar situation. Eventually I had to leave the company, but that may not have been the best idea.



As Adel points out, you're going to see this in a lot of companies. When I left work, I started picking up some Freelance work to make ends meet and working under some of the contacts I had made. Out of the 7 Companies I've developed for thus far, none of them had any documentation, multiple versions of software scattered around the business and didn't even understand what a long-term roadmap was. The guys with money do not work with code, so they don't care about any of that stuff.



What I tend to do, if it's a fairly small project that has just became overcomplicated with time, is try to convince the client that it would be better to redevelop from scratch. Then put those documents together myself and comment the code. There's a lot of loopholes you're going to have to jump with this though.



First of all, as you've noticed... people do not like change. They like sticking to the comfort of old technologies, new stuff requires effort to learn. If you can show them that their part of it will remain practically the same, that will soften the blow. Keep the same UI elements, keep the same layout, keep changes with how they interact with the software to a minimum. (I also tend to throw out the words "Future Proofing" a lot, management seem to like those words. They tend to imply that they won't need to invest as much later down the line, which is true if you do it right).



Secondly, companies will always have doubts about something untested VS something they know works. There's a risk element, you need to keep this to a minimum and pull every fact that you can in your favour. If I come up against someone really reluctant to change, I tend to make them a little power-point with the strengths of the change. If you want to switch from some ancient language nobody uses any more, make sure the higher ups understand why everyone else has already switched to these new technologies. Use real-world examples to prove that it works.
How much quicker will it be to implement changes?
How many limitations will this remove?
How much more secure will the software be?
How much cheaper will future development be?
They're not going to care one bit about how much easier it is for you, or how much it will help you develop as a programmer... they want to see what benefits it has for them and the bottom line.



Lastly, make sure there isn't a genuine reason for it. One of the companies I developed for were handling logistics on behalf of another client. I wanted to change their software from Visual Basic 6 to .NET 4.5, only to find that their client required access to the code, and their tech guys only worked in VB6... so that was a complete no-go for upgrading. This stuff happens and then you just have to grin and bare it. You might find other technical reasons for this as well, such as having to interact with ancient software elsewhere in the business.



Also one last note. If you're going to write out documentation, make sure it's okayed with your superiors first. Even though it can be invaluable to programmers, there are companies that will see that as a major waste of your time and their money.



Good luck!






share|improve this answer














I was in a very similar situation. Eventually I had to leave the company, but that may not have been the best idea.



As Adel points out, you're going to see this in a lot of companies. When I left work, I started picking up some Freelance work to make ends meet and working under some of the contacts I had made. Out of the 7 Companies I've developed for thus far, none of them had any documentation, multiple versions of software scattered around the business and didn't even understand what a long-term roadmap was. The guys with money do not work with code, so they don't care about any of that stuff.



What I tend to do, if it's a fairly small project that has just became overcomplicated with time, is try to convince the client that it would be better to redevelop from scratch. Then put those documents together myself and comment the code. There's a lot of loopholes you're going to have to jump with this though.



First of all, as you've noticed... people do not like change. They like sticking to the comfort of old technologies, new stuff requires effort to learn. If you can show them that their part of it will remain practically the same, that will soften the blow. Keep the same UI elements, keep the same layout, keep changes with how they interact with the software to a minimum. (I also tend to throw out the words "Future Proofing" a lot, management seem to like those words. They tend to imply that they won't need to invest as much later down the line, which is true if you do it right).



Secondly, companies will always have doubts about something untested VS something they know works. There's a risk element, you need to keep this to a minimum and pull every fact that you can in your favour. If I come up against someone really reluctant to change, I tend to make them a little power-point with the strengths of the change. If you want to switch from some ancient language nobody uses any more, make sure the higher ups understand why everyone else has already switched to these new technologies. Use real-world examples to prove that it works.
How much quicker will it be to implement changes?
How many limitations will this remove?
How much more secure will the software be?
How much cheaper will future development be?
They're not going to care one bit about how much easier it is for you, or how much it will help you develop as a programmer... they want to see what benefits it has for them and the bottom line.



Lastly, make sure there isn't a genuine reason for it. One of the companies I developed for were handling logistics on behalf of another client. I wanted to change their software from Visual Basic 6 to .NET 4.5, only to find that their client required access to the code, and their tech guys only worked in VB6... so that was a complete no-go for upgrading. This stuff happens and then you just have to grin and bare it. You might find other technical reasons for this as well, such as having to interact with ancient software elsewhere in the business.



Also one last note. If you're going to write out documentation, make sure it's okayed with your superiors first. Even though it can be invaluable to programmers, there are companies that will see that as a major waste of your time and their money.



Good luck!







share|improve this answer














share|improve this answer



share|improve this answer








edited May 10 '15 at 19:33









wolfPack88

247313




247313










answered May 10 '15 at 17:42









Darryl_Holmes

463613




463613











  • Your answer makes a lot of sense. I'm trying to take that approach. My challenge is the physically non-existent director I report to is the bottleneck. The CEO wants to change to a different technology that is mainstream, but he gives the director a lot of headspace to act and that director is intimidated by anything outside of his limited scope. I was baffled when I asked him what kind of apps he builds on the side and he said he doesn't. He doesn't know what Ruby. Python, or C# is.
    – Alex
    May 10 '15 at 17:53










  • I find that you get this a lot. A lot of the guys I've reported to have only ever used one language and have absolutely no interest in programming outside of their 9 to 5. You'll likely find your Director wasn't originally a "tech guy" and simply got stuck with it at some point. This is pretty common. My original advice still stands on that situation. Make it seem like his job is going to be easier. It's much easier if you're using simple tools, such as Visual Studio, where you can showcase the Drag & Drop functions to make it look like he'll be able to stay on top of it.
    – Darryl_Holmes
    May 10 '15 at 19:16







  • 1




    I was in this situation as well and I agree with @Darryl_Holmes . When you walk into a company for a job chances are pretty high that your going to be sifting through a ton of code. Pretty much all non-tech founded companies have higher management that don't understand code, they just want results. What happens when there's multiple developers is that things get added and as time goes on and more developers swap out, things get changed even more. Little bits here and there, and because of time constraints or irritability, no one comments things as much as they should. Name of the game.
    – zfrisch
    May 11 '15 at 0:59

















  • Your answer makes a lot of sense. I'm trying to take that approach. My challenge is the physically non-existent director I report to is the bottleneck. The CEO wants to change to a different technology that is mainstream, but he gives the director a lot of headspace to act and that director is intimidated by anything outside of his limited scope. I was baffled when I asked him what kind of apps he builds on the side and he said he doesn't. He doesn't know what Ruby. Python, or C# is.
    – Alex
    May 10 '15 at 17:53










  • I find that you get this a lot. A lot of the guys I've reported to have only ever used one language and have absolutely no interest in programming outside of their 9 to 5. You'll likely find your Director wasn't originally a "tech guy" and simply got stuck with it at some point. This is pretty common. My original advice still stands on that situation. Make it seem like his job is going to be easier. It's much easier if you're using simple tools, such as Visual Studio, where you can showcase the Drag & Drop functions to make it look like he'll be able to stay on top of it.
    – Darryl_Holmes
    May 10 '15 at 19:16







  • 1




    I was in this situation as well and I agree with @Darryl_Holmes . When you walk into a company for a job chances are pretty high that your going to be sifting through a ton of code. Pretty much all non-tech founded companies have higher management that don't understand code, they just want results. What happens when there's multiple developers is that things get added and as time goes on and more developers swap out, things get changed even more. Little bits here and there, and because of time constraints or irritability, no one comments things as much as they should. Name of the game.
    – zfrisch
    May 11 '15 at 0:59
















Your answer makes a lot of sense. I'm trying to take that approach. My challenge is the physically non-existent director I report to is the bottleneck. The CEO wants to change to a different technology that is mainstream, but he gives the director a lot of headspace to act and that director is intimidated by anything outside of his limited scope. I was baffled when I asked him what kind of apps he builds on the side and he said he doesn't. He doesn't know what Ruby. Python, or C# is.
– Alex
May 10 '15 at 17:53




Your answer makes a lot of sense. I'm trying to take that approach. My challenge is the physically non-existent director I report to is the bottleneck. The CEO wants to change to a different technology that is mainstream, but he gives the director a lot of headspace to act and that director is intimidated by anything outside of his limited scope. I was baffled when I asked him what kind of apps he builds on the side and he said he doesn't. He doesn't know what Ruby. Python, or C# is.
– Alex
May 10 '15 at 17:53












I find that you get this a lot. A lot of the guys I've reported to have only ever used one language and have absolutely no interest in programming outside of their 9 to 5. You'll likely find your Director wasn't originally a "tech guy" and simply got stuck with it at some point. This is pretty common. My original advice still stands on that situation. Make it seem like his job is going to be easier. It's much easier if you're using simple tools, such as Visual Studio, where you can showcase the Drag & Drop functions to make it look like he'll be able to stay on top of it.
– Darryl_Holmes
May 10 '15 at 19:16





I find that you get this a lot. A lot of the guys I've reported to have only ever used one language and have absolutely no interest in programming outside of their 9 to 5. You'll likely find your Director wasn't originally a "tech guy" and simply got stuck with it at some point. This is pretty common. My original advice still stands on that situation. Make it seem like his job is going to be easier. It's much easier if you're using simple tools, such as Visual Studio, where you can showcase the Drag & Drop functions to make it look like he'll be able to stay on top of it.
– Darryl_Holmes
May 10 '15 at 19:16





1




1




I was in this situation as well and I agree with @Darryl_Holmes . When you walk into a company for a job chances are pretty high that your going to be sifting through a ton of code. Pretty much all non-tech founded companies have higher management that don't understand code, they just want results. What happens when there's multiple developers is that things get added and as time goes on and more developers swap out, things get changed even more. Little bits here and there, and because of time constraints or irritability, no one comments things as much as they should. Name of the game.
– zfrisch
May 11 '15 at 0:59





I was in this situation as well and I agree with @Darryl_Holmes . When you walk into a company for a job chances are pretty high that your going to be sifting through a ton of code. Pretty much all non-tech founded companies have higher management that don't understand code, they just want results. What happens when there's multiple developers is that things get added and as time goes on and more developers swap out, things get changed even more. Little bits here and there, and because of time constraints or irritability, no one comments things as much as they should. Name of the game.
– zfrisch
May 11 '15 at 0:59



Comments

Popular posts from this blog

What does second last employer means? [closed]

List of Gilmore Girls characters

Confectionery