109

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?

  • 10
    I notice that one of your tags is Scrum. Is your team a Scrum team? And if so, are they holding retrospectives? – Daniel Jan 8 at 23:07
  • 10
    Is there any reason you use "they" instead of "we"? E.g. "My team is fairly small and somewhat new (<3 years old). They lack"? – Thomas Koelle Jan 9 at 14:02
  • 40
    Just an FYI, if you have worked for multiple companies you're likely not a junior anymore. – kevin Jan 9 at 14:26
  • 11
    What makes you think that the things you list are "better", and not just the latest time-wasting fad? Can you make a reasonable case for each one? – jamesqf Jan 9 at 19:20
  • 11
    "Management is open to the implementation of improvements [..]", that is largely irrelevant, more important is whether or not the rest of your team is open to it. If they aren't, having management buy-in, but not team buy-in is a road to an adversarial relation with the rest of your team. – Mark Rotteveel Jan 9 at 19:21

12 Answers 12

182

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.

  • 19
    I could not agree more with your observation. Practice is by far the best way to know what works, and even then there is always more, and other. – Kain0_0 Jan 9 at 5:31
  • 226
    If a project is insanely complex, dreadful to change, then it is not a “fantastic piece of software design”. – Steve Chamaillard Jan 9 at 7:25
  • 85
    This answer makes it sound like OOP is a body of knowledge that academics are obsessed with, while the industry "knows better". In my experience, it's the other way around: academics care very little about OOP, while lots of companies are still obsessed with it. Academics tend to concern themselves with more timeless but obscure concepts (whose value often takes decades to be appreciated by the industry). – Theodoros Chatzigiannakis Jan 9 at 9:26
  • 13
    Moreover, expect senior engineers to be wary of fads. – John Wu Jan 9 at 10:09
  • 67
    "It was a fantastic piece of software design. Sadly, in production and maintenance, it was a nightmare as a result." The second part means the first is untrue. Good design by definition makes software better. If the theory doesn't actually work, the theory is just wrong and following it is a terrible idea. – jpmc26 Jan 9 at 10:28
43

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
  • Lots to agree with there. One thing worth stressing is that no codebase or procedure is perfect; everything is always a compromise. And much as you might want to chuck everything away and start again, as you say, IME it's usually far better to evolve slowly, by small steps. That way you can bring everyone along with you, and avoid losing existing knowledge. The important thing is knowing where you want to get to; that way, you can spot and take the opportunities as they arise. – gidds Jan 9 at 10:57
  • @gidds I think that was my point, its best to make small changes that everyone is aware of, or at least is obvious to them has changed, and easily read. While i do believe its important to have a long-term goal in mind to help you pick and choose between all the ways you could improve things, I don't think its always possible to formulate one, particularly for junior developers with limited experience in working at scale with people. Formulating improvements to the status quo is much easier. does this irritate you? Yes What is something small you can do to improve the situation? – Kain0_0 Jan 9 at 23:38
  • @gidds reading your comment again, I agree no one procedure or process is perfect, or even applicable to a given situation, and if miss handled can even take the team to a place worse than never having tried. That being said, even when successful the end result is usually a compromise between all of the competing requirements that the software and its team somehow have to satisfy. That is a lot harder if the business is in a regulated industry. Governments are not fond of rule breakers. – Kain0_0 Jan 9 at 23:55
20

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.

  • 1
    It sounds to me like you went behind people's backs without justifying anything to your fellow developers first, just having a manager force it through. Nobody likes "that guy." So yeah, if you have suggestions for improvements, bring them up with your colleagues, but most importantly: be able to justify your suggestions to them. Why will it make things better? How will it save people time and effort? Are there any drawbacks to the new way? Etc. If you can predict and prepare responses to people's concerns, they'll be much more likely to accept your suggestions willingly rather than by force. – Alex Jan 9 at 9:54
  • 2
    I didn't feel as if it "went behind people's backs". I reported the issue to my manager, he told me to take care of it, and I did. – Robert Andrzejuk Jan 9 at 10:14
  • 17
    "unfortunatly get a nickname derived from the source control system." LOL I hope you didn't take git. – BЈовић Jan 9 at 10:50
  • Git wasn't around yet. – Robert Andrzejuk Jan 9 at 11:31
  • 10
    @BЈовић Maybe they called him "subversive"... :-) – Alexander Jan 10 at 11:32
14

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.

12

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".
  • “Not during the first weeks” I think especially during the first few weeks simply asking questions can achieve a lot. Not only will you learn about the project and work flow, you’ll also make your colleagues think about why X is in Y and not in Z, missing documentation, cumbersome tools (why do I need 20 commands to integrate my change?) etc – Michael Jan 11 at 12:34
  • 1
    I may have stated it badly: Of course you sould ask questions on other moments and specially during the first days. My intended but may by midcommunicated point is that as a Junior you do not "PUSH FOR CHANGES" the first days as you may be be seem a know-it-all arrogant and you lack tools for something so difficutl as changing an organization – Borjab Jan 11 at 14:40
9

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

  • 6
    As a junior employee I proposed all of these. Over a number of years, with some assistance (and lots of buy-in) I then successfully implemented them. By the end I was the senior architect. It can work, and it's often worth trying. ;) However you have to pick your battles and know when you're facing an uphill struggle for something that may not even fit the profile/dynamic of the organisation very well. In another role I was tempted to go down the same route, and decided not to even broach the topic because there it would never have worked out and wasn't particularly important either. – Lightness Races in Orbit Jan 9 at 12:06
  • 4
    Unit test and continuous integration are a good choice to start. They will give you the best return on investment. Do not try Scrum without the technical practices that allow it to work. How can you have frequent deployments if every one is dangerous and needs a lot of work from testers and sysadmins? – Borjab Jan 9 at 19:21
  • Unit tests/integration tests are not necessarily something one can immediately start implementing due to architecture. Furthermore, they tend to force certain patterns which can go against the existing order of things. While they do have value, it's not always an easy home run as suggested. – NPSF3000 Jan 13 at 5:40
2

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.

1

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.

0

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.

0

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.

  • +1; one of the better answers with a lot of good ideas. – Keith Jan 14 at 3:26
0

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.

0

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.

protected by gnat Jan 10 at 4:51

Thank you for your interest in this question. Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).

Would you like to answer one of these unanswered questions instead?

Not the answer you're looking for? Browse other questions tagged or ask your own question.