Hello everyone!
My name is Tanner, and I am a .NET and JS developer. I work for a fairly large company where I develop primarily internal business applications.
I'm writing this post because I am hoping to get some feedback from fellow developers on my current situation.
First, let me explain a bit about our environment, then get on with my overall question. As it exists today, we have a .NET API and an ASP.NET MVC front-end. We setup MVC pages and use Bootstrap, vanilla JavaScript and JQuery to do everything. We do not use any frameworks or other libraries (outside of some basic charts/grids/etc...). All of our pages are essentially coded once and forgotten about. Almost nothing is reusable. The closest we come to re-usability is a master JS file with some common function calls that we use in multiple places.
So, this means that we do not use ES6, linters, or any package managers. Basically, as soon as we get past simple UI setups, we start venturing into JQuery spaghetti code.
As a young developer, I look around and see all of these cool advancements in JS and front-end development. I feel like we are in the stone age. I feel like everything is a complete mess, and we are just adding to that mess every day.
My question is this. Are we in the stone age? How can we begin to get out of what I see to be a mess?
I am interested in moving towards something like Vue or React, as that will at least get us into the modern era where can at least start doing things with npm, and various libraries etc... However, I am the most junior on our team, and I feel like this will be a huge leap for our team.
Is there any way to help smooth the transition, or to gradually start improving things for a team that is primarily familiar with Microsoft technologies, and are not well versed in JS?
I apologize if this post is too broad. As I said, I am the youngest developer on our team, I see a bunch of problems, but I dont know how to start fixing them. I am looking for guidance from more senior developers.
Thanks,
Tanner
Top comments (7)
It's great that you're noticing that there are issues and want to fix them. It can be really difficult to get a company to invest in changing an old system but the longer it's left, the harder and harder it gets. I'd first of all suggest talking to the senior members of the team and try to get an understanding of why they do things in a certain way and if they have any upcoming plans. It's really easy as an outsider to say they're doing things wrong but often with a long term project, there will be reasons why they took a certain path with the technology. However, that being said, you could just be somewhere where the senior members of the team are a bit stuck in their ways and they need a little push.
If it is the latter, I'd start by suggesting small changes. The code being repeated and not reusable would be a good start. If you notice places where there are repeated bits of code then bring it up with a senior developer. If they don't know why they're not reusing things, ask another, if no one knows then suggest a change and if they don't want to change then you have bigger issues and you'll have to really consider if you want to be in an environment like that.
Bringing something like React in might not be best for the team or the project. It's hard to know without knowing what you're working on, but just because something is popular and cool it doesn't mean it's necessarily a fit for every project. It really does sound as though you could be lacking in front end leadership in the team though. I can't see a reason why package managers, ES6 and good design patterns couldn't be used. Just because you are a young developer, it doesn't mean that you cannot start suggesting things, I guess just be careful with office politics and not stepping on people's toes.
Good luck!
Hi Charlotte, thank your for the advice.
I have been having conversations with both my boss and senior members on the team about the things I am seeing. They are not closed off to the idea's, but they are also not fully embracing them either.
I know that projects are always a balance, because I have worked on teams where literally everyone picked a different technology to build something, and it was a mess. But, in the past, I think we have fallen into the trap of always picking technologies that we know/are familiar with, over what will work best, which is not good either.
I think your feedback aligns well with what I am thinking too. React, Vue, or another framework will likely be too much. But I can focus on starting to integrate things like linters, ES6, better design patterns for code reuse, which will hopefully lead to more comfort with further changes.
Vue or React are next-project goals. In an existing codebase, introducing a frontend framework like that is a rewrite level effort.
But you can still use npm/yarn/etc! At the end of the day, you're serving a bunch of JavaScript files. A package manager can take care of getting thirdparty dependencies in one place to be served. Bundlers can help you manage your own code. None of this necessitates renovating your entire frontend.
Selling this kind of initiative as a junior member of the team means you need to have an answer for the question "how will this start making our lives better in the very near future?". It's not unlikely that the manual approach has had painful effects: dependency scripts in different places, having to track something down through spaghetti in order to use it, multiple versions of jQuery kicking around, that kind of thing. Look for those. If you have a solution in search of a problem, shelve it for next time.
Hi Dian!
Your feedback definitely aligns with what I was thinking, and what others are saying as well. I will avoid big changes, like a front-end framework, and focus on smaller, easier to digest improvements.
I am going to start looking into how something like NPM could improve some of the problems we face today. I agree 100% that the best approach to all of this is to focus on delivering value to my team as quickly as possible. That can get the snowball rolling, and from there we can explore more and more options.
Thank you for your feedback!
Hey Tanner, how's it going?
In the company I'm working for we had (kinda still have) a similar issue, legacy application with asp.net mvc and a new app with c# apis, react frontend, you know, more "modern".
My first advice is try to find more tangible issues that the architecture is causing you and your team, saying that it feels like stone age probably won't be enough to convince the business about making a huge change, it would be preferable if you could identify more impactful metrics, such as performance, time spent fixing features, etc. These will definitely add more value and convince not only your team but the whole company, and trust me, a big move like the one you're talking about takes time and money so the company has to be 1000% onboard with the idea.
In alignment to what I mentioned above, try to find measurable metrics that you can use to convince your team, it doesn't matter if you're the most junior dev, nobody should punish you for presenting ideas to improve the product. After you have your team onboard you all can swarm and create a strong speech to present to the company.
Best of lucks in your journey!
Hi Mauricio! Thank you for your feedback!
I agree that everyone needs to be onboard, and that's why I am leery of big changes like a front-end framework. I like your advice of sticking with measurable things I can try and fix. As I mentioned in one of my other replies, I think I am going to try and focus on bringing in linters, ES6, good design patterns, things that should be straight forward, and hopefully provide a path for additional changes further on down the line.
Thanks for your submisson, but it does not meet the help tag requirements. Please review the sidebar for more information.