Dtyjlui

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, this resulted in production and maintenance nightmare. The code base was so large and complex that places were 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).

It also performed very poorly, precisely because of the multi-layered structure of patterns, and class libraries that design required. For example, clicking a button on a screen to make a single call to the database would result in 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.

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 belligerent way. This often leads to interesting conversations as to why those things are as they are. Maybe changes will happen and maybe not, depending on whether the value of changing things is smaller than the cost.

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.

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

Yes You can. BUT...

You have to be careful.

At the begining of my career (very long time ago) I was lucky/unlucky to get into a few months old project as the "Junior".

As the first thing I noticed, there was (OMG) no code repository! All merges of code were done manually by sending zip files to each other by mail.

So I went to my (also new) manager and suggested that we should have a repository. Answer was: Ok, organize it ....

So organizing a code repository, without help, been new in the company, now that was a humbling experience.

When I set it all up, (shock) nobody wanted to use it. So I tried to push things along and luckily my manager understood it's importance so I had support.

But this resulted in that I wasn't well liked and unfortunatly got a nickname derived from the source control system.

So my take on this is, first feel out your team members, what they think is important to set up next.

Maybe they also have a list like yours. Maybe they have though everything through and they wanted to do that "thing" on the list. Maybe they.... (whatever)....

The whole team has to be aligned.

But if they are not, then You can still work professionally.
And find like minded people and work together how you think it should be done. If this brings good results, more people will work with You, eventually it will become "the" process.

Just like with code, the same for development processes: continuous improvement is needed.

So Yes, You should always try to improve, that which is possible to improve.

But also remember many people You are working with, could already be professionals, and they know what is wrong and what is needed.

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 organizational change is hard even for a senior so if you really want to make a difference do it in the right way:

• 
  

  Not during the first weeks: Use this time to:

  
  
  
  
  
  • Create a good first impresion. Show that you fit in the team.
  
  
  • Understantand the culture and politics or your company. Is it safe to push for changes?
  
  
  • Build a good relationship with coworkers
  
  
  • Learn about the process, rules and needs of your team
  
  
  • Learn your work and do it the best you can. You will surely be busy enough.
  
  
  
  



• Choose your battles. Get some early victories: You may arrive with energy to change everything but this is unrealistic. Focus on some low hanging fruit and show that your ideas work. You want them to be receptive to more complex improvements. And remember that things are easier in books.




• Consider the implication to others: I do refactors affecting lots of files. Even if they improve the code I must be very carefull to avoid turning the merges into a pain in the ass. Try also to undertand the reasons why they keep working like that. May be they can't use Scrum as they lack tests and the are, understandably, afraid to push untested code to production frequently. Writing a realiable test is no easy task. The current code could be really hard to test. Furthermore, the team may not used neither to write tests or testeable code. The current code base may specially hard to test and needs to be refactored. It may require years to change this problem but at least you can focus on the root cause.




• Do not judge. Do not demand. Ask for it and listen carefully: This is a moment when communication is critical and we, the programmers, are usually not very good at subtle nuances. There are techniques to help. It is easy to keep pushing for our idea instead of focusing on the answer. First make sure that they feel that you have got their points. Understand that feelings are important. What does this change makes them feel? fear? insuficiency? anger? frustration? hope? Lazy? Stupid? (Never make people feel stupid). Of course you would have asked a lot of questions before and this will prevent a lot of false steps.




• Lead by the example: complaining is easy, creating the change is hard. Show results and people will believe you. If they do not use test you can write your unit tests. If people do not document you can share some google docs with the team. Understand that "Ok, do it" is one of the best possible scenarios and then you need to deliver. In this case you need to have thought what resources you are going to need. Example: give me a small Amazon instance and two hours from the admins for a Jenkins server




• Keep It Small and Simple (and Cheap): You do not want to wait for a formal budget approval or have your bosses think that you are lossing valuable time from expensive programmers. It would be great to have this code review sofware or evaluate several open source tools but we will just use the repo for the moment.




• Get critical mass: Gather the group of people focused on improving quality. You can even go with them to conferences and ask for help or mentoring. Peopleware describe the "waking the giant phenomenon" in with the base of the team literally rebels against some stupid practices that slow productivity. This individually would have been really dangerous and I would not have recomend. But if all the group agrees change is easier.




• Give it some time. Afterwards vote with your feets: You may want to try it during a few months up to two years. But some companies do not have easy solutions. Some teams do not want to change and do not have incentives. And some code bases are pure horror. If you feel that it is you against the world remember that there are plenty of offers in job pool. You want to learn good practices and in the long run you will be better in a pleace with sligtly less wage but getting experience that will make you more valuable.

Bonus: If you succeed write it down for your CV/Interviews. As a Junior you usually have very little to say and creating a change for better is always a great sign. You want to have a very clear and realistic view about what you personally did and what was work from others. Imagine the following interview question.

• Tell me about a time in which you made a difference in the team.


• Well, I was in a place were they had very old fashioned practices. A
  lot of people was't happy with it and productivity had a big room to improve. So I proposed to make a fast experiment with retrospectives, we did X, and Y and the as a result we had this wonderfull measureable result".

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.

Don't start with the most complicated things like Scrum. Start with the easiest steps possible.

