srvaroa

This feature is 10 years late

Looking forward to someone writing the Spring equivalent this on the JVM

I'm sure many people have equated "typing code faster" with velocity, productivity, and execution speed. But I am not doing it.

I'm saying that given N developers, if they all type code faster, you get more code. From the linked text: "Will this translate into a net increase of actual value or just an accumulation of slop and technical debt? Regardless of the answer, there will be more raw code."

The argument I'm making is based on more volume of code. Not on quality, value, etc. of whatever that code is doing.

On your point about nobody having thought "my problem is that can't type fast enough". The problem "shit, I'd know what I want, I'd rather spend 10 minutes typing than 1 hour" is real. An LLM allows you to say "I want a piece of code that does X" and it hydrates that into the 500 lines of code. You materialize the thing faster.

Now. Yes we can go back to your point. Was that idea good? Is the code good enough? etc. Those are valid questions, but orthogonal to my point. My point is not about the quality of outputs etc. It's about "this thing helps you churn more code, and throw it to the systems that digest code".

Thanks!

"When AI is able to deliver coding tasks based on a prompt, there won’t be enough copies of the Mythical Man Month to dissuade business folks from trying to accelerate road maps and product strategies by provisioning fleets of AI coding agents."

Submitted yesterday, but no luck :D

https://varoa.net/2025/04/07/ai-generated-code.html

I guess yes? https://danluu.com/productivity-velocity/

7. This incident has reminded that many people mistakenly assume that git tags are immutable, especially if they are in semver format. Although it's rare for such tags to be changed, they are not immutable by design

IME, this will be more "learned" than "reminded". Many many people set up pipelines to build artefacts based on tags (e.g. a common practise being "on tag with some pattern, then build artefact:$tag") and are just surprised if you call out the flaws.

It's one of many practises adopted because everyone does it but without basic awareness of the tradeoffs. Semver is another similar case of inherited practise, where surprisingly many people seem to believe that labelling software with a particular string magically translates into hard guarantees about its behaviour.

Well, this AI operates now at staff+ level

The primary reason I keep writing is that this, the plain written word, is The Platform to transport ideas in time and space. It has passed the test of time in ways that each of those platforms you mention have not (nor any other medium, e.g. video, etc. at least in our lifetimes).

I think of those platforms more as distribution / syndication mediums, using them for stuff like throwing it out there and reach others (which I somewhat care about because the topics I write about are those I like to exchange opinions about with others, but not obsess in terms of needing validation) and keep some degree of isolation from their policies, relative importance vs others, algorithms, UI/UX choices etc.

KISS > DRY

Yep, this is an important point.

We wanted the metrics to create the right set of incentives to make people improve the right parts of the system.

For example, we did present deploy frequency prominently. This gets people to see it, managers to want their team to be in the upper percentiles, etc. which drives a set of practises that, in general, and backed by research, are beneficial.

One of my favourite features was putting two graphs together: size of PRs vs. time to review. Time to review went up more or less linearly to size of PRs, but past a certain threshold (different per team!) time to review dropped sharply with larger size of PRs. This made for a good conversation to topic with teams that sets the right incentives for smaller PRs, iterative development, etc. (and it happens to correlate with deploy frequency).

Why do line managers want this info? Do you think they have someone in mind for promotion, and they are looking for metrics of accomplishment?

Nah, you don't need to assume malice :)

Most times it was managers with good intentions, not realizing that those metrics were either pointless (e.g. how much code / commits does $person do), or toxic, in the sense that it leads the team to game metrics, that it prevents the manager to actually understand why the values are what they are, that it opens the risk to link them to promotions and perf reviews etc.

Explaining them all this was generally enough!

And, cynically, I would say that senior managers don't care... because to them, most hands-on engineers/devs are fungible. What is your view about why the upper levels never ask for it?

Actually that wasn't the case. AFAIK (I left at some point, but kept a bit in touch with former colleagues) upper management started using some of those metrics to set organizational objectives.

