[larsonnn]

> Good engineers know how to influence others and the organization to deliver a solution as a team.

This is a Problem, assuming someone is good at talking is also a good engineer.

> Good engineers constantly work on reducing complexity in the codebase to consistently provide high quality.

Complexity for the manager? Who is deciding how complex a system is. This could also be a skill issue with the „team“ by taking skilled engineers and mix them with not so skilled ones.

Overall the article is written for managers which try to add a image of an engineer which is like a manager. Influence people and give up on complex stuff.

[devjab]

I know a lot of engineers follow various principles like SOLID, DRY, Clean Architecture and so on, but as far as complexity goes it’s really rather straight forward. You never add abstractions until you can’t avoid them. We’ve had 20 years of these principles (and what other nonsense OOP had brought with it) now, and despite the fact that many of them were written by people who haven’t worked in software engineering since a decade before Python was made they still remain popular and largely unaltered. Which is silly considering our industry has never been more of a mess, with so many teams building complexity to “future proof” things that they will never need, to the point where some teams actively hinder the business.

Complexity is fairly straight forward in my opinion. You build after the YAGNI principles and you include things from SOLID, DRY, CLEAN, whatever when it makes sense to do so. If you happen to enter a team that has dug themselves into a pit of unnecessary complexity you need to work on reducing it.

This is takes a good engineer, because the fundamental reason to do this or that comes down to engineering. People who follow dogmas are not good engineers. You will even see the authors of some of these principles like Uncle Bob tell you that people who over complicate their code bases misunderstand his principles. Convenient when your career is selling consultant, but also very true.

[imiric]

> Complexity is fairly straight forward in my opinion.

That's a bold take.

The difficult thing with complexity is that it's an abstract and, sometimes, subjective concept. (Not speaking of measurable complexity like cyclomatic or algorithmic.)

It may involve abstractions, yes, but those are usually introduced with the argument that they—ironically enough—_simplify_ some interface or process. It's difficult to argue against that since we deal with abstractions on a daily basis which _do_ make our lives easier, from the hardware layer and up. So then the task of removing abstractions becomes an uphill battle to convince the rest of the team that this is indeed a good idea. This is a sociocultural and political problem, not strictly related to engineering.

So I don't see the task of resolving complexity as being this straightforward. The best approach I've found of dealing with this is to focus on things we can measure instead. Use linters to warn you about cyclomatic complexity, function length, dead code, single interface implementations, and any other quantifiable metric that contributes to increasing complexity. Even this is often difficult to align on within teams, but with it in place at least there's an objective metric that can guide the team in the right direction.

[FLT8]

> You never add abstractions until you can’t avoid them.

Whilst I accept that bad abstractions can really hold a codebase back, good abstractions and layering are what make code clean, understandable, and maintainable. I don't think we should throw the baby out with the bathwater.

What's important is having good designers who understand the domain and are able to judiciously select the "right abstractions" to apply at the "right time". Often this will mean people who have worked in a domain and made or experienced the consequences of mistakes previously.

Bad or inexperienced developers will write bad code. Good, experienced devs will do a little better. Don't let inexperienced devs design abstractions that you'll be stuck with for a while.

[patrickthebold]

> You never add abstractions until you can’t avoid them.

What would be a case where you would _have_ to add an abstraction? I'd say you probably never have to, but things will get start getting complex.

[devjab]

I would abstract a holiday calculator service. I’d abstract a base class with “created_at” and similar for your data models in a traditional OOP sort of thing along with the audit table. I’d probably abstract something like an e-mail validation mixin.

Basically things which will never change, and when they do, you really don’t want them to change in a million things.

Otherwise I’d probably never add abstractions. Sometimes it makes sense to build a service which owns a domain on a business which is then consumed by others, but you have to make sure the consumption can be stopped when that domain is no longer relevant without it causing issues.

I’m not sure what my personal stance is on frontend components. Probably as low reuse as possible.