hakunin

I don't think I ever try to verify the correctness of the code in code review. That seems hopeless to me. The original developer should be assumed to produce working code, which is covered with tests and maybe will go through QA (if you have that). Of course there are occasional bugs you can spot, but the main goal is to review the architectural approach and code clarity. You can also note if something isn't properly covered with tests. If you managed to make any security, performance, or edge case handing suggestions, that's a nice bonus.

Maybe we're in a very different context, but to me if you can't understand what the code does without a debugger, then you ask the author to make the code clearer.

I think relying on your judgement of character to determine trust is a decent tactic in personal life and interactions, but it doesn't work at scale.

People place trust in faceless institutions all the time. That's why you sit in a box that produces about 50 explosions per second when you drive a car. I don't think you would've gained much by being comfortable with the character of your car designer. If you think building cars is complex, laws and regulations are just as complex. And it takes teams of lawyers, hundreds of pages of documents, and a lot of data to figure out what makes sense. But it's easy to armchair-judge all of that as "just some faceless institution".

> what forces exist to prevent them from being corrupted?

Why are you right now not stealing from your work, or vulnerable people around you? Why are you not trying to screw over everybody you meet? Those forces and more. There's a lot of scrutiny built into most institutions.

> the growing cynicism in institutions is because of evidence of corruption

I don't think we use the word "evidence" the same way. Having perverse incentives is not evidence.

That feeling you just expressed of higher trust to your local doctor than to a head of a large institution: it came from having a pretty good idea what your local doctor does, and no idea what a head of an institution does. The growing problem with cynicism in our society is not because there's evidence of corruption, it's because nobody knows how anything works, but everybody gets fed "look at these bad incentives" by pundits (especially alternative media ones) all day. Everything is complex. Just because it is doesn't make it nefarious.

An institution's whole point is to be a system where you don't have to trust individuals. It's a way to deal with complex nature of our reality. People should really learn what institutions are, how they function, what accountability mechanisms they contain, instead of blaming them based on conjecture. "Look, this bad thing happened. And this person has this bad incentive. Now we know the whole story." We don't.

Every single thing in our society has perverse incentives. Every single person who ever sells you something has incentive to sell you as little as possible for as much money as possible. Every single employer has incentive to pay you as little as possible for as much labor as possible. But that's not how things end up happening, because other forces are at play.

People who worked their entire life in an industry and became experts on it, then become regulators for the same industry, have incentives to favor their industry, sure. But who else should be regulating the industry if not the expert in that industry? If you get someone who is not an insider, wouldn't they just fail at regulating, because they have no idea how it works? Also, the people who put someone in that position, isn't there a chain of accountability there? There are many people working side by side with the "evil person trying to enrich themselves". Bad acts come out. Incentives tend to balance each other out. It's not wrong that part of a regulator's job is to find a balance as to not destroy an industry while regulating it.

> I've seen those exact questions in PR templates […] understanding a PR takes time […] when anyone is under any kind of pressure to deliver. […] is this the case frequently enough for the process to have a positive ROI.

Not templates. The culture HAS TO be for everyone to calm down and treat PR reviews as first class citizens, not unwanted distractions. If ya'll stop stressing each other out that reviews are bs, I'm sure they'll stop being that.

> […] we still had, design reviews, white board sessions, code reviews, pairing sessions, planning meetings etc...

You know that feeling when you get a design idea, you start implementing, and a single plot twist makes you realize it doesn't fit? What do you think happens when a white board session bumps against reality? That's likely a session down the drain.

What if we replace it with the following process: 1) Discover all the plot twists up front by writing out the solution. Publish a PR. 2) When a reviewer comes in, give them time to grok it, welcome redesign ideas. 3) Easily assess and validate their ideas using the stupid amounts of expertise you temporarily gained by having written a working solution. 4) Discuss or proceed with fixups.

How can it get more concrete and grounded in reality than this? One of you knows every tree, the other one can still see the forest. I'd argue, you rarely need to talk before this point. This is the best point.

(Obviously you shouldn't just suffer in silence if you're stuck or your diff is getting out of control. Run it by somebody sooner than later.)

> I highly doubt you'd be able to do this outside of a small company, or a small self-contained team.

Thankfully most companies or teams are indeed small.