Again, same argument. You don't need to assume malice. Management has a legit interest in engineering productivity. What happens most of the time is that they don't know how to measure it in an effective way, or how to use it to drive organizational change. Providing guidance is part of your job as a Platform eng.

I worked on an internal platform for a large engineering org and was responsible for choosing what features we put in.

We had the technical means to track everything from commits to reviews, jiras, deploys, etc. Some of our most celebrated and impactful features were reporting on Accelerate metrics and related. E.g. deploy frequency, size of changes, duration of stages in the dev cycle and such.

I set a very inflexible red line: we don’t expose data more granular than at team level. Ever. No excuse.

Quite a few line managers would come to me asking for “personal metrics”, and even engineers in the team were super interested in building that (“with all this data we could…”).

My argument was that these metrics are toxic and invite misuse. A second factor was that this misuse would generate mistrust from engs against the platform and damage adoption.

Instrumenting an organization thought of as a system is fine. You want to see where are bottlenecks, you want to have measurable targets for how technical work is done and how it correlates to business goals/KPIs.

You want to offer teams metrics of their delivery my process so they can take the info and implement improvements whenever they see fit, and have a data driven conversation with the business (e.g. about the right setting for the carefulness knob)

But teams are the minimum unit of ownership, we stop the instrumentation there. Sure, a team’s performance ultimately links to individuals, but that is the manager’s job to figure out.

Interestingly:

* only line managers asked for this info, nobody in a director/vp/cxo role * the most annoyed by me saying no were engineers in the team who wanted to do these features

Yeah that was my point. In the end both approaches can be fine (depends on your context). The real difference is that whatever choice you take, it will need the right investment in tooling and support.

"This scale – the scale of devprod, and in turn the scale of the overall organization, such that it could afford 10 FTEs on tooling – was a major factor in our choices"

Is basically the summary for most mono/multi repo discussions, and a bunch of other related ones.

“Anytime you apply a rule too universally, it turns into an anti-pattern“.

