5

I'm a mobile developer. I work in a service company developing internal tools for different areas of the company. There is an so-called modernization project where I am, which is supposed to define and improve processes and bring more modern solutions and practices to the various projects.

Knowing that, since my first day at the company I've been committed to setting development standards (clean architecture, git flow, ci/cd, design system, automate testing, etc.), preparing systems documentation and setting up plans and strategies for refactoring.

I've already made some presentations showing changes that need to be made. Always exposing the problems showing and how the company can benefit from attacking them. Presenting very detailed backlogs as a plan to action.

However, very little I was able to put into practice. The company shows a lot of resistance to these changes and shows little to no interest in implementing them.

I'm exhausted from bringing my ideas just to get them rejected right away and instead being assigned some mundane, low-quality and low-effort task, to be delivered as fast as possible, just to break something else and having to do the same the next sprint, because the code is a big mess.

I'm on the verge of giving up the job. I'm feeling extremely demotivated and sad. But before taking any action I want to know if there is something else I can consider doing, or what steps could I take to make my proposals being accepted?

7
  • 2
    Another alternative, is to fork the code and make some changes that you feel are meaningfully better and then show them. Maybe if they see the promise of better things, they will get on board. This likely means a good deal more of your personal time dedicated to work to try to prove these changes are for the best. If you go this route, really think about thinks that can show significant improvements (metrics are great for quantifiable things or really show how the experience is improved if you can't measure it) and not just "the code is better" Aug 11, 2023 at 2:14
  • 1
    Thanks for your comments. I reworded my sentences, hope it fit the standards now
    – sittaman
    Aug 11, 2023 at 2:46
  • 1
    @sittaman I edited a bit your post and title. I see it's OK now. I do suggest you browse our various questions, as what you post here rings a bell in my mind...
    – DarkCygnus
    Aug 11, 2023 at 3:50
  • 5
    Further clarification questions: how long have you been in the company? are these proposals part of the "so-called modernization project" you are in, or are they things you are proposing and are not bound to any project?
    – DarkCygnus
    Aug 11, 2023 at 3:51
  • 4
    What is your seniority level? I think what should be expected from you depends on that. A senior or staff engineer should be able, it can be expected to create a form of consensus.
    – Helena
    Aug 11, 2023 at 7:28

5 Answers 5

14

From your question, it seems that you are talking the talk without showing that you can walk the walk.

I've already made some presentations showing changes that need to be made. [...] Presenting very detailed backlogs as a plan to action.

You're a developer, not an engineering director. Until you've shown that you what you're talking about actually has value for your employer's specific situation, stop trying to change everything at once. Pick one very specific thing and show - with actual code, not a Powerpoint - how it makes things better.

1
  • 6
    Exactly. The other developers and the company will be sold on it when you show how it improves their lives. Here's an example: many, many years ago I was talking up the value of lint, a checker for C programs. No one was sold on it but one dev was stuck on a bug and decided to take a break and have me show him how lint worked. We ran it on his program. It immediately found the uninitialized pointer that was his bug. He used lint religiously from then on.
    – DaveG
    Aug 11, 2023 at 21:26
9

Not to be rude, but there are plenty of developers who think they know better than everyone else how things should be done. It's very easy to come into a workplace with a legacy system and identify lots of faults with how they are doing things, not appreciating the amount of work that would be necessary to actually fix them and the fact that there may be good reasons that things are the way they are. It also rubs existing employees - the people you have to work with to make these changes - the wrong way when a new guy comes in and thinks that he's smarter than them. It doesn't sound like you've been hired to make wholesale changes to the system, so why are you doing a job that you're not being paid for? I think you'd be better concentrating on your actual job. Show that you can do that well, and maybe you will win the trust of those who are actually in charge of making improvements and they may ask for you to help them.

2
  • 4
    Please capitalize traditionally when posting to SE. It really does make your writing easier to read, and hence makes people more willing to read your thoughts. (Sorry about the typos in first draft; typing on phone )
    – keshlam
    Aug 11, 2023 at 16:25
  • 1
    I think the two issues with most workplaces is either that they lack experienced management in a highly technical area (so very often the apprentice does know more than the non-technical managers), or they suffer flight of those who have a deep understanding of their (often shoddy) bespoke software systems and then want to bring in someone (often very young, and naive enough not to reject the employment outright) who knows nothing about it. If it takes a lot of work to fix, then more fool the employer for creating such badly broken software in the first place.
    – Steve
    Aug 16, 2023 at 9:33
8

Remember that best practice is not the only valid practice, and that changing existing practice has costs that the company may not want to invest in at this time. Unless you can demonstrate that benefits will outweigh costs, and that costs are sufficiently low that they are acceptable, the company may be entirely correct in accepting this as technical debt to be addressed at a later date.

Research/science/academia can spend the time looking for perfect solutions. Part of being a developer -- or any kind of engineer -- is being able to hold your nose and work with what you've got until your customer agrees to something better. Or, if you really can't accept that, finding a customer you can work with... but being that picky means fewer customers available to work with.

When someone needs their ratty old bicycle fixed immediately, they probably aren't going to want to wait, or pay, for you to custom-build them a state-of-the-art Pedalmaster.

1
3

Unless you are in a leadership role (manager, team lead, architecture, or otherwise) that empowers you to make decisions on such matters, the feedback you've received indicates that you need to take a seat. The presentations are cool, but no one's biting. The modernization project is obviously just as you've described - "so-called".

This is really not an uncommon situation. Business initiatives tend to drive the work that gets done, and in a lot of situations technical initiatives tend to take a low priority unless it can be clearly shown that failing to move to different standards or update obsolete tech is going to tangibly impact the bottom line. In short, what you feel matters a lot less - you need to show impact on dollars and time to people who can make these decisions, because your colleagues aren't budging.

1

Frankly, if you're facing something you didn't make and can't work with, it's easier to simply plot an exit.

Software suffers deep problems in that companies often commission work in a very cavalier way, they often don't retain competent technical management to oversee the process, and they often fail to retain the staff who make and understand the software.

The popular view amongst non-technical management is that, by being in possession of the code or the computer configuration, they are in possession of everything that counts.

What they don't realise is that they need staff who understand how the business works, including how the code relates to those workings, in order to modify the code further. That's why you have development staff - to make new code that you don't already have.

Often multiple man-years have been spent getting the existing (or last) programmer to the point where he made his most recent modification to the code.

Getting another person to that same point with the same codebase can easily take that length of time if things make reasonable sense, and there are knowledge resources available in terms of development staff who are articulate and liberally available for discussions, documentation (written to a commercially saleable standard, like a publishable textbook, not written by amateurs), and project paper trails that explain awkward things.

In the more likely event that none of these knowledge resources are available, and the company hasn't started the training process years ahead of time, then their legacy software is usually dead on arrival, or moribund at least.

Usually, there's no reasoning with companies that get into that situation. There's usually nothing you can do to correct their earlier mistakes.

They are simply trying desperately to get a bum back on a seat, and the only language they understand is (to mix a metaphor) the bum on a seat standing up and voting with his feet.

Just find a new employer who has fresh development to perform from a clean slate, or an employer who might have some legacy but with much more structure and stability to cope with reproducing knowledge (i.e. at the very least, you'd expect to be working under a skilled development manager who has already set suitable development processes years earlier, not addressing these yourself with non-technical management).

Don't waste your time with companies that have legacy code, but no legacy software management structure to receive you, and no legacy understanding.

You must log in to answer this question.

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