Qfyilyi

I'm a junior developer that is given the ability to help shape my team's processes if I can justify the change, and if it helps the team get work done. This is new for me as my past companies more or less had rigidly defined processes that came from management.

My team is fairly small and somewhat new (<3 years old). They lack:

• a well defined software development/work management framework (like
  scrum)


• strong product ownership


• well defined roles ( e.g. business staff will do manual testing)


• regular standup meetings


• a consolidated issue tracking process (we have a tool, the process is still being developed)


• a unit, system, regression, or manual testing suite or list


• documentation on business logic and processes


• a knowledge base to document internal and customer facing tips

And the list goes on. Management is open to the implementation of improvements so long as the value is justified and it helps the most important work (namely the development) get done. The underlying assumption however is that you have to take ownership in the implementation, as no one is going to do it for you. And it goes without saying some of the above projects are non-trivial, without a doubt time consuming, and are clearly not development work.

Is it worth a (junior) developer's effort to try and push for the above as time goes on? Or is it best to "stay in your lane" and focus on the development, and leave the bulk of the process definition, and optimization to management?

Good answers so far, but they don't cover all the bases.

In my experience many people fresh out of college have fantastic theoretical knowledge, far better than me or many other seniors with decades building software for a living.

BUT, and that's a big BUT, that knowledge isn't grounded in any practical scenario. In the real world, a lot of that theory falls flat, or at the very least has to be taken with a massive grain of salt as it's found in practice to not work that well in a real world scenario.

Case in point, an application I worked on a long time ago was designed by a brilliant OO theoretician, architected to follow OO principles and theory to the T with lots of patterns applied everywhere.
It was a fantastic piece of software design.
Sadly, in production and maintenance, it was a nightmare as a result. The code base was so large and complex it was in places impossible to change, not because it was especially brittle but because it was so complex nobody dared touch it in fear of what would happen (the original architect/designer had been a contractor who'd long since left of course).
It also performed very poorly, precisely because of the multi-layered structure of patterns, and class libraries all that design required.
A single call to the database as a result of clicking a button on a screen for example would require several hundred object instantiations and method calls, all in the name of ensuring loose coupling and things like that.

This architect had been a university professor with several books about the topic to his name. He'd never worked a day as a programmer on a commercial project.

People with practical experience building software would have realised what a monstrosity that design would inevitably lead to and taken a more pragmatic approach, leading to a system that's easier to maintain and performed better as well.

And the same thing can apply to many other things you encounter as a fresh graduate, or indeed a new employee in any company. Don't assume that because your theoretical base tells you something is wrong or sub-optimal that there's not a very good reason for it to be done that way.

Even now, with over 20 years experience in the field, I'm wary of criticising the way things are done in companies I go to work with. I'll mention in passing that I noticed things are different than in my experience being the most optimal, but not in a beligerent way. Often this leads to interesting conversations as to why those things are as they are, and maybe changes will happen, maybe not, depending on the value of changing things which is often smaller than the cost.

So don't be afraid to suggest things may be done better, but always make sure that you don't come across as the know-it-all snot-nosed kid but rather as a coworker who's trying and willing to not just learn but also help improve processes for the betterment of the company, not just theoretical correctness.

Is it worth a (junior) developer's effort to try and push for the above as time goes on?

Yes, it is always worth your effort to try and make things better. You know best what problems you face after all.

But as you mention, there are lots of problems to solve and many of those problems are not terribly valuable. And at a lot of places, there will be insurmountable barriers to your success or other people who are far better positioned to champion them. So you should always try to make things better, even if that means picking which things you spend your time trying to make better.

Because in the end, if you're not part of the solution you are part of the problem.

Yes. But not the things you suggest.

Out of your list Unit/Integration tests are the only item you can make progress on.

You can start adding these by yourself with minimal time investment and show instant value. Its a technical problem with widely accepted benefits and wont affect others work practices. While also gaining you mdore knowledge of the code base even if the results arent accepted. An easy sell.

The others are generally business processes that involve the entire team or even other teams. You could suggest improvements, but they will be hard for a junior employee to change and the process of changing them is generally non techincal and probably unrelated to your normal work.

I would also suggest things like, setting up CI pipelines, automated deployments, versioning, packaging libraries as good stuff to attack

It depends on:

• how much you expect to get from better practices


• how much effort you'll have to spend getting there


• what are the chance of success and risks - from simple adoption failure to new practices are actually terrible, code quality degrades, key people leave, everyone hates you and you got to find another job in a different city where nobody knows your name

Basically: it's well within your responsibilities to spend some reasonable time advocating for what you think is best - but the decision should be a team or management responsibility. Keep in mind that alienating people is rarely worth it, even if you end up with better practices.

Yes but with a lot of care!

Let me clarify that.

You should strive to improve the habitability of the software. If you look at the code/team/business/project/management and your first response is to take a shower, then it is not habitable. If your first response is to shout yeah!... and then complain when you are turfed out of the office, then you need to make your home more habitable. Its a feeling, and you will know it.

That being said, you are working in a complicated symathesis. Anything you do do is likely to go wrong, and probably will make things worse at least in the short term, because a simple change has ripples. So first off become humble, I don't mean become a push over or accept that things must be bad, I mean come to terms with the fact that your good intentions are going to turn on you viciously.

The Problem

With the best of intentions you might feel that a broad sweeping change needs to happen, and I don't disagree that these situations do exist, but take a moment to think about it. The current system is working, you and your team are producing code, perhaps its slow, perhaps its painful, but it is working and all of you have experience on how to do this. You know roughly what to expect, in short you are practiced professionals in this system.

After the sweeping change though no one, except perhaps the implementer, knows what to expect. In short everyone has been reset to a neophyte level in this part of the system. That's not good. Neophytes have to learn the new rules which takes time. In that time neophytes are making mistakes because they aren't practiced. Those mistakes become part of the system, which you now have to live with and its no where near as sparkly now.

A Way Forward

There are times when slash, burn, and rebuild is by far the best you can do. Its particularly attractive if no one is practiced in the old system, because the only thing being lost is the codified knowledge. If this knowledge is thoroughly incomprehensible then its already lost, and starting over is the only choice. Conversely if the method of codification, or how it used is problematic but functioning, that knowledge is still accessible, and perhaps its worth keeping, perhaps its not - Just don't take the decision lightly.

The other choice is to work with the system so that everyone has a frame of reference, but to change small parts of the system so that everyone on the team is aware, or if they are not aware of the change, it is both easy to notice and easy to learn. This is the basis for the practices called Kaizen. A more developer orientated formula is presented in the presentation Shaving the Golden Yak, I highly recommend watching it and thinking it through.

So find a small thing that can be changed that will improve your life, and hopefully those of a few others. Fix or improve the situation. This will give you practice and experience on putting changes into practice. Make sure you get feedback: could you have discussed it better, was it actually useful, did it upset another part of the system. Develop your feel for what can be done and how to do it.

Now three things have happened:

• you have improved the system,


• you have obtained experience on how to change the system


• the team has seen you successfully change the system.

Now pick another thing to improve, as your experience grows and as you eliminate low hanging problems you will start to confront the harder issues in the system but at least now when you say we have to change X:

• You know how the change will affect the system


• You know what problems it will generate (what rules need relearning)


• You know some immediate ways to fix, or improve issues the change will introduce


• the people around you are aware that you are knowledgeable of the system, and capable of changing it successfully