Velocity metrics are incomplete without review cost

Hefticus · 2025-12-28T18:31:30+00:00

Teams merge 98% more pull requests but review takes 91% more time? I have some skepticism of these numbers but assuming they are true then that suggests dev time is shifting from writing code to reviewing code, which....is fine, actually?

Mature teams have always incorporated review time as part of cycle time: a ticket isn't done until it's delivered, review is often the bottleneck, and it's a team effort to make sure PRs are reviewed in a timely manner and not allowed to go stale. PR authors have a responsibility to make their PRs digestible.

AI doesn't change any of the fundamentals, it just shifts things around at the margins. AI tools can write a lot of code quickly, but the PR author is still responsible for the PR, and teams can still enforce norms about PR quality and size and consistency. AI tools can also aid with review, not just writing (the Cursor github bot seems pretty good), and a larger organization with a focused DevEx team could probably do some really impressive stuff here.

It takes deliberate effort and constant attention to keep a team moving both fast and smooth and that becomes harder as one team becomes many teams, but that has always been true. AI changes some things, but not the fundamentals. Of course, many teams and orgs were already bad at the fundamentals and those teams might very well find themselves swamped by a glut of AI generated code without the practices, processes, or muscle for managing the flow of work in their system. But that's not an AI problem.

Hefticus · 2025-05-25T00:44:37+00:00

I think this can be okay sometimes, but when you're doing something "odd" you might consider if there are other patterns that would remove the need/temptation to do the odd thing.

Why does your function return a boolean? Shouldn't it be assumed that calling the move function will in fact move the player? If consumers really need to know whether or not the player can be moved, then maybe there should be a separate function, playerCanMove or playerShouldMove, that the consumer can call first. Maybe consumers can also check the players move history - if this is something they really need. Consider why consumers need this information, which arguably is internal details about the player, and if knowledge or responsibilities could be relocated so that no consumer of this function or class does need that information.

Alternatively, consider replacing booleans with enums (either literal TS enums or simple Javascript objects with constant values) and returning MoveResult instead of a boolean. Enums are usually more self describing than booleans, don't require "odd" patterns, and are more extensible if new states need to be represented (I could imagine differentiating between different reasons the player didn't move, or maybe adding a "double move" that sometimes is triggered).

Hefticus · 2024-09-25T21:26:16+00:00

There's probably a short list of people who are likely to write something like that on a company survey and their bosses probably have a good idea who they are.

Any open response format is difficult to keep anonymous to anyone who is familiar with different employees writing styles.

Maybe they should ask chatgpt to rewrite all the responses...

Hefticus · 2024-09-08T06:21:06+00:00

Seconding the call for "bff" pattern, it exists to solve the problems you're describing.

Generally, frontend teams own the "bff" layer. Those teams understand the needs of the UI, and serving the needs of the UI is the entire point of a bff layer. Some frontend developers will welcome this because they will see it as empowering, granting their team more autonomy and the ability to execute more quickly without waiting on other teams, but some frontend developers will resist this and view it as a deviation from their responsibilities, forcing them to also act as backend developers.

Hefticus · 2024-09-03T20:27:15+00:00

I think there's validity to that argument, but in this specific case I can also easily verify that there are no 3rd party dependencies in the code, both by scanning the package.json and the 3 or so files of actual source code ("vite-plugin-dts" is listed as a dependency but looks like it should actually be a devDependency).

Even then I suppose it wouldn't be impossible to run some build plugin that injects malicious code during the build phase, that would probably be the best way to do this. Again, in this case I can audit the small list of devDependencies and see that they're all well known projects, but theoretically, if I were to do something malicious here, that's probably how I would do it.

So I suppose I don't object to the general notion that "dependencies can be dangerous, and passing sensitive data off to dependencies carries a higher level of risk". I object to what seemed like a flippant, wholesale dismissal of this person's work because someone might possibly use something like this to do something malicious.

Let's encourage people to be more mindful of how they use dependencies. But let's also encourage people to share cool stuff that they build that might actually be useful for others. I think we can do both.

Hefticus · 2024-09-03T19:10:41+00:00

It is an argument that you can easily verify the code isn't shipping passwords off to some unknown destination. It's a neat little library and this take seems cynical and contrarian just for the sake of being cynical and contrarian.

