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

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.

Answer 1

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 !!

Answer 2

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!