@RhysSullivan The second has too much noise in the API design. Effect, Context, Layer, Layer.effect, Effect.succeed, Effect.gen, Effect.provide etc
The first one really boils down to createContext, useContext and Context.Provider.
@joshmo_dev This is the main thing people are missing. It seems the devs went down a rabbit hole assuming they were initially under attack. Clear telemetry to communicate what assumption had been invalidated (rather than the generic panic message) would have given them direction.
@davefarley77 There seems to be an illusion that gold plating a long lived branch and having that go through multiple quality gates reduces bugs and provides stability. Not in my experience. Small incremental changes back to main reduce risk and increase feedback far better
@TheGingerBill Way easier to glance at this and know what’s going on even when unfamiliar with the language. I also see this problem emerge when people get a bit too clever and write “helper” methods to make the code “cleaner”. But all they do is introduce a new flimsy API to learn
@FatherPhi Not privilege at all IMO. It’s a scale. Better to know up front if you’re expected to work an extra few hours here and there and under what circumstances vs “we always work 12 hour days”
@enunomaduro It’s so easy for verbosity and unnecessary boilerplate to sneak in as well. Sometimes these models remind me of padding essays to reach min word limits.
It’s interesting to go through this experience. Where I might have been a bit more bullish in the past on opinions in code reviews I’m way more chill now.
Flag it and move on. Yes that means some devs will ignore the feedback. But you can nudge them towards thinking on it.
Incredibly strong opinions always receive the most attention on social media, which is a shame. They're the least interesting.
The older you get, the more you realize how important it is to loosen your grip. You have too many "Oh, wow, I was completely wrong about that" moments.
I don’t understand bold statements like “evolve or be left behind”
If AI is truly so great then wouldn’t it be trivial to pickup these tools when needed?
No one will get left behind as the knowledge for using the tools is easily acquirable.
@jamonholmgren You are spot on regarding the constant friction. This is why I hate teams forcing an interface for every single class even though it only ever had one implementation. You will forever hit the tedious minor friction of jumping to the definition rather than the implementation.
@slimjimmy Hate working with these types of devs. Always solving imaginary problems the business doesn’t have. Better off investing that effort building technology that grows the user base so the company has more than 50k requests a day
@Hasen_Judi And you also get these codified into excessive linting rules that actually make code worse. e.g. variable name length can’t be greater than x characters. Method can’t be more than y lines. Where x and y is some arbitrary low number you’ll often hit.
@rickyfm Yeah not a big deal at all. Pretty sure you’ll run into this with say parsers that generate PDFs from HTML as well. Adding an explicit tbody saves on the headaches tbh
@steipete Yes production incidents happen regardless. The point is that when they do, you’re gonna wish you cared about code quality and it being the best it can be to resolve it efficiently and effectively.
Maybe you’d even reduce the blast radius of the incident with the “best” code.
@iannuttall Ok but what if you want to update the app without introducing regressions? Code quality matters on a bunch of dimensions. Maintainability, reliability, scalability etc
@antoniosarosi Yeah people are always scared of “what if we need to add/edit/change this code”. Well when that happens let’s deal with it. Rather than building a random abstraction when there’s 3 lines of code in the function. Co-location is king but they want to split everything up.