siscia

Are all the position in Microsoft WFH?

I have several friends who works in Microsoft and would disagree

That's usually what a judge decides.

Anyway, I went checking and I wasn't able to find any opening in Microsoft in the Seattle times online version. Which is definitely not a nice optics and would play unfortunately well with the current allegations

> It doesn't say anywhere that it cannot be advertised in a small town.

I think it is implies in: "The newspaper must be widely distributed in the area where the job is located."

Just to be clear, when I say that it is impossible even to self review, it was an indication of how difficult is to review code of colleagues.

Thanks so much for saying this!

Even with a single instance of Claude Code, running I am producing so much code that it is impossible to even self-review.

Can we please focus on that?

At the same time if the organisation want code fast, it gets code fast.

The revenue for a new feature today is something sure. While the cost associated with supporting such feature will be up to debate in the coming quarters.

As often it is the case, we are moving on a long vs short term trade-off space. And I don't think any experience will generalize

It seems VERY cooperative.

If you can afford that, with all the coordination costs that it comes from it, good.

An alternative is just to let the downstream service own the retry logic. Too many requests? Just error out as soon as possible.

Each team manages its budget and each other team adapts.

> If you can't spend the time to write it, why should anyone read it?

Because the value of writing are not the words on a piece of paper but the idea they convey.

Politicians speech are not worth listening too because they have a copywriter polish them?

Teacher assistant homeworks are not worth to do, because they are made by a TA and not by the course professor?

Of course there are writing as: "Hey ChatGPT write me a piece around coding with LLMs" and yeah, those are not worth reading.

But most of the writing is usually, these are the ideas, this is how the idea are structured together, now let's review them and then let's get a nice prose out of it.

Do you have specific examples of what you mean here?

It is not clear to me how the verbosity metrics works. Can someone shades more light on it?

I am building software factories and deepseek IS the workhorse.

I personally found V4-flash an amazing model and really hungry to try 4.1-flash

For software factories, cost is much more a concern that standard development workflow and using anthropic models is just a non starter

You are not wrong but if we go deeper we will find more nuances.

> tests should test behaviour and not structure.

Of what?

The whole idea of software architecture, and underlying of my messages, is to structure the code so that it is easy, but before easy, possible, to work at the right abstraction level.

Which allows to tests the behaviour of components and not their structure.

Trivial example, say your code read from a socket and manage the bytes with some CPU operations and write them to another socket. (You may recognise it is basically what a compressor do)

The way in which you manage read and write to the sockets will make dramatically simpler or much more difficult to write good tests.

If you adopt strategies like sans-io, you will see that the testing is almost trivial.

If all the logic sprawl up from the read syscall in a loop, you will notice how more challenging testing becomes.

---

To answer your question, the way I let LLMs write code is very DI (dependency injection) based.

A class never instantiates another class - all the dependencies are passed to the constructor. Including time. Including whatever DB iteraction.

The reason why I prefer this is that I can test each component at every level of abstraction. I don't have to. But I can.

My current approach is to force coverage higher than say 80% as default and then when a bug is discovered drill down to the components.

It is still early, but I find that this experiment makes little to no sense and it is barely useful.

The way you test code cannot (and should not) be decoupled by the way in which you architect the code itself.

80%+ of effective testing is not in the testing framework but in the code architecture.

The author doesn't mention how the code is being architected and managed.

For what it is worth, I found that forcing agents on DI/hexagonal architecture and forcing a trivial coverage check is quite useful and produce overall good enough code with relative little effort