Reasons why Angular developers could be unproductive

Reasons why Angular developers could be unproductive

Did you know that developers can work 10 times faster on your product depending on a lot of factors? First we have the non-technical factors like:

  • Waiting for the api or even the contracts that are not being ready yet
  • Working on crappy machines, where developers don't even have rights to install their favorite IDE
  • Scope creep, waiting for the designs, etc

In this article I will sum up some technical reasons why Angular developers can become unproductive. Trust me, those reasons can have a massive impact on the productivity of your team. (Most of it does not apply only to Angular)

Bad architecture

When you have a bad architecture, it's hard for developers to find their way into the source code. When you have a good architecture developers know exactly where a new piece of code belongs or when they should extract a piece of code to make it re-usable. A good architecture makes sure developers don't have to think anymore about which decisions to make when developing on a big project

Lack of guidelines

Lack of guidelines decreases consistency. Consistency is key for productivity and maintainability. Having clear guidelines again decreases the need to think about how to do things and will enforce best-practices

Over-use of the redux pattern

Adding everything into a global store glues all the features together and makes it hard to decouple things. It also takes a lot of time to create reducers, actions, action types, selectors, effects and write tests for them. Even if most things can be generated, we still have to maintain the code. Keep it simple, and keep the state as low as possible. Use signals, or light-weight state management solutions.

Lack of encapsulation in the codebase

In a big scaling codebase we should prevent everyone from using code that is already there, unless it makes sense to re-use it. It should always be a decision whether to re-use something or not. The more we re-use the more dependencies we get, and the harder it becomes to maintain. Making code re-usable also decreases flexibility as an update to that specific piece of code impacts more and more of the codebase. Write re-usable code, don't re-use it unless needed.

They write unit-tests for everything

Unit-tests are great for testing logic, algorithms etc. Writing cypress/storybook tests make way more sense when testing components in the frontend. Because you spend less time writing them, they test the actual logic and they won't break when you refactor code. One of the biggest ROI decisions and productivity boosts for me was testing my components with cypress against storybook stories. It actually became fun to write tests.

They install whatever angular dependencies they like

Angular is great, install Angular, but don't install dependencies that have a dependency on a certain angular version (mostly ngx-dependencies), unless they give great credibility and update together with all major versions. Being tied to a specific angular version prevents you from updating, and makes your project outdated quite soon. This also affects productivity.

They lose time over forms

Forms in Angular are a complex thing. There are reactive or template-driven forms to choose from, we need validation messages, we need conditional validation messages. We want re-usability of form groups and validations. We need asynchronous validators.

Most importantly the most solutions I've seen contain a huge amount of boilerplate, resulting in demotivated developers.

Setting up a streamlined solution for forms can really help out your team in the long-run.

They copy-paste directory structures

Duplicating code isn't bad per se. It gives flexibility and decreases complexity, so there are definitely use-cases on when to do that. However, in my experience there are a lot of developers copy-pasting complete directory structures and then replacing stuff as a monkey-job. This is error-prone and takes a lot of time. By creating custom generators you enforce your own guidelines, consistency and let the generators do all the work for you.

They don't refactor on a day to day basis

You shouldn't be scared to refactor. You should be scared to over-engineer. Over-engineering is the worst thing that your team can do. When you are working in an agile environment. You are basically agreeing that you need to change stuff all the time. This should give you a "don't-be-scared-to-refactor" mindset. The refactor-mindset doesn't mean rewrite everything all the time. The refactor mindset means this:

If your component shouldn't be re-used now. Keep it close to the feature. If you need to re-use it later, extract it later. Don't be afraid to constantly move things around in your workspace. It keeps your codebase fresh and more aligned with your product. Keep it simple. And remember, a good architecture makes sure that moving things around should be a breeze.

They don't accept legacy

If you have a piece of code that is absolute crap, but it works, and you don't have add features in it, you should leave it (unless it impacts other stuff). What I mean with that is: it works, and it is battle tested, and you know it's crap but you don't have to touch it. Leave it there, don't refactor that. Don't go for the perfect code-base. Trying to achieve the perfect code-base proves that you care more about code than the product, which again decreases productivity, "big-time"!

If you need to add features in that crappy part of the workspace, it is a clear indication that it might be worth investing some refactor-time.

Accepting legacy is one of the most important things that developers can do. After all, developers should be problem solvers, not evangelists.

Final notes

I hope you enjoyed these tips. I've been involved in over 150 angular projects and seen a lot of stuff.

If your team is unproductive at #Angular, I might be able help. After all, I've helped a lot of companies stepping up their productivity game and it results in better results, and more motivated people. Drop me a DM if you are interested. or send me an email at brecht@simplified.courses

Abdoulaye Gueye

Aspiring Software Engineer in Alx_Africa || Frontend web development ||Electronic and Electrotechnical Technician

1mo

wow great !

Kishore Kumar Andra

Software Developer | Web | JavaScript

1mo

Forms are a real concern 😞

To view or add a comment, sign in

Insights from the community

Others also viewed

Explore topics