havkom

I am mostly worried about the current AI use in management. I’ve met a few with ”AI hubris” making poor managerial decisions that stem from their poor usage of ChatGPT (not understanding the importance of context, model sycophancy, etc).

Some people that are immune to listen to people with more experience will continue to be ”junior” forever. They may eventually not have the title junior, but they really are.

There are fundamental differences. Many people expect a positive gradient of quality from AI overhaul of projects. For translating back and forth, it is obvious from the outset that there is a negative gradient of quality (the Chinese whispers game).

My tip is: don’t use SDK:s for agents. Use a while loop and craft your own JSON, handle context size and handle faults yourself. You will in practice need this level of control if you are not doing something trivial.

What about GLP-1 antagonists to lower inflammation / hs-CRP?

Does this matter much? Git is a ”distributed source control system”. Are you using git in the wrong way? :)

Reminds me of C#.. IDisposible and IAsyncDisposible in C# helps a lot to write good mechanisms for things that should actually be abstracted in a nice way (such as locks handling, queue mechanisms, temporary scopes for impersonation, etc).

I tried:

-red

and:

red-red-red

But it did not work and did not get any response. Maybe I am stupid but should this not work?

What is the difference between them? Both seems like quite trivial implementations?

Good investigation!

Software developers nowadays barely know about transactions, and definitely not about different transaction models (in my experience). I have even encountered "senior developers" (who are actually so called "CRUD developers"), who are clueless about database transactions.. In reality, transactions and transaction models matter a lot to performance and error free code (at least when you have volumes of traffic and your software solves something non-trivial).

For example: After a lot of analysis, I switched from SQL Server standard Read Committed to Read Committed Snapshot Isolation in a large project - the users could not be happier -> a lot of locking contention has disappeared. No software engineer in that project had any clue of transaction models or locks before I taught them some basics (even though they had used transactions extensively in that project)..

The big threat of LLM:s is not the diminishing skills of established skilled developers, but rather the skill set building of junior developers.

try catch - where you catch the right types of errors at the right level is hard to beat.

However, many make the mistake to handle any errors at the wrong level. This leads to really buggy and hard to reason about code and in some cases really bad data inconsistency issues.

A rule of thumb is to never catch a specific error which you are not in a good position to handle correctly at that precise level of code. Just let them pass through.

Amen!

How to apply these rules on junior co-workers (who think they know what is best from reading a hyped blog post)?

Yes. It shines with real problems.

I have seen tons of ”abstractions” in recently created code bases from ”senior developers” which in actual fact is only titanic-grade mess of complicated ”indirection”. Many people nowadays are unfortunately not fit to work in software development.

BTW, I am currently working in an enterprise with a small team mixed with experienced developers (heros - but still always learning because of new complexities) and new developers (heros in becoming).

Absolutely fantastic and we create wonders, but it requires management to acknowledge skill and exceptionalism.

Yes. Focus on building all your team members to heros instead.

The other way around is possible, but you will end up with a team of 1000 people doing the same work as 10.

Windows 2000 Professional was the best OS ever. Only downhill from there.

This looks cool!

Using these technologies or frameworks may just as well indicate that they are not agile. Nowadays much more common that the wrong technologies are used in the wrong places.

The document vibe to me is like it is written by some junior engineers who have just read a blog post about the Netflix stack and think they know it all now.

First parts of the document are pure BS focusing on hype technologies rather than “Agile”. I mean, questions about ”Kubernetes or Docker Swarm?” etc.

The last section with flow chart is good though.

Lots of very strong opinions here what they should have done in terms of code/pipelines/etx from people who have no idea how CrownStrikes stack or build systems works and people who have no clue how to write that type of software themselves (including Windows kerneln modules).

The doctors example is good, however may not only be health communication between a parent and a doctor but among parents themselves to figure out what action (if any) to take in relation to a condition.

The hesitation to effectively communicate after CSAM may actually cost lives.

Did they recall the recall product?

#14401370

But now with 856+ points on HN about it, it is probably a valuable relic!

I agree. The state of level of “basic” knowledge in developers are dropping.

The consequences are that developers can tackle basic tasks which are supported by the frameworks they use, but once something is not supported or straightforward they don’t know what to do and get completely stuck.

From society’s point of view, the usefulness and value of the task force decreases and important problems are not solved or aren’t efficiently solved.

I think Apple holds developers and third parties to “click through” agreements, so I hope Epic does the same towards Apple (it there has been any breach).

Feels like it is a weak legal argument (even though some jurisdictions may have special “ticket cases” doctrines).

It is not Epics concern if Apple by mistake would enter into a contract with them or not. It is up to Apple to whom they offer such agreements and how.