I agree with your comment, but I disagree a both the example opinions... complex is the discussion :D
I heard something that helps better framing those discussions, use "familiar" instead of "simple".
An highly abstract way to access a database table, with ORM for example, can be simple because everyone is expecting it and knows how to do all tasks (changing schema, troubleshooting, managing transactions, etc.).
Doing userService.pgSql("select ....") in the same way can be simple.
By chance, recently in an architecture discussion document I added that one of aspects to consider is how easy is to remove (the whole thing) if it's not wanted anymore.
It was an obvious case because it was an AI capability, which can be become deprecated/useless/too-risky very fast.
The article is interesting but I think it deviates from a common developer experience as many don't work on Python libraries, which likely heavily follow patterns that the model itself already contains.
Since you're getting into a senior role, learn the mantra, it depends :D
The usual trade-off of a well paid software development job is lack of job security and always learning - the skill set is always changing in contrast with other jobs.
My suggestion, stop chase trends and start to hear from mature software developers to get better perspective on what's best to invest on.
And why the mantra is always true?
You can find stable job (slow moving company) doing basic software development and just learn something new every 4 years and then change companies.
Or never change company and be the default expert, because everyone else is changing jobs, get job security, work less hours and have time within your job to uplift your skills.
Keep chasing latest high paid jobs/trends by sacrificing off time.
What's the best option for you? Only you know, it's depends on your own goals.
The downside is that https://haveibeenpwned.com/ can only find "exact email" addressed, as in, you must search for myname@gmail.com, myname+service1@gmail.com, etc.
I don't have time/will to find more consolidating information but some EU-Elites regularly use NGOs to support their own policy goals, against member states governments and their populations. They always excuse themselves by saying they fund everyone... but one side of the issue usually gets more funds than the other.
If I recall correctly in one "EU wants to monitor the internet" regulations, EU directly funded targeted AD campaigns to convinced some Member state populations to support it so the government would change its intended vote. They were caught and backed off. Then they funded some NGO to do it :D
I appreciate that "tools" that are used to build the final version of a module/cli/service are explicitly managed through go.mod.
I really dislike that now I'm going to have two problems, managing other tools installed through a makefile, e.g. lint, and managing tools "installed" through go.mod, e.g. mocks generators, stringify, etc.
I feel like this is not a net negative on the ecosystem again. Each release Golang team adds thing to manage and makes it harder to interact with other codebases. In this case, each company will have to decide if they want to use "go tool" and when to use it. Each time I clone an open source repo I'm going to have to check how they manage their tools.
My personal estimation is that this will be noticeable in the first six months of 2025 in the USA big tech organizations.
I think this is actually already in motion in board meetings, I'm pretty sure executives are discussing something like "if we spend Z$ on AI tools, can we avoid hiring how many engineers?"
I heard something that helps better framing those discussions, use "familiar" instead of "simple".
An highly abstract way to access a database table, with ORM for example, can be simple because everyone is expecting it and knows how to do all tasks (changing schema, troubleshooting, managing transactions, etc.).
Doing userService.pgSql("select ....") in the same way can be simple.
reply