Should a (junior) developer try to push for better processes and practices in their development/IT team?

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?

As a junior developer, how can I broach critism of not-yet used chosen tools

So I started a month ago at relatively small company (12 people in the building) as a junior developer without professional experience apart from my own (7 years) and no degree. We’re building a JEE app that’s been going on for 15 years, and for the next version it was decided we would rebuild the frontend, removing frames/iframes/JSP and using a restish API. They also decided that we would use ExtJS as a framework. I just started discovering it and here is what I thought:

  • They have a large, although far from exhaustive, base of available components


  • The framework provides poor information over encountered errors. For instance, it doesn’t test the type of data sent to classes, leading to cryptic x is not a function where a proper framework like react would have said x is y expected a z.
  • The community is small and googling errors is often useless, so you are left helpless / requiring a senior dev’s help
  • The UI looks like shit. Seriously. Their icons are ugly. Their buttons are just rectangles. They have a poor choice of colors. Do the even have a designer? A six years-old could have done a but better job.
  • The underlying mechanics are not obvious: scopes are unclear, what a single param will effectively do is unclear…

I’m not the only one feeling that way, our intern webdesigner agrees.I’d like to bring this up to my manager, I think if I brought it up the right way he would listen. Although, it’s not the first time I talked about technology choices (we still use CVS and we don’t use any build tool like maven) but I do believe that the technology choice, when rebuilding from the ground, is a matter of importance and going off the wrong foot might be detrimental.

I already asked why they would choose ExtJS over React/angular etc and it seems because – our headquarters like extjs, and already paid for it – licensing might cause issue with another approch (since we would need several libs) – tech debt could be an issue (eg Angular versionning)