Wells Fargo

• The co-workers can be nice.
• Pay is good.

• Leaving misleading positive reviews to fool prospective employees.
• Waterfall disguised as Agile. They're not fooling anybody.
• Awful code quality process. There's a checklist of requirements that changes constantly for reasons nobody can specify. Things don't get deployed until the entire application is completely finished, which in software engineering means never. Nothing is ever finished.

This results in deployments of massive chunks of code, which we all know is more risky than deploying completed bits and pieces.

• Forcing employees to come into the office when the teams they work on are spread across the globe. So employees go into the office for "face time" on Skype and Teams.

A stated reason for making everyone go back into the office was so we can chit chat and build professional relationships with people not on our team, but of course nobody's given the time to do that. You're booked constantly with meetings so every bit of non-meeting time you get, you dedicate to doing your work. Also, not everybody is interested in chit-chatting with people they don't work with.

In short, they only want you back into the office because, unlike smart managers, they care about the time your butt is in the seat, not the work you get done.

• Extremely unstable development environments.
• Excessive amount of documentation, duplicate documentation, and out-of-date documentation.
• 200-hour SLAs. Really? SLA? There's no reason to have this anymore. And did I mention 200 hours?! Just get the ticket and work on it!

Most of the "engineers" that pick up these tickets are offshore, and on multiple occasions, they waited until the 200 hours were almost up to start work on the ticket. But they don't know what to do, so they "work" on it and then immediately mark it as done, thereby resetting the 200 hours. Of course, they aren't real developers, so they don't know what to do, but now they're given an additional 200 hours to complete their work. They do all of this without once reaching out to the person who made the request. Very unprofessional.

• Dev teams are told we MUST do Agile (even though it's not Agile) so we're all working on 2-week sprints, yet every little thing we want to do outside of our local machine requires a 200-hour SLA ticket to be submitted. I'm not that good at math, but 200 hours is way longer than 2 weeks.
• Everything requires a stupid ticket, which has a 200-hour SLA attached to it. And the "developers" that pick up these tickets have no idea what they're doing. You need to call them and walk them through exactly what to do, or else they won't know. But you're not allowed to do it yourself. Not even in the dev environment.

This is how I had to instruct one of the "devs": "You need to go to this URL. Ok, now click on login. You need to enter your credentials. No, I can't see what your password is, so you can go ahead and type it in the password input field."

I wish this were a joke, but it is not. And what did this "developer" need to do that I had to give such detailed basic instructions? He needed to update environment variables, which should've taken no longer than 5 minutes, but it took the entire 200-hour SLA to complete this task... It's sad.

You may think that I am just a disgruntled employee getting back by leaving a negative review, but that's not the case. I am very well liked at Wells Fargo and have received nothing but praise for the work that I do, but enough is enough.

I feel sorry for all the employees that don't have the ability to just up and leave an awful employer.

You need to implement on-demand deploys now. It's way less risky than what you're currently doing, but the people in charge of this process are more interested in maintaining the status quo, which means you'll continue to ship bad stuff to your customers. You must really like bad PR.

Your SDElements and DSOP don't provide you with any extra security. All of your dev teams are just filling out those projects in a way that gets their applications deployed because they know your "champions" don't actually review the code. Your "champions" don't actually test the application. Your "champions" don't do a single thing to ensure the code is up to par. All your champions do is make sure we attest that the code is good. So, it's all trust-based. If it's all trust-based, then why bother with it at all?

What you need is a robust review process, and you need to trust the people doing the reviews because that's all you have now. As I have pointed out, your "champions" do nothing but take the developers' word.

Your SDElements and DSOP processes are absolutely not providing you with any extra levels of protection. It's not preventing bad code from getting released to production.

You also need to do away with your ticketing system and give developers free reign of the lower environments. That will speed things up and isn't any less safe.

Lastly, you need to start making these teams that pick up tickets do actual work. They're not just useless at the moment; they are a hindrance.