> 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.
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.
> 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.
> 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.
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.
Interesting read. Just to add, even HTTPS isn't completely safe from Man-in-the-Middle attacks, especially in corporate environments. A few points to consider:
- Some apps bypass or poorly implement certificate pinning.
- Companies using self-signed certs can be spoofed.
- There's always the risk of compromised Certificate Authorities.
- Corporate tools that inspect HTTPS traffic, while useful for security, can inadvertently become a vulnerability if misconfigured or hacked.
Always good to remember: HTTPS is a protective layer, but not an unbreakable barrier.
Every advancement that simplifies coding potentially displaces a job. If tools like GPT-4 amplify my efficiency by even 1-5x, it's not just code— it implies a broader workload shift across the tech sector.
I'm also wondering if it'll impact compensation in any way, as the work becomes easier and more accessible, I'd expect the pay will lower, since more people will be able to do the job with the help of AI.
From my perspective, hailing from Germany, I don't anticipate a decline in developer compensation. Instead, I foresee a future where companies will be selective, opting for developers who are adept at integrating AI into their workflow.
As we begin to reshape our approach to project construction, the inclusion of AI systems will become a standard component in our calculations. This realization will inevitably lead us to understand that certain tasks no longer require as many developers as they once did. Consequently, there might be a reduction in hiring rates for developers.
Nevertheless, I remain optimistic that while the demand for developers might become more selective, their compensation could potentially increase due to the specialized skills required in an AI-integrated landscape.
Maybe, but LLM are trivial to integrate, it does not take any special knowledge or experience. Integrating in-house trained models is difficult, but LLMs really changes that.
Pretty simple it’s just like any abstraction. This AI will not work when nobody would deliver the answer beforehand. LLMs are given inputs of existing code. When you abstract that you better hope you have good code in it.
So my question would be, what is the use case?
I guess it’s more like planing software and not implementing it.
You can pretty well plan your software with ChatGPT. But it will just help you not really doing the job.
The demo already shows the problem. It picks an event, the AI picks Earth Day. Then it makes a recipe with an avocado in it.
And writes it is good for the planet. Avocados are exactly the opposite. They have an extremely high water consumption and then have to be imported from all over the world.
Contrary to the author who claims, "Auto-GPT pushes the boundaries of what is possible with AI." I don't find that.
Why can't you just use GPT-4 as it is. It is an insanely tool to simplify many things. But it's still a long way from being ready, and it's not meant to decide anything on its own. And even to reflect reasonably out of own motivation.
Is testable code a tradeoff too much? That cannot be answered globally, only locally. That's why we have engineers, after all. You could eliminate the entire profession of engineering if "which tradeoff is best" could be answered broadly without deep understanding of specific circumstances.
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.
reply