You did not mention source code management. Do you have some source code repository (git, svn, cvs, ...)? A strategy for tagging and branching? Those are simple steps a beginner can do. Read up what problems these steps (try to) solve, and how that helps your company reduce costs (that's what management is interested in).

Next step could be automated builds, nightly or directly after every check in, e.g. with Jenkins. You can also run tests automatically. And add some tools for measuring code quality (oh yes: defining some coding standards is also a good step).

As for scrum, better read about "Extreme Programming" (XP). Scrum is based on many ideas of XP and adds a formalized process around them - the concepts of XP can still be used without that process.

Suggest things, provide back ground information, try to convince others to try it, analyze the results, ... but don't expect to much co-operation from others: most people prefer to stick with their old bad habits. But when you don't try that, nothing will improve.

You said the team is quite new (3 years old), so if you can not introduce some good principles now, it will be harder do that 10 years after. Some of the things you mentioned such as testing and versioning system are among the ones you could suggest already, but do not throw the suggestion just like that without emphasizing on their obvious benefits and picking the tools your development stack requires.

In the beginning, ask questions

Reading your list, I would suggest the following questions (refer back to your list to see how they fit):

• How do I see what work the business owners are requesting?


• Have you tried [Scrum]?


• Who's the product owner for this?


• What roles are there?


• What does [this role] do?


• What role is responsible for [this activity]?


• Have you tried a daily standup?


• How do I communicate my impediments to the rest of the team?


• How do I find out on what other members of the team are working?


• Should we put [this] in the issue tracking tool?


• How should we write [this] in the issue tracking tool?


• When [this] happens, should we put it in the issue tracking tool as [that]?


• How do we test?


• How do we record our tests for others to reuse?


• Have you tried [JUnit]?


• Where is [this] documented?


• Have you tried [MediaWiki]?

Replace things in [brackets] as appropriate to make the questions make sense or fit your priorities. Consider rewording if my wording doesn't match your style.

You may have already started doing that. Favor one-on-one conversations over group conversations. Because one-on-one, you can get a better read of what the other person thinks. Is that person for this change? Against it? Weakly? Rabidly?

When you're new, asking questions is practically free. People should expect you to ask questions. Even if your questions implicitly advocate a position that they oppose, they shouldn't get angry. They should explain why they oppose that position. I recommend against arguing with them. Arguing tends to harden positions more than it convinces. Note who has what position and move on.

Later, take steps

Look for ways that you and possibly others (i.e. those you noted agreeing with you previously) can start the changes you want. Not everyone wants a standup? Why not? Perhaps those of you who want one can have your own standup. Not as effective as with the whole team, but more than you have now.

When you have an impediment (and assuming you can't share in a standup), email the team for help.

Identify what the roles should be, possibly with the support of others who agree with you. Start consistently going to people when work involves the role you (possibly a group you) think that they should have. If they push back, ask them to identify who should own that role.

Ask product owners (that you identified) to write up descriptions of how they think their product should work now and in the future.

Install a test framework (if others favor this, make a joint decision on which framework) and use it for your projects. When you're fixing bugs, write tests. Document this in the bug report on the issue tracker (wrote test demonstrating bug, stored at [location]). Encourage others to run the tests when they make changes. If they don't, run the tests yourself and submit issues to the tracker as necessary.

If you can get management support, install wiki software or similar and start documenting your stuff. If people ask you questions that show they didn't read the documentation, point them at the relevant pages. Encourage them to ask more questions if they don't understand the documentation. If they continue asking questions covered in the documentation, quote from the documentation when answering. Consider encouraging them to update the wiki if you think that the problem was structural rather than them not reading.

I would suggest only concentrating on one task at a time. And certainly only push one at a time. Don't push hard. See this example of pushing harder than the group wanted. Concentrate more on changing your behavior than theirs. If your way is the right way, that should be obvious to people observing you. Actions speak louder than words. Try not to repeat yourself with the same person when you do nudge. Once you've led the horse to water, leave the choice of when or whether to drink to the other.

Eventually, you'll be senior

Over time, your team will hire new people. You'll stop being the new hire and be able to advocate your positions with new people. Work with them to make changes. And you may find that you are making progress with your existing teammates as well. Or if that's not working, look for a new job where they have better practices. There's no real hurry. You have a job. You can wait a while on having a better job, either by improving that one or finding a better one.

Short answer: No, for all the reasons outlined in the other answers. Even when being a middle or senior dev, it's usually better to seek first to understand when joining a new team.

A proposed solution:

1) whenever you see something you feel should be improved, take note of it! (in a notebook, in a digital note...)

2) After 6 month, go back to your notes and check them. How many ideas now feel pointless and inadequate? Most likely a lot, you saved yourself some embarrassment. If some ideas still hold, now would be a good time to introduce them, if possible by testing them yourself first.

Late answer, and agree lots of good content in the other answers.

I think it needs called out that a key issue here is not the specific practices, but overall team culture.

• Creating cultural change is hard.


• More so if you seen as "junior"

Everything else can follow if there is a means of achieving continuous improvement.

My approach to achieving that is:

• Documented processes and procedures


• Retrospectives with the team whose actions are changes to the process documentation.

I guess if you do not have sprints you do not yet have regular retros. All you do need is a conversation with the team, and then action that.

You can easily start documenting processes. "I am the new guy, have I got this right? Let me write that down." It is important to then actually follow the process yourself, or try to and call our where it breaks.

Maybe you start with such conversations being ad hoc and then suggest regular rituals.

Taking this approach allows an incremental, softly softly, approach. You can avoid appearing as a junior who things they know it all and instead try to be a facilitator for the team making change.

Some considerations:

• Some teams have a poor process but actually already know that. They
  want to change and just need something to catalyse that. Other teams
  really stuck in their ways and a lot harder to change.


• Same goes for individuals.


• You need to be sensitive to that and figure out who on the team is
  open to change and who is not. Understand why.


• Find easy wins.


• Make the changes welcome to the team: Find their individual pain
  points and try to help fix them.