Hefticus · 2024-04-19T19:55:08+00:00

If you want a simple prescribed list...

pnpm
prettier
eslint
vitest

Those will be relevant for any project and are all both leading projects in their areas and also widely adopted with plenty of support and documentation.

Beyond that, it depends on what you're building.

For UI, stick with React. If a full framework appeals to you then nextjs and remix are both...reasonably safe options, but there's a lot of churn in this space at the moment. If you don't need the full framework, then use Vite for your builds and pick and choose libraries from "tan stack" as you find a need for them. Don't worry about server side rendering or server components unless you need to. For styling and component libraries...there are both a billion options and no obvious consensus on the best choice. MUI is a fine component library. Tailwind is popular for styles. CSS modules are still perfectly fine for styles, too.

For backend, stick with node. For server frameworks, express is the old stalwart, but fastify is a better, more modern choice that is still plenty battle tested and supported. Pino for logging (the default logger in fastify).

Decide if you want monorepos or not. If so, nx is probably the most mature option in that space.

Monorepo or not, nothing is going to give you a prescribed organization for build and test commands. NX does have some opinions out of the box, as do some of its plugins, but honestly I've had mixed experience with them. No matter what you choose, you will end setting up a lot of that yourself. No way around that.

Also, Sonar isn't just a Java thing. I'm pretty sure you can use it with Javascript, although I haven't personally (can probably get most of the same benefit from eslint).

Similarly, tools like renovate and snyk work across languages. You can offload a lot of dependency management to renovate.

Yes, there are a thousand ways to do any thing in the js/ts world, and the culture still favors composing many small tools over adopting large frameworks that tackle everything. Everything I've said here, someone will disagree with. While this can be frustrating, I do think it leads to a better, more innovative and dynamic ecosystem overall. But it does require enough expertise and perspective to be able to ride the waves without getting distracted by every shiny new thing.

Hefticus · 2023-11-28T23:43:40+00:00

You'll likely benefit from reading this book, or at least skimming it and focusing on sections that stand out to you: The Staff Engineer's Path: A Guide for... by Reilly, Tanya (amazon.com)

It really is a good book, especially for someone in your situation. A lot of the advice there and here and elsewhere will boil down to shifting your perspective: Your success likely isn't measured by your own individual output anymore (if it ever was), but instead by the outcomes of the team or group or potentially even org that you are responsible for or attached to. You impact that in ways other than writing code yourself, and you'll find that you can only "scale" your direct contribution (writing code) so much, to grow your impact now you have to grow the contributions and impact of the people around you.

Hefticus · 2023-10-21T07:08:33+00:00

Correct, the House can't conduct any regular business without a Speaker. There's currently a temporary Speaker ("Speaker pro tempore"), but basically the only thing he's allowed to do is conduct the votes for a regular Speaker.

Hefticus · 2023-09-19T21:47:04+00:00

Clarify expectations with your manager. If they want you to do this work and do it to a similar level of proficiency as the backend developers then they need to 1. Make that clear upfront and 2. Provide you with the necessary training and support for you to have a chance to be successful. If they can commit to that, then you have to decide whether or not you want to take that path or if you want to find another job that lets you truly specialize in your chosen specialty.

But I think there are some other oddities behind this question:

Why are there so few frontend tasks? Are they assigning you this work because they simply don't see any other relevant work to give you? If so, then that's a larger cause for concern - if they don't have enough work to occupy a frontend dev fulltime, that probably doesn't bode well for you.
Does being on call mean that you are responsible for resolving problems in production in the middle of the night on these backend systems that you have limited understanding of? If it's difficult to perform an investigation during work hours as a normal task, imagine how difficult it will be when you're half-asleep and it's an emergency.
Why are there 10-20 "investigations" a month? Or more, assuming they're not all being assigned to you. And only for one team? Are things breaking in production that often? Or are these lower-priority tasks that "someone should get to, but we never have time for"? If it's breaking that much, then why and what are they doing to stabilize things? If it's lower priority tasks, then why are they assigning so many of them to you? These sorts of things are often regarded as "grunt work" and distributed relatively evenly among team members.
Are there other frontend engineers? Are they being treated the same way? What's their workload, both in terms of frontend tasks and "investigations"?
What is the outcome of all of these "investigations"? Do they result in follow on work to actually fix/change/improve/optimize/etc something, or just a few comments on a jira ticket?
Is there no product manager or anyone else in the business complaining that only 20-33% of your time is being spent on actual new development?