Quote from Will Larson found in another HN post (https://review.firstround.com/unexpected-anti-patterns-for-e...) right after checking out this one.

My main advice would be to obfuscate those identifiers in a way that you can use the semantics in the very specific system do want/intend to, but prevent the rest of the organization / systems / external world from using them for their own purposes. At the end of the day it's about not turning them into a public API (which means you lose control over them).

Nor does it account for the effectiveness it bought the project in the meantime.

This is a great point! I should have mentioned in the article, but in the examples mentioned part of the nuisance was that people involved could envision alternative solutions that would have also been effective without causing most of the long lasting trouble.

But, sometimes that's not possible (I do mention that they are not always avoidable)

best practice is usually to encrypt it before sending it to the external world

Yeah, although encryption is basically a way of hiding semantics from the external world (or, everyone else but whoever generates them) no?

If a pizza team struggles to work in small independent changes, and end up having to deal with long lived branches, merge festivals etc. then the problem is really not in the tool chain.

Yes, I assumed you did need some integration with the user's account (my case). Thanks for the answer!

Nice feature!

Just curious, how long did the API extension approval take? (been waiting for almost 3 months on mine)

A business model based on engineers as the decision makers is perfectly possible. But it is confined to tools where an engineer can make a local optimisation without direct impact beyond that scope. IDEs are the best example. Engs in a company can be allowed to make whatever personal IDE decision that makes each one of them more productive, and the global impact of aggregating those individual decisions will be ok. Jetbrains is a testament to this.

But this is not the same for every tool. The thread author focuses on examples that fall in this second category like Redis, Terraform, AWS, etc. Unlike with IDEs, sprawl resulting from individual decisions in databases, infra management or cloud infra becomes a problem. For both! The company has to maintain a heterogeneous stack. The seller can’t make a meaningful enterprise deal just because some team chose Redis. This means that you will want to do some standardisation. At that point the impact of the choice and the size of the license become big enough that, in the same way as eng leads will want a say, finance will too, for good reason.

And needless to say, the moment finance is in the picture you will have to justify the choice in a language that is challenging for most engineers.

I have just outsourced the problem and paid a platform (ghost.io, mainly because it allows for custom domains on the most basic plan.)

It still is cherry picking one out of many examples where the headcount reductions were by far not that drastic as in Twitter.

The parent reply has an important point: a good % of headcount reductions tend to affect r&d and the type of projects where cutting investment doesn’t have a negative short or even medium term effect on the company. Sometimes it can even be positive for operations (e.g. infra teams have to support less product teams). This is mostly why it’s very uncommon to see headcount reductions lead to instability, etc.

Long term effects (e.g. stagnation, no innovation..) may manifest, but are harder to see clearly in advance, and when they do happen the connection to those layoffs from N years ago is not obvious/even remembered

It basically "oh well I'm going to take a 2m break, let's click that short video " and getting sucked into the vortex.

A similar effect happens to me on Twitter. I sometimes click on a video / dumb meme account, etc. just to take a break or whatever (Twitter does a much worse job at creating the attention vortex, so it's easy for me to literally make it a 2m break). BUT, some hours later the algo digests my click and turns my feed into absolute garbage repeating an endless firehose of dumb meme content. (In Twitter's case this is actually helping me: I really avoid clicking on dumb content so the algo doesn't go nuts.)

I haven't needed to be so drastic, but removed the YT app from my phone. There is a fair amount of good content that I find very worth consuming from YT (mainly educational videos) and would not like to miss. But, the mobile app makes a very strong effort to push you to shorts, which is the real danger. Shorts are proficiently engineered to just suck my brain into a doom scrolling comma. I tried removing shorts from the app, but it keeps pushing them in your face, so I ended up deleting it and watching via browser, logged out. I've heard several acquaintances having the same experience / solution.

It's a pity the YT PMs insist on designing the app like a Vegas casino, I'd really like to use the YT app for healthy usage, but well.

I'm working on an app to help solve this. It's still waiting for Spotify's approval but I can whitelist some users while in development mode and some beta testing / user feedback would be appreciated. The profile shows my email.

I don’t find they are valued like that. IME most devs who use them perceive them as annoying boilerplate. Proof being how Lombok or Records are generally well received among the younger gen.

The problem on this topic is that they cargo cult getters/setters by inertia, usually because more experienced engs pass it on as good practice.

It’s not an inherent problem to the language.

You don't need to assume a bad actor in the team to encounter the situation of having 100% code coverage with meaningless tests.

Indeed. The thing is, I was replying to a comment that referred _explicitly_ to a bad actor. The situation @ponector describes (team's coverage indicator is rendered useless because have a bad actor games it), THEN the cause is not coverage. It says nothing about coverage beyond "a tool only works in certain conditions".

You bring 2 more cases that break the indicator, and I agree with both (there are more!). We have (1): We all make mistakes and write dumb tests. (2): Coverage is not useful for _some_ practises / scopes of testing.

I agree on both. But we're back on the same place. I'm not saying those problems don't exist. I'm saying that those are not problems coverage ever claimed to solve. Making a sweeping dismissal of a tool because it doesn't solve problems it never claimed to solve is throwing away the baby with the dirty water.

* Coverage does not claim to be a tool to fix bad actor, (1) or (2)! There are other tools to cover those risks (e.g. managers, code reviews, pair programming, etc.).

* Discussions about those tools (code reviews, etc.) tend to make the same mistake. Find problems the tool doesn't claim to solve to dismiss the tool.

* This all happens because people pretend to treat tools like coverage, tests, DORA metrics, as silver bullets. They are not. They are all meant to be a toolbox that engineers evaluate and use where they yield value.

And this is why yes, a lot of the "$tool is useless because $situation_where_it_doesnt_work" conversations are fundamentally about cultural issues. If your team uses a tool without knowing what problem is trying to solve, you have a cultural issue. If your tool has an actual purpose, and yet engineers are intentionally working around it, you have a cultural issue. Etc.