> 9/10 when people do make those kinds of suggestions it's not objectively better, and 9/10 changing it won't move the needle with respect to maintainability or meaningful performance.

The 9/10 number seems incongruent with my experience, but that could be because I often help set the PR review culture, and encourage people to identify the questions: is it "how" (…is it working), "what" (…is it doing), or "why" (…is it done this way). If you recognize those, it makes it way easier for the author to address the specifics without a total redesign. (How = hard to follow the logic, what = better names needed, why = comments needed).

But sometimes a redesign can be super compelling to everyone, and the question is: do we want to be stuck with the subpar version? Because really, the closer you are to remembering how it all works, the easier it is to rewrite it. Not later, when it faded from memory and overgrew with dependent code.

> Comparing the software we produced before the whole PR review for every merge request thing became common, and the software we produce now, I don't think software quality has improved at all. So for me to change my mind, I'm going to need to see hard data that says the opposite.

The kind of subjective reviews we're discussing (not security, performance, consistency, edge case issues, or major simplifications) are not really about quality, they're about your specific team understanding your specific code. Help your colleagues (just the small circle of maintainers) have more confidence in coming in later to change this code. If you're working alone, this isn't as big an issue.

To collect data on this, you would need to witness what happens when everyone architects their own way, and then you have to find the person who wrote that part to decipher it, and compare the amount of slowdown that can cause. Nearly impossible to measure in practice, I think.

> not everything needs to be asynchronous

I completely agree. PRs provide great tools for discussing code asynchronously so it's good to lean on them sometimes, and discuss the work on a call other times. This is however a big departure from your original statement that PRs are the absolute worst time to review the code.

The biggest issue with PR reviews in my experience is not how long they take, but the justifications people provide for their feedback. I don't think you should ever leave a comment if you don't have a convincing answer to "why" you left it.

The change request must either make the code objectively better (i.e. performance, memory, security, adherence to a consistent architectural pattern, simplification), or subjectively clearer (it's hard for you to understand what is happening, how it happens, or why it's done this way).

If the reason is solid, then the feedback is usually well received. Except in unfortunate environments where PRs are treated as annoying disruptions. I hope I never have to work in that kind of place.

I completely disagree. By writing the code, the author gains understanding of the hidden details of the problem. The reviewer gets to explore a full solution that accounts for those details, and provides tests. With the context still fresh, it's a great time for a new pair of eyes to explore, ask questions (which should lead to clarifications in the code), and think of ways to simplify and untangle the solution further while keeping the tests passing. In fact, it can take more time to keep assuming and discussing what the solution might be than to write the code and iterate on it. In an asynchronous/remote work environment, iterating on PRs is not only okay, but probably the most effective way to collaborate.

It's probably a version of that. But since data is assumed sorted, memory requirements almost never grow beyond one item per stream.

I don’t think that can happen because all those functions assume the streams are consistently sorted.

Lazy enumeration can also save memory, because you aren’t storing entire collections during intermediate steps, and it works with infinite/unknown size collections. Such as streaming data.

Some examples:

I wrote a utility gem a while ago that lets you lazily intersect, union, etc various potentially infinite streams of data. https://github.com/maxim/enum_utils/

I also used lazy enumeration for traversing the wordmap in my no-RAM static storage gem. https://github.com/maxim/wordmap/

I think you don't really know what you want if you don't know why you want it. Learning to understand oneself is a huge part of one's personal growth. When you don't know the "why", it's easy to be mistaken about what you actually want, and push for a superficial projection of it, not the real underlying thing. (And therefore lose out on relationships you didn't know you'd be happy with.) But we speak in generalities of course.

Only issue is that when you get what you want, you might be convincing your partner(s) to settle for something they want less. Perhaps the mindset of "best I can get" and finding an acceptable compromise is the way to go.

Yeah I realized, but preferred to keep my own format.

And here I thought "Yay, I can find more people in my area." Nope, it's just me, like I suspected.

I remember reading this jwz post[1] in 2012 where he said he never uses tabs at all, and realizing that I can use a combination of windows and tabs. So now I just have each window contain a bunch of tabs for one topic. If it's WIP, the window stays open or minimized, if it's a long term thing, I convert it to Safari's tab group. Not sure why more people don't use multiple windows, it's way more convenient than just having hundreds of tabs in one window.

[1]: https://www.jwz.org/blog/2012/04/why-i-use-safari-instead-of...