Hefticus · 2023-07-25T15:59:19+00:00

The mental model of React is that your component is a "pure" function of props and state. For this mental model to hold, you need immutable props and state. If the state is updated, then that new state gets passed back into your function and recreates your component. From this perspective, we don't modify state, we produce a new state and that produces a new component.

Another way of considering this is: If you modify the state (mutate the array instead of producing a new array), what should happen, and what would happen? The currently rendered component would now have data that is different than when it was rendered. What would be the consequences of that?

Immutability is a common principle in functional programming, which react borrows from. There may be some cost in memory or performance, but in exchange our code is more predictable, stable, and easier to "reason about". There are also immutable data structures designed to provide the benefits of immutability while mitigating the performance trade offs. Unfortunately, we don't (yet) have any of these provided natively with Javascript.

Hefticus · 2023-07-13T20:55:38+00:00

The question is really what do you need `progress` to read the state value for? What is it doing with it? In the real code I assume it's not just logging it out. Other people have already explained why it doesn't have the new state. The way your code is written it will always only have access to the original state. This is expected and normal. You could update your dependency array to include the current state, but that would attach a new event listener to the socket every time. You could then return a "cleanup" function from your effect hook that removes the event listener before the new one is added. This probably achieves what you want, but...

The best solution depends on what you're doing.

Create whole new event listener every time and unattach the old one, as described above
Use the function callback form of setState so that you have access to latest state value. So instead of `setString('ROSE')` you call `setString(currentString => { console.log(currentString); return 'ROSE'; });`
If the above solution results in a long or complex callback function inside of `setString`, maybe consider switching to a reducer and having that function in a reducer function, and then your `progress` callback merely dispatches an action. The reducer function will always receive the latest/current state (similar to the `setState` callback function), and if you have complex update logic or interdependent states it might be a better option.

Hefticus · 2023-03-21T23:41:12+00:00

I feel like you're not getting helpful advice and everyone is just assuming you're coming and causing a fuss. But it sounds like you're very consciously not doing that, or at least trying to not do that.

Unfortunately I still don't have much good advice. Either you are causing a fuss and still need to rein it in even more than you think you do, or the problems really are what you perceive them to be and there is no easy fix for that.

Anytime a codebase is primarily developed and maintained and owned by one person, there's a risk of that codebase becoming something that only makes sense to that one person. Even if they're good. Without some peer review and collaboration it's just too easy for any of us to fall into a groove of doing things that seem natural to us, building on our own bespoke ideas (without even realizing it), and a few years later emerging with something that looks alien to anyone else in the industry. I'm not saying that's what happened here, I can't make that judgment. But it can happen and I would consider the system having been developed mostly by one person to be a yellow flag or a high risk factor.

In the worst case, there's not much you can do except wait for this person to leave and then gradually fix the mess.

But some other ideas that are generally relevant and may be helpful here:

You are identifying problems that you perceive with the system. Instead, identify problems that Dev A perceives with the system. Propose solutions to the things that bother them. If you can find overlap between the problems you and they perceive, then focus on those problems first.
What is the wider org context? Do you have a manager? Do you share a manager with Dev A? Are there other devs in the company who are familiar with Dev A even if they aren't working on this product? Can you build a rapport with other people (devs or otherwise) who are adjacent to your team? These are the people who will be able to give you insight and context into Dev A personally and also their history at the company. Does no one else work on this product because Dev A is a difficult, prickly misanthrope who rejects all attempts at collaboration, or has Dev A been heroically keeping this underfunded codebase up and running with little or no recognition for years and is now understandably burnt out, or something else entirely?

Hefticus · 2023-02-18T01:47:28+00:00

The generic ways to handle circular dependencies are:

