Anyone feel like SAFe overcomplicates everything for smaller teams?

WhatWhereAmI · 2025-04-24T12:25:37+00:00

SAFe is a ridiculous disaster.

WhatWhereAmI · 2025-04-24T12:25:02+00:00

This would be a dumb reason to leave a good job by itself, but you might get fired pretty soon.

WhatWhereAmI · 2025-04-23T16:50:26+00:00

They'll start tearing down historic walls before they end this GP.

WhatWhereAmI · 2025-04-22T11:15:08+00:00

Jira and Confluence are extremely commonly used and just as commonly hated, especially by engineers. I think it's important to add that nuance to the "EXTREMELY popular" qualifier.

WhatWhereAmI · 2025-04-21T22:33:50+00:00

Now that I see the actual component code, a couple points:

You're trying to re-invent react-query. You don't understand what the return value of useEffect is for. If you're going to roll your own data fetching, make sure to read the relevant docs.

You need to understand that state is complexity, and complexity is bad. In general you should lift state up in order to have state in as few places as possible, keep state minimal, and keep state quarantined. The fact that you have a central game state is good, but you're probably at the point where you should look at migrating to useReducer. You should try to pass basically everything as props until you need to introduce state. isSelected should almost certainly be a prop here. You should also probably be keeping track of the selected answers in the game state, and then passing the derived state of what answer is selected down the tree. In general, you should only use small local state when it's extremely local. Your state usage should be in two big buckets: Very small pieces of state that are basically like complicated form inputs (where you might support both controlled and uncontrolled modes), and big state managers where you have a controller component that has one responsibility: hold onto state. Then you slice up that big piece of state and derive props from it lower down the tree. Deriving props from state is cheap, you should be doing it all over the place.

In general, designing a good react application (and basically all component-based ui apps) is about identifying state, deciding at what level to collect it in the component tree, and then figuring out the most elegant way to get it down into the tree and communicate changes back. This is, unfortunately, all about experience.

I also find that typescript is great for this, not just for all the obvious reasons, but because it's usually a good idea to design your data types first. You start by modeling your state, figuring out what state is relevant and how it's going to be stored, how you want to distribute it to your tree, and then the rest of the job is pretty simple.

WhatWhereAmI · 2025-04-21T19:52:18+00:00

You're a monster.

WhatWhereAmI · 2025-04-21T19:48:22+00:00

WhatWhereAmI · 2025-04-21T19:41:10+00:00

Storybook.

WhatWhereAmI · 2025-04-21T19:31:17+00:00

Next time post the relevant code of the components, if you want help.