Weirdly, I like ligatures only in Elixir, and no other language (Ruby, Go, Javascript, etc).

Dupe https://news.ycombinator.com/item?id=42024246

Prospective and retrospective analysis are fundamentally different. It’s easy to point to successes and failures of the past, but that’s not how we predict the concrete future potential of one specific thing.

How do you write a test for code clarity / readability / maintainability?

> You probably went through Ecto 1 -> 2 -> 3 and Phoenix was migrating to contexts.

> But I also have to say there was a lot of FOMO in relation to OTP back then: people felt they had to build these amazing supervision designs, otherwise they were not using the language correctly.

Exactly!

Contexts really threw me off, because I couldn't figure out how/why would I set a boundary up front, if I'm not even sure how the app is going to turn out.

Here’s my anecdote.

I built 3 production projects in elixir around 2015-2018, and it was a blast to learn and work with. Those were interesting projects that were a great fit for the stack. One was March Madness bracket game which required a huge throughput on day one, and another was a football game audience play calling each play from their phone as the team is playing live at the stadium. This one needed a lot of timing coordination and poor connection handling. I even put out an open source fast/customizable leaderboard on top of ETS.

However, I didn’t feel the need for this stack on most projects, and if I’m totally honest, I never got good at the novel way of building applications in it.

While it was very enjoyable, everything felt a little awkward. Even 3 years in I constantly felt that I’m not doing it right, and I’m fighting the language to do data transformations in a purely functional style. I never got used to writing Ecto queries, and always had to look up their syntax. Plus, there didn’t seem to be a good architecture story, just isolated praise of OTP. And Phoenix further fueled the confusion, making it hard to understand whether I’m supposed to reason about my app like a Rails app (just build controllers, models, and views) with no regard for processes, or I should orchestrate some creative supervision trees, that I can’t even tell how they would be arranged in a typical web app. Going back to Ruby on Rails was kind of back to super productive comfort zone after a bit, and I just continued staying there.

I’m still looking back at Elixir with nostalgia, wondering if I’m going to have a chance to go back to it and really make it an extension of my arms/brain like Ruby had become. And whether I can do all that amazing supervision-based architecting I keep theorizing in my mind. I loved Dave Thomas’s vision (and agreed with his controversial takes) and really wished I could get as good as Sasa Juric at really deeply reasoning in this framework. Maybe one day.

I responded to another thread under this comment, but can you give me some examples?

That's not at all my experience. There's a one-line integration between almost everything under the sun and Rails (business/traffic analytics, performance/profilers, error notifications, logging, object storage integration, I could probably go on). Many other frameworks don't even have the general capability of doing one-line integrations.

Correction: you mean 2014, not 2024.

Do you think there is no criteria worth considering besides the size of the hiring pool? What if 2 hiring pools are sufficiently big, do you still pick the bigger one every time?

You vastly underestimate what a 6yo can do. Case in point, one can understand the entire content of a book like Little Prince or Secret Garden, an entire plot of Marvel or Harry Potter movie, build 18+ yo lego sets, and play Theme Hospital and actually win levels. Animal sounds? Don't put speed limits on kids' learning.

Also, how would you listen to VHS tapes?

Having read the article, the team just seems more experienced with frontend than backend dev. As somewhat an old school dev, I've been noticing these small fears and misunderstandings in the way FE devs think. Honestly, I believe it only takes a minor adjustment in thinking to understand how this stuff works, but I get it — many people at this point have never seen regular client/server approach in their entire careers. That said, I get the value of off-the-shelf React components, and ease of finding docs/help, so wouldn't discount that anyway.

This is a good "what not to do". A while ago I wrote a "what to do"[1], which could serve as a good complement to this article.

[1]: https://max.engineer/mindful-code-reviews

To be clear, this is Kamchatka Peninsula by the Pacific Ocean, located in the Ring of Fire[1].

[1]: https://en.wikipedia.org/wiki/Ring_of_Fire

I can't escape Sublime Text's grip. The editor is incredibly smooth and gets out of the way like no other. (Tried a bunch of them). However, lately I started opening Zed on occasion just to ask ChatGPT to make a non-trivial edit on a bunch of code. The way Zed does inline AI assist is unmatched. That's why I can't wait for Sublime to gain this functionality, so that I can calm down and stay with it.