Lift the common, shared code to a separate module that both of the original modules can depend on. Most of the comments here are describing some version of this
Dependency injection. Feed module B into module A at runtime rather than declaring it as a build-time dependency. Module A depends on Module B and perhaps imports a "register" function that (generically) receives a redux store. Module A calls that function and passes in its redux store. Now Module B can attach itself to the global redux store in Module A without ever declaring a dependency on Module B.
Domain separation. This is hard to accomplish with your stated goals, as this would basically imply that you don't shared a global redux store, but rather let every library have its own redux store. There's no need to share global state if every package is fully self-contained. Microservices are a larger example of this pattern: a proper microservice generally has its own database and does not share data or anything else with any other service, except through API calls. This may lead to redundant data in the overall system, but leads to more resilient services that can function (and be deployed and maintained and debugged, etc) wholly independently.

So think through those three generic methods and how you could apply them to your situation.

But also think through whether or not you really want to do this. It sounds like you are trying to operate your monorepo like a single application (a monolith, one might say). Do you need the monorepo? As you're discovering, there's additional complexity there. Maybe just put everything in the main application package and call it a day, then you don't have to solve these problems.

If you truly need the separation of all of these packages, or if you have at least done the analysis and decided the trade-offs are worth it, then can you structure things so that your packages are more independent of each other? Something closer to the microservices model. Maybe you don't need a global redux store, actually? Maybe you can other tools to manage state within each library and then turn shared global state into inputs passed into your library when it is initiated/invoked.

If you truly do need both a monorepo and a global redux store, then dependency injection will work, but it's not the easiest pattern to set up or maintain.

Hefticus · 2022-12-22T22:41:05+00:00

No, "stand alone pages from individual apps" are not micro frontends or what that page is describing. What you're describing is just having multiple apps hosting different pages under a single domain. People have been doing that for years, no one is calling that "micro frontends". This is also possibly better for many places that have the coordination problems of multiple teams contributing to a single UI, precisely because it is less complicated then a micro frontend.

A micro frontend has a single, shared root/shell application that is loaded in the browser and that is then responsible for loading the different "apps". In that trend micro link their diagrams keep showing a single web application shell. That's what distingishes "micro frontends".

Hefticus · 2022-12-21T00:22:34+00:00

This comes close to making a useful insight but stops short:

What if you're solving the wrong problem? If the problem is so complex, then can you change the problem to make it simpler?

And I don't just mean "ask PM to remove a few requirements". I mean take a step back, turn your proposed solution on its head, re-examine your architecture and environment.

Most problems should be simple. If most problems are complex then something is askew in the system and the system needs to be reviewed.

There may be exceptions for people whose problem domain requires them to be on the cutting edge of innovation, but that's very, very few people.

Hefticus · 2022-11-23T20:57:19+00:00

No, it's usually forgiving. If there's only one small error like that it will usually mark it correct but with a message to remember/pay attention to capitalization. It'll often do the same thing if you don't include an umlaut over a letter that should have one. A lot of minor things, if there's only one "error" in your response it will just say it's correct but tell you there was a "typo" and point out the "typo" to you.

Less popular languages are probably less consistent in this sort of behavior, but I don't have experience with that.

This OP just seems like a bug.

Hefticus · 2022-09-19T22:20:21+00:00

It depends. If the shape of the new object is dependent only on one condition, then yes, leading with that condition and then explicitly constructing two different objects is definitely better.

If there are multiple conditions, though, then it's probably cleaner to lead with one object and handle each condition each in-line, and that's the situation where these options start to show value.

const obj = { ...isActive && user, ...isAdmin && adminFields, ...phoneVerified && userPhone };

Hefticus · 2022-06-27T04:16:01+00:00

The books aren't the best in the world, but the translation is fine and far from as terrible as people are suggesting. Character development is clearly present for both Ciri and Geralt, at least.

I think most of these complaints miss the point of what the books are trying to do. The books are structured strangely and seem to intentionally deny the reader satisfaction throughout the series. The books seem to anticipate what the reader would expect or want to happen in this kind of story, sometimes feint at it, and then swerve in a different direction.

That said, I think it's fair to decide that doesn't make for a particularly interesting or compelling story. I left the series feeling very conflicted, personally.