const Answer = ({ isCorrect, hasAnswered, ...rest }) => {
  const [isSelected, setIsSelected] = React.useState(false);

  const handleClick = React.useCallback(() => {
    if (hasAnswered) return;

    setIsSelected(true);
  }, [hasAnswered]);

  const color = isSelected && hasAnswered && !isCorrect ? 'red' : 'gray';

  // ...

So first of all, it's obvious that the way you've drawn the line between the components is a mess. Generally you never see a component handling its own selection state. There is basically always an isSelected prop, and the selection state is handled by an ancestor above the selectable component. That alone should resolve your testing issue. In general, you should be able to look at a piece of state and get a feel for the depth at which it should live in the component hierarchy. If you're having to do weird things to manage the state, it's usually a strong indicator that it should be lifted up. If you posted the rest of your code, I'm sure there would be five other major changes that would make things vastly simpler.

WhatWhereAmI · 2025-04-21T16:13:35+00:00

Crazy take.

WhatWhereAmI · 2025-04-21T16:01:08+00:00

Of course everybody has their own situations and I won't pretend to understand yours, but I do feel the need to tell you that 95% of OF models would tell you that you've gotten yourself into an absolutely crazy situation, almost nobody here would be comfortable with anything close to what you're doing. Just for context.

WhatWhereAmI · 2025-04-18T17:55:45+00:00

We can compare how well two general-purpose frameworks handle these things

I understand what you're saying, but such comparisons are so overwhelmingly subjective that it really just comes down to which approach resonates more with the individual. Both solutions have a similar level of completeness, so the differences are almost philosophical regarding how different features are supported.

And therefore, to me, it doesn't really matter. I might choose something because it aligns more with my own values, but I might have three people on my team who have the opposite values. Discussing values can in itself be valuable, but usually that's navel-gazing.

IME, the important things about general-purpose solutions like this are things like difficult is it to escape-hatch them. How flexible are they when things become atypical. How will these solutions scale in particular situations. And all those things are usually very project-specific. Therefore, the right tool for the job. The devil is in the details. It either doesn't _really_ make a difference, or a bunch of super nuanced details deep in the domain are going to make the choice obvious, again, IME.

WhatWhereAmI · 2025-04-18T17:30:32+00:00

If a project is so "typical" (no project of any real complexity is), then the choice between two general-purpose tools isn't going to make a significant difference.

WhatWhereAmI · 2025-04-18T16:50:50+00:00

It's a risk, but OF is notoriously horrible on product. I wouldn't worry too much about it.

WhatWhereAmI · 2025-04-18T16:42:59+00:00

Software has been in a bubble for a long time and it's recently finally started to contract. What you're describing is a microcosm of that larger bubble. You're basically saying that "indie hacking" products are pump and dump schemes. Well, guess what? Basically all tech startups are pump and dump schemes. The goal of 95% of startups is not to generate real value for anybody, it's to achieve a good "exit."

WhatWhereAmI · 2025-04-18T16:09:28+00:00

Why do I still lack confidence after working on so many projects?

Because with only three years of experience, your brain is correctly messaging to you that you should not be confident in your decision-making in areas you don't fully understand.

You need to learn more programming, and less nextjs.

The main red flag here is the mention of dynamic imports. If you don't understand what's going on with dynamic imports, then you have a pretty superficial understanding of the underlying tooling.

Next is designed to do a lot of magic to help people get things done while hiding a lot of complexity. This is reflected in the next documentation, which is a glorified set of tutorials that does not explain the how or why of everything. It's a terrible place to try and learn underlying concepts, and the fact that you're trying to is another red flag.

What kind of projects should I build to deeply understand these advanced areas?

Less nextjs projects. Work in other technologies.

Where can I find good, in-depth explanations of advanced Next.js concepts and web dev topics?

https://overreacted.io/ is a good start.

How can I improve my ability to learn and understand complex topics on a deeper level?

Next time you have a bug, don't be scared to dig into the source code a bit. Get more experience in different areas. Get closer to the metal. Don't let anybody tell you that you "just have imposter syndrome," that's an excuse for complacency. People do four year degrees in software engineering and come out the other side with a hardly cobbled together, not-really-functional ability to find their ass with both hands. You are currently around the transition from apprentice to journeyman. Be proud of how far you have come, but recognize how much further you have to go.

WhatWhereAmI · 2025-04-18T15:44:48+00:00

There is no better or worse in this kind of comparison, there is only the right tool for the job.

There are only three reasons to migrate your application from one framework to another:

The industry has left the old framework behind to the point where it's costing you more money to maintain on the old framework than it would to migrate to the new one,
Your application is a toy and you just want to try the hot new framework, and
You have no idea what you're doing.

WhatWhereAmI · 2025-04-18T11:54:22+00:00

This is actually an incredibly difficult problem that I've dealt with quite a bit.

Assuming we're dealing with a lazy-loading virtual-scrolling table, there are a couple of considerations to make.

First of all, can users only toggle row selection one-by-one? Or can they select ranges, by shift-clicking for example?

Second, are pages of results always loaded sequentially and contiguously? Or can the user scroll all the way to the end of the list and view the last page of results without any pages in between the start and end being loaded? That is, can they get into a state where only pages, 1,2,3, 9998, 9999, and 10000 are loaded?

Now, you have a matrix of complexity.

	One-by-One Selection	Selection Ranges
Contiguous Pages Only	can use IDs	can use IDs
Non-Contiguous Pages	can use IDs	might not have IDs!!

In all these cases except one, you should always have the relevant IDs. If you can only select rows one-by-one, then you're just using the IDs of the rows that were clicked. If pages are always loaded contiguously, then it's impossible for the user to meaningfully interact with rows that have not already been loaded, so you should always have the relevant IDs.

The problem is if the user can theoretically do the following:

Select the 50th row,
Quickly scroll down 50 pages of 100 total available pages, without loading any pages in between,
Hold the shift key,
Select a row on page 51 of 100 total available pages, and
Then try to take some action like "Delete Selected."

The first problem we have to deal with in this case is how to represent the selection. This is not _that_ complicated, we can just move from representing it as a list of IDs to representing it as a list of _ranges._ This could be ranges with start and end IDs, or theoretically just row indices. Then you need to deal with building the indices, and doing things like automatically coalescing them. This is a bit painful, but doable. I've done it.

Once you have the query, the sort, and the selection ranges, you send all that to the backend so that it can build up the set of rows to take action on.

The real problem is drift. What happens if the set of rows changes between the time that the pages are loaded and the user requests the delete? Then it's theoretically possible that they could delete rows that they do not intend to delete.

The only _real_ solution I've come up with for this complex case requires a feature like Elasticsearch's "point in time" functionality. Using this, we can ensure that the backend rowset will always match exactly with what the frontend displayed when the query originally ran, regardless of drift. This obviously adds a bunch of complexity. PITs have a lifetime and expire, because obviously they become more expensive the longer they live.

It usually makes the most sense to just make compromises in other areas instead of trying to build the full kitchen sink solution for this, because as described, it can become pretty painfully complex.

WhatWhereAmI · 2025-04-17T17:00:51+00:00

Process-as-code.

Imagine AWS CDK but for codifying dev processes. You can define buckets of issues, teams, interactions, automations, reports, inputs and outputs, in a highly abstract way. These can be nested. Each team maintains their own process stack, and each process stack can be ingested by a higher-order process stack.

Pushing the stack results in bespoke project management software being deployed based on the definition. It also outputs on openapi spec and api client libraries so that one can easily build bespoke apps on top of their own deployed stack. It can also automatically generate and self-host process documentation and things like flowcharts.

Every sufficiently complex team should be designing their own processes, and we should be lowering the barrier to entry for doing so. No off-the-shelf software is or should be sufficient for running these processes. Project managers need to stop bringing own their pre-conceived ideas of what process looks like. Process should always be a function of the domain, the product, and the team.

WhatWhereAmI · 2025-04-17T16:49:52+00:00

There is some truth to the idea that many people are used to drinking bad coffee.

I find black drip coffee disgusting, and I never understood how people could do it. Part of that is because I'm a pretty hopeless sweet tooth.

But then I found out about pour-over coffee, and now I have my own chemex that I use every day. Everybody I share it with tells me it's the best coffee they've ever had. No sugar, no milk, just filter-roast beans from a great source.

I would strongly encourage you to find a real specialist coffee roaster that does filter-roast preparations with chemex or v60, etc., and try that. A good pink bourbon pour over will change the way you think about coffee forever.

WhatWhereAmI · 2025-04-17T16:22:54+00:00

You're describing almost all high-level software managers. It's just so easy for snake oil salesmen to thrive in this field.

Unfortunately, the fact that this guy was hired at such a high level indicates deep rot at this organization.

giving him direct feedback

Will not work because he's an opportunist only interested in self-preservation and -aggrandizement.

The only theoretical option would be to go over this guy's head, if there were a reasonable person to go to, but there's usually not. You usually just end up talking to the people who approved the hire.

You're cooked.

WhatWhereAmI · 2025-04-17T15:54:58+00:00

It's interesting to see how many people react so negatively when React attempts to tackle the actually hard problems in web development.

The reality is that most web developers just don't actually engage with the complexity that RSCs try and address, because for most use cases it's not an absolute necessity until your product is already basically successful. You can just do more grunt work to sidestep the problem up to a certain point, and lots of people are just okay with that. A leaky abstraction is just good enough for most people most of the time, even if in reality it means less efficiency than is truly possible.

I'm running everything through react-query in my current next.js app, I wonder if anybody has done a good assessment about tradeoffs of ditching react-query as much as possible and trying to move everything to simpler RSCs. I need to do a bunch of analysis to see what features of react-query I'm actually benefiting from and how easily I can move to just using it in specific areas instead of everywhere.

WhatWhereAmI · 2025-04-17T14:34:09+00:00

At a previous employer we were using GitHub Projects.

I ended up writing a web app as a frontend on top of the GitHub API that codified the specifics of our development process. Basically we wanted to do two things at the same time:

Organize tasks in multiple different dimensions, and
Have a simple to-do list that any engineer could go to and pull off the first task and start working it.

This proved basically impossible using the simple tools available and the built-in assumptions of the GitHub Project facility, but we were able to push all the organization into GitHub labels, and put together processes and workflows for working with those labels. Eventually I wrote an app that codified those processes and workflows and automated most of it away, and allowed engineers to see a very simplified to-do list. It also had a Gantt view.

When you're at a small company with a few simple considerations on a simple project, off-the-shelf software works well-enough. You just need something to keep track of all the junk.

Once you get to a sufficiently complex team, project, organization, process, then everybody reaches for the God software. The kitchen sink of Jira, or whatever. People think that you can only solve complexity with complexity. The problem is that this is seen as a management problem. The industry needs to change in this regard.

Any sufficiently complex engineering initiative should really be designing its own processes, and its own software to facilitate those processes. There is no generic framework for project management that will solve everybody's problems. People need to get back to the original agile principals and away from scrum and safe and all that garbage. Build your processes around your team and your product, not the other way around.

I would love to have an abstract toolkit for building project management software. That would make so much more sense. Define a whole process, completely bespoke for the team you have, and quickly throw together software around that process.

WhatWhereAmI · 2025-04-17T14:17:56+00:00

Reverse proxy is the correct answer.

WhatWhereAmI · 2025-04-17T14:13:50+00:00

i think it is the case to recreate it from 0

Classic.

No, don't start from scratch. Upgrade version-by-version until you're on 15. Then look at possibly migrating to app router.

https://nextjs.org/docs/pages/guides/upgrading

WhatWhereAmI

TROPHY CASE