Jacques de Vos

TL;DR a thought experiment / guide for larger software product orgs (not a prescription): a ~20 person team structure (aka Peloton)—about 7 2-person-crews, ~5 supporting specialists, and a product manager—might ease new bottlenecks from LLM efficiency. Counts are illustrative, not fixed slots.

This talk introduced LLMs to software developers as a new kind of processor with remarkable capabilities, framed within the history of computing.

Treating your mature enterprise product carelessly will get your business into deep trouble, but gold plating a new product, before you are sure that you are building the right thing, can bring your venture to a premature end.

In order to escape the common traps of software development, teams and managers need to understand the consequences of their decisions - they need to understand the dynamics of software engineering. This is not an easy task and we need solid help. We need maths!

Although software engineering has become crucial to our modern society, it is still a new and often misunderstood discipline.

Choosing the wrong mobile tech stack sets you up for a world of pain. But how do you select the right one from a plethora of current options?

Dealing with an ageing code base is one of the hardest challenges that software development teams face. Legacy code bases can slow teams to a crawl, and therefore it is critical to solve this on the road to agility. Software rewrites fail at alarming rates! Refactoring – a safer approach...

Here is a list of classic articles and books that have informed my thinking on software engineering.

_**“Nothing is more powerful than an idea whose time has come.” Victor Hugo**_

As a software engineering coach part of my job is to help teams become more effective. To this end, it is sometimes useful to employ concepts from self-help books, but I don’t always enjoy reading these, they often stretch a few insights into endless anecdotes.