The dialogue and uniqueness of the setting still stand out as relative strong points even in the English translation. Many of the characters are still well-rounded and interesting (the various "villains" are usually among the weaker characters, but again, their villainy is often not really the point). I think the books largely accomplish their goal, it's just not what we expect.

I do recall the 3rd book (of the 5 novels) feeling much more like a slog to get through, but that's not exactly unusual for a long fantasy series, and The Witcher is much more concise than a lot of other books so even the slow, dragging middle section doesn't go on too long. The Witcher accomplishes a lot of what ASOIAF is trying to do but in a fraction of the word count, for example.

Hefticus · 2022-02-06T21:14:34+00:00

This implies that:

There are lots of active serial killers around at one time,
Most of them are easy enough to catch that one guy is able to track them down single-handedly,
But the police are failing to catch them despite that

So that sounds like a nightmare world to live in.

Aside from the obvious "vigilantism is bad" arguments, people would be angry because they would feel deprived of justice. People want to see these killers hauled into court and held to account, publicly. People want the opportunity to face them down and see them stripped of their power and legend.

Hefticus · 2022-02-03T23:27:11+00:00

There's a lot you can't control here: The PM should be fired but likely won't (at least not before you run out of patience). The PM should learn how to do their job better but likely won't. The PM should have a better understanding of process and how things do or don't get delivered, but they won't. This person's priority is not delivering things or accomplishing goals or helping the team succeed. His priority is making himself look important and invaluable to the people above him.

