How to cope at a company where technical improvement is actively discouraged. [closed]

Question

A little background: I have been out of undergraduate college for a little under a year now. I work at a decent sized corporation as a software engineer. I am well paid and have good benefits.

My concern is I have not been working this job long at all and I feel as though it is completely a technical dead end. I am not someone who has ever struggled with learning new things in the field of computer science or software engineering. I can pick up most programming languages in a week (not just imperative or OO, but functional and logic language as well). I have never touched an API I could not learn in a weekend. It has been over a decade since I can remember looking at source code and not being able to figure out what it is doing.

My problem arises that at work, I feel like I have to consciously not use my technical knowledge to ever have any hope of fitting in. My workplace does have standards. I don't really have much of a problem with the coding standard, nor do I have a problem with a documentation standard for software. I think some of the things in those standards are unfathomably stupid, but they really aren't deal breakers. Some of the business process standards seem silly to me, but I go along with them because I am paid to. I'm not naive enough to believe that I will somehow change the business processes of a large corporation.

The thing is, it seems like any sort of technical improvement is actively discouraged. The examples are so scattered and numerous, it hurts to even think about, but here are a few examples:

If someone else can't immediately understand what I am doing, it's automatically out. Even if I do a phenomenal job of explaining it (not my words), it's probably going to be forced out.

Writing portable (i.e. code that can move from one architecture to another) is actively discouraged. I could speculate as to why, but I really have no idea why.

Using a standard set of functions to validate user input is completely inadmissible. I have actually been made to duplicate the same logic hundreds of times across a code base rather than use a single function to encapsulate it.

A coworker was once told to decouple his software from the mathematical concept of pi. It involved mathematics in spherical coordinates. He was not successful in fulfilling this request.

Trying to identify problems with software architecture decisions ends up with me getting treated like a heretic. Keep in mind this isn't the new guy refactoring the 6 million line of code base that started while he was in diapers. It's trying to suggest improvements to make everyone's life easier while developing new software. This resulted in the 'not your job' speech at least once in front of a room of 20 other engineers.

I feel like this career is absolute technical dead end. As in, if I never learned something new for the rest of my life, no one would ever notice. At this point, I have completely given up on trying to create anything of value. No matter how stupid of a request comes across my desk, unless it is not simply not possible I just go along with it. The only thing keeping me at my job is the paycheck and the location.

I could go on, but I would just like to get to my real question: Is all software engineering like this? I'm pretty young, so I could easily change careers. I haven't quite yet strapped on the life preserver to jump ship, but I would rather make a decision now than just become completely disillusioned with what I do.

What are my options here?

Answer 1

Is all software engineering like this?

No, it certainly isn't. Though it is more likely to be like this in larger organizations where software exists to support the business rather than being the business. Having said that, there are many large organisations where excellence in software is actively encouraged. Whether an organization does one or the other tends to mirror the focus of upper management and those of the IT management team. Such people may think of the situation as "if it is not broken don't fix it" and cannot see that it is broken.

Requirements like the one you describe about decoupling PI from a library (class/set of functions/whatever) used for spherical calculations sounds like something that came from someone who doesn't have an idea about programming or mathematics - someone like that is unlikely to care about code quality, let alone improving it, or the development experience.

Your options are:

1. Prove to the higher ups, those that don't see the breakage, that things are broken. However, if they are not technical in the least, they will probably not be convinced.

2. Leave. Find a job where they do care about code quality. When interviewing, make sure to ask questions about their coding processes - ask enough so you feel confident that you understand how they feel about this issue.

Answer 2

Writing portable (i.e. code that can move from one architecture to another) is actively discouraged.

This is kind of thing is common in corporate IT development teams. For example, you may encounter a team that's been using VB since the late 90's and, even though they're on .NET now, they still code in a VB6 style. In other groups, the corporate standard is to only use Microsoft products so being portable to *nix isn't a consideration. Others may be equally divided between IOS and Android developers who don't share code and have no desire to for 'religious' reasons.

Using a standard set of functions to validate user input is completely inadmissible.

This is common too, simply because refactoring a large number of existing applications/code to deal with this has been deemed too costly. It's also likely someone tried to do this in the past and it ended up being a massive failure. If a company spend thousands on a failed refactor they're unlikely to take one up again, even a small scale one, in the short term.

Trying to identify problems with software architecture decisions ends up with me getting treated like a heretic.

This is common too. Some people who've been at a company a while will be defensive about their code, especially criticism from a junior programmer. Some are just resistant to change. For example, I've encountered .NET programmers who're quite resistant to learning LINQ, MVC and other newer things and still code like they're on Framework 1.1 or 2.0.

But, each software development organization is different. There are good ones and bad ones, high pressure ones and laid back ones, ossified ones and dynamic ones. The one you're in right now seems rather bleak from what you've described. If it's making you that unhappy, it may be time to consider moving on even though the pay and location is good.

When you do interview, ask questions to make sure that you're walking into a situation that's a good fit for your personality and skills. Ask them how they handle portable code and standard functionality. Ask about other areas you have concerns about. Do this without mentioning your current employer's ways. Use non-threatening questions to get the answer you need without offending.

Answer 3

You have confused the definition of job and career.

You have a job with a particular company. If it isn't a good fit then start making plans to leave. That doesn't mean you have to switch to a completely different field.

There are thousands of companies that have software engineers. You picked one that doesn't meet your needs.

Don't quit today. Continue to work with them and take the time to investigate other companies. They can be competitors, sub-contractors, or companies you meet though trade shows. Try to figure out if their work situation is more like what you want. If it looks like a good match, apply for positions there.

When you need a job, you have to spend the interview process convincing them that you are the perfect one for the job. When you have a job, but are looking for a better one, you turn that process on its head.

Answer 4

Is all software engineering like this?

Of course not. A better question might be 'Are all software development groups like this?', and the answer would still be no.

What are my options here?

Sounds like your best option would probably be to find a shop of like-minded engineers and work with them. If you, as a very new developer, are noticing his company's tech issues already, I'd imagine the issues run deep and are systemic and cultural.

As a young engineer, don't be too discouraged by this. It's your first job, and although there are other groups like this, there are plenty that are more friendly to engineers like you.

You mentioned that you are able to pick up new languages and APIs readily, so finding new work shouldn't take too long. Lots of companies seem to be doing more hiring in the junior level range as of late, so your freshness to the industry is a potential advantage.

If your career is the main concern, even taking a small paycut to work in an environment that rewards learning and your type of thinking would be wise in the long run. Learning is the most important element of any job for you at this point in your career, and the money will come if you learn your craft well.