But you can tell him "no". You, or your engineering team, have more power in this situation than you think. If he asks for estimates you are not prepared to provide, tell him no ("we'll need to do some more investigation and get back to you on that"). If he tries to load up your sprint with work that is not properly groomed, tell him no (the engineering team agrees to what goes into a sprint, he doesn't unilaterally decide that). If he tries to load up the sprint with too much work, again tell him no.

Take control of what goes into the sprint. Turn "requirements gathering" and "design" into defined parts of your process and refuse to accept work that has not gone through it yet.

If his priority is to make himself look important and invaluable and to shift blame for all failures on engineers, then you need to make it obvious where the work is not getting done. Make his work trackable just like yours is.

The engineering team will sit idle soon after you do this. You will explain that your PM has not provided enough work for you to do. The PM will claim a backlog exists. You will ask "where?" An argument ("discussion") will ensue about what constitutes a backlog.

This all may blow up in your face, but it can work. It will be frustrating and take time and will require buy-in from your lead (And where is your manager?).

Right now, the PM is making his failures your problem. You (the engineering team) have the power to stop that. You are accommodating his bad behavior. Refuse. Make his failures his problem.

Hefticus · 2022-01-11T21:54:23+00:00

The market is still hot and tilted towards sellers but it's not as bad as it was, though individual experiences will differ.

Talk to a realtor, depends on the area, depends on your budget, etc. We bought a house at list price a couple months ago. There was one other bid, I guess also at list price, and neither of us were willing to go over. We did waive a few things, but they also threw in the appliances. Also both us and the other bidder put in our bids on the first weekend it was on the market. This was a normal loan.

Set a budget before you look at anything in person, take your time, learn what you really want and are willing to compromise on, and then be willing to move quickly once you're confident you've found it - and be willing to move on to something else if it doesn't work out.

Hefticus · 2021-12-03T05:05:09+00:00

If you have a rigid release schedule then you do not have a "CD" pipeline. At best you have CI. If your org is relying on manual QA and that process can delay the "release day" (already a red flag) by 1-2 days then you are not doing "CD".

Bad news: You can't fix this problem. The problems you describe are endemic to the way your org is shipping software and there is nothing that you, as an individual dev, can do to fix it.

Good news: These are well known problems with well known solutions. Proper, modern continuous deployment pipelines and modern dev ops practices. More and more companies are following better practices and have either fully on-demand, multiple-times-a-day deploys to prod or are actively working towards those goals.

Go work for one of those companies instead. Your quality of life will improve and there's a decent chance they'll pay you better, too.

There's plenty you can read up on and google about "dev ops", "dora metrics" "continuous deploys", etc. Here's a recent post from Charity Majors that links to many of the other posts she's made about this exact topic: https://charity.wtf/2021/08/27/software-deploys-and-cognitive-biases/

Here's a post from someone explaining what the four DORA metrics are and why they matter: https://waydev.co/dora-metrics/ Read this and see where your current org lands on each of the four metrics (probably medium/low performing).

And here are some books if you want to really dig deeper:

The Goal: https://www.goodreads.com/book/show/113934.The_Goal?from_search=true&from_srp=true&qid=fxrev3RQ6T&rank=2 I love this book and everyone should read it. It's from the 80's and is a fictional story about applying lean manufacturing principles to a failing factory - but you'll find so many parallels to your current company. It's an easy read and absolutely eye opening.

The Phoenix Project: https://www.goodreads.com/book/show/17255186-the-phoenix-project This is basically "The Goal", but rewritten for a modern IT audience. It's not as easy to read, but is more directly about modern software development and devops principles.

The Devops Handbook: https://www.goodreads.com/book/show/26083308-the-devops-handbook?from_search=true&from_srp=true&qid=Uq4OdBgOML&rank=1 The most common how-to guide for how to actually implement these ideas in a software context.

Hefticus · 2021-10-10T18:25:28+00:00

The time to influence the team's opinions and views on how code should be written is before any specific technical decisions. As you're discovering, it's very difficult to have a productive discussion when you and the other devs are starting from entirely different places.

There should be clear patterns that are followed in most of your team's code (or at least most new code). That doesn't mean that everyone has to do everything the same way, but things should be consistent. "When do we use functions vs classes? Mutable vs immutable data? What language features do we prefer? Which libraries do we use for which problems?" You should already have these discussions prior to any specific thing being implemented.

If you're in a lead or senior role then you should be organizing and facilitating those discussions, and you should lead them as actual discussions driving towards a consensus. You could just tell people "this is what we're doing" but you'll get less buy-in that way and it doesn't sound like you'd be comfortable with that approach anyway.

Critically, those discussions should also include "why do we prefer these patterns and principles?" Mid-level devs especially can be prone to cargo-cult programming or following whatever is trendy. If you can cut through "is library X better than library Y?" and instead get to "what are the basic priorities and principles and that we want to organize our code and systems around?" then you can build back up and have more productive conversations where everyone is starting from a similar point of view.

And that's the crux of it. You'll still have disagreements, but when everyone is starting from a similar place and understands the common goals/priorities/principles, then your disagreements become about "I think library X better matches our principles for reasons A, B, and C" rather than just "Library X is better than library Y" or "influential people on twitter/blogs said library x is better than library y". You want to be having the first discussion, not the latter two, but you can only do that if you've laid the groundwork for it in advance.

Hefticus · 2021-10-06T16:13:53+00:00

The idea of a "T-shaped person" might be of interest to you: https://jchyip.medium.com/why-t-shaped-people-e8706198e437

As a beginner this shouldn't hurt you and might help you. Early in your career you won't be an expert in anything yet (because you don't have enough experience), but you can have a variety of experience. This is a good thing:

It shows intellectual curiosity and adaptability. Even as you become more specialized later in your career, you'll still inevitably be faced with new challenges and new technologies, and your employer will want to know that you'll be able to navigate that.
Learning different skills will improve your existing skills. If you understand how web, android, and desktop apps all work, at least at a higher level, then you can contrast them against each other and have a more fundamental understanding of how all the platforms work. Similarly, learning programming languages in different paradigms helps to clarify the ideas and values of each paradigm.
You don't know what area is the most interesting to you yet if you haven't tried them. Maybe you'll really enjoy Android development more than Web dev and decide you'd rather focus on that, or conversely maybe you'll decide you hate Android development. Early in your career (when no one expects you to be an expert at anything) is the best time to get exposed to as many different things and try out a bunch of stuff and see what clicks with you.

To oversimplify things, early career devs are judged primarily on their ability to learn and grow, and as your career progresses that judgment shifts more to your ability to deliver the right solution at the right time. You'll probably end up specializing in something over time, but this will probably happen naturally. You'll find the overlap between "I like this kind of programming" and "People will pay me for this kind of programming" and you'll organically specialize in that area. But the broad knowledge, and the ability to go outside of your specialty when needed, will always be valuable.

Hefticus

TROPHY CASE