hakunin

It's really hard to be a good architect, because their job is not supposed to be to leave their mark. An architect is doing a great job when the codebase is boring, and everybody talks about business. That doesn't help the architect however, because people can't tell how it would've been had they not been there. "Our codebase is so simple and boring, why do we even need an architect". That's how you get the kind of architects that try to look impressive to the management.

There are a few things a business can do to get a good kind of architect.

1. Hire them to be hands on with code (give them secondary features or refactors, not major lifts, since shipping speed is not the priority). 2. Don't give them authority over devs, rather ask them to provide mentorship and demos. Their job is to excite devs about a clearly better approach, not to force their opinion. 3. Encourage devs to come to the architect for advice as needed. 4. Have the architect organize long term refactors[1] when needed.

Basically make them a developer whose audience is other developers, and the product of their work is developer buy-in/excitement over good practices and software design directions.

[1]: https://max.engineer/long-term-refactors

I agree that this article is just a naive conversation trigger, and that complex front-ends will lead you down this path.

However, there's another path, which is where you keep things on the backend. Unless you're talking about very complex interactive experiences, the amount of front-end code can go from >100% of the backend code, to <5-10%. Backend always implements almost everything anyway, and the question is how much should front-end reimplement on their side too.

Every time I push for smaller front-end, I'm faced with how the team might get bored or not have enough to show on the resume.

Ruby can parse itself, it has test coverage, vulnerability auditing, SQL auditing, static and runtime analysis and type enforcing tools…

Rails has an incredibly convenient REPL that's built into every dev error page, a one-line integration with every error, analytics, and log-tracking service under the sun, that will give you all of the insight into production runtime for basically zero effort.

You install Sidekiq or GoodJob in a couple of lines of code, and suddenly you have the entire background job system to tap into for any delayed or periodic workflows that can be offloaded, bundled with monitoring and administration UI.

All you need to do is learn how to do software design, but even there Rails starts you off with arguably the best design decisions you can make at early stage: focus on your entry points (controller actions for requests, rake tasks for CLI), and start extracting domain objects as you learn more about your domain.

Am I missing something? Where's the "hostility to tooling"?

In our current project it's Stimulus/Turbo on the admin side (maintained by the backend devs), React on the end-user side (maintained by the front-end devs). I haven't met a single front-end dev who prefers the Rails approach. Even after trying to do some light convincing and demoing. They seem to be too committed to the React ecosystem in my experience. I can respect that, too much has been built for it already, and it's generally in high demand.

Plus, Rails story has no clear JSON boundary between back and front, which creates some discomfort (i.e. learning erb) as well. As a backend dev, I'm all-in on Rails in solo projects.

I think the post is making a poorly-worded switch to talking about fragmentation in backend node packages.

There's a bit of conflation between easy and simple here. Cloud is easy-ish, but it's not simple due to the proprietary abstractions you aren't meant to access. If things go wrong, you can't investigate past a certain point. Granted, clouds go to great lengths to make their own failures auto-handled for you, but that actually increases complexity in order to remain easy.

Running your own machine is definitely simpler because you can debug a problem all the way down to bare metal. Not easier, but simpler.

That said, the more I do this stuff, the more I want simple, not easy. Easy is good when you're on the happy path, but as soon as something goes wrong, you wish it was simple instead.

In an ideal world, all the guts are exposed, but in the clearest, most organized way possible, where you always have an option to go one level deeper if you want. This would be great to have in both software interfaces and software design (code).

Covid virus during pregnancy increases risk of bad outcomes dramatically, but a lot of patients have the wrong (reverse) idea, and therefore refuse the vaccine. Refusing the vaccine is probably a contributing factor. (Source: wife is OB).

I've written up some rules that I've successfully applied in my teams. https://max.engineer/mindful-code-reviews

Couple of points on this.

1. A lot of problems arise from too few people working on too many things. If it's one-two devs and backlog is growing, the problem is not that you have no time to fix things, but that you're understaffed. If you have enough people, then from the business perspective it shouldn't even be that noticeable that someone is refining previous work, while someone else is building the next thing.

2. If you're not understaffed, then the best time to clean up new code is during or immediately after writing it. A phrase I like to use is "while it's still fresh in memory". You're saving time and not adding new bugs, by not having to remember everything again, load all that context back into your head.

The problem here is not that developers are too busy, but that code reviews are considered second class citizens to churning out new code. It's like saying "many devs are super busy working on feature A so they just write quick and dirty code for feature B". If reviews are integral part of feature production pipeline, there should be no issue to sit down and spend a day reviewing code. For bigger, more complex things it could be a few rounds of reviews.

There is an approximate non linear relationship between time it takes to produce the first PR and time it takes to go through all rounds of review. This time can be pretty reliably calculated and taken into account.

The worst use of analogy in my view is to use it not for improving understanding, but for morally loading the subject with the baggage from the analogy. When you say that data is like organs, you are morally loading all of our worst perceptions on what organ trade can be (harvesting, trafficking, and exploitation crimes) onto data. Data resale is serious for different reasons, and trying to morally load it with organ considerations is obfuscating those reasons. We should instead understand those reasons for data itself.

I've been using History Book app[1] (only on Apple ecosystem). The search is starting to slow down at 25k pages, hoping it can hold up.

[1]: https://apps.apple.com/us/app/history-book-browse-search/id1...

Did the repetition become obvious before or after you saw both implementations? It’s possible that if you dried it up right away, you would’ve abstracted the wrong thing, and it’s way more obvious only in hindsight.

Yes, but his law is descriptive, not prescriptive. Just because it tends to happen doesn't mean it should happen, or happens for good reasons.

This is good sometimes, other times it risks losing the audience. Extra info works better when they're ready (i.e. asked for it). This is why it's such a difficult balancing act. You don't want to preemptively answer questions that people didn't realize they should ask yet.

One of the problems I often see is that when trying to explain one of the possible options, people don't understand it. When that happens, you try to explain it to them harder. Your explanation is then mistaken for pushing for that option. It's important to carefully navigate around this perception. People should understand that first you just want to be on the same page what your options are, and then discuss the best one.

Trying to solve a communication problem with more code and infra is often a mistake. This is something many engineers don't realize they're essentially doing. Some communication problems can be somewhat alleviated by processes and technology enforcing those processes, but you must always consider the cost, and weigh it against alternatives that don't require engineering overhead. In almost every case like this, increasing the amount of code and infrastructure is the wrong option.

I think not getting hung up on a method to solving a problem is a great message to remember. You should be open to switch to a different method if it solves the problem better.

Type safety is just one such method. The actual problem is making code easier to maintain for humans. Type safety is not always the best means to that end. Our brains perceive information in a complicated way. Sometimes too much information can overwhelm us and obfuscate something simple. Sometimes too much detail about each value can make us lose the overall flow of the program.

My advice: (aside from reading other people's code) try to read what you wrote, and have others read what you wrote in code reviews. Do you and your colleagues understand it? Make it as brief and simple as possible without losing that understanding. Address any "how" questions by rewriting the code clearer, "what" questions by improving naming, and "why" questions by adding comments. These are your code's 3 primary objectives: explaining how, what, and why to your colleagues. I once wrote a post about it.[1]

[1]: https://max.engineer/maintainable-code

I agree that if you make a very complex query in ActiveRecord, it could eat a lot of resources.

That said, I would highly recommend going with raw queries for this sort of complexity, no matter the language. There are usually 2 kinds of queries: normal ORM-powered CRUD operations (which can get moderately complex), and hairy specialized report-style calculations. The latter I always recommend to keep in raw, well-written, well-commented SQL form. You can still wrap it into some nice object.

You could write them in something efficient like Jet or Elixir's Ecto, but for such a complex case I'd argue that you shouldn't obfuscate SQL at all. For all other cases ActiveRecord works well.

If you are serving these results in real time, something like materialized views (in postgres) would move the burden of calculation to when data changes, rather than when data is viewed.

And to tie it back to the original convo: a very efficient concurrent language doesn't solve these root causes, rather gives you more time not to address them, and allows you to get away with more neglect. There's some value in that, but you have to weigh it against the downsides mentioned in previous comments. If the language+framework is super efficient and has no downsides to its ecosystem and ergonomics, then there's no debate, I'd just use that.

A internal network boundary is probably worth it for heavy jobs, since you usually don't want it to interfere with serving web requests (no matter the tech).

You probably already know what I would say to each of those examples.

> Rails timing out after 30s while allocating 500MB of memory (mostly) in ActiveRecord to compute 5MB of JSON to return to an API caller.

I can make a JS or Go program perform the same way. In fact the exact same thing happened in my shop with Go/Gorm. The key question is: how do you compute the 5mb of JSON? The devil is in those details. We changed the way we computed ours, and the issue was gone.

> 90% of request latency of ~10s spent waiting for downstream services to respond to requests. Most of these could be fired off concurrently (ie `Promise.all` in node). 9s/10s this Rails worker is sitting around doing nothing and eating up ~300MB of memory.

This sounds broken. Why is the worker doing nothing for 9 out of 10s? But like I said earlier, there are a bunch of ways to use HTTP1.1 pipelining to run them concurrently. (https://github.com/excon/excon and https://github.com/HoneyryderChuck/httpx support it, but you can also do that with Net::HTTP I believe) And you can still start threads, which are still concurrent while blocking on IO.

> trying to extract out Authorization to a centralized service (so that other extracted services don't have to call into the monolith in order to make authorization decisions) is a major pain as the monolith now has to make calls out to the centralized auth system to in order to make authz decisions.

This seems unrelated to Rails. Not sure why monolith can't continue handling authorization.

You're saying that NodeJS monolith comes with no downsides compared to Rails at early stages. We disagree here.

From my brief surveys, nodejs ecosystem comes with less security out of the box, less standardized project structures, fewer thoroughly-designed and supported packages (vs cutting edge experiments), more complex upgrade paths, more projects getting abandoned, all of which can slow you down every day. Friction from these can be deadly.

On the other hand, being in the corner at scale doesn't force you to rewrite everything. Just the piece that put you there. You can leave Rails app to handle most things, and extract parts of specialized infra as needed.

Would be curious to look at specifics — what kind of pains your company is experiencing with Rails today.

I understand your general point, but these solutions are not niche. They cover almost everything needed in web dev. The niche problems are the ones that arise at scale, which is when a business typically has the resources to solve them. (Hint: you don't have to solve them in Rails).

Large app / company challenges don't apply to new apps. Statements like "I wouldn't start a new app without a great concurrency story." or "I wouldn't start a new app without microservices." etc don't make sense, because new apps have different priorities (i.e. finding the fit, surviving, staying relevant).

I went through a phase of building Elixir/Phoenix apps for 3 years, thinking that I will switch permanently, but ended up coming back to Rails due to higher productivity in that stack. This was in 2015-2018, so maybe Elixir/Phoenix has gotten more ergonomic since. I'm not sure.

Http clients have pipelining for parallel requests that doesn't require threads. Database calls in Rails 7 now have `load_async`. You can still have other services, outside of Rails. Would that cover it?

P.S. I'm a huge fan of Elixir/Phoenix, but didn't find the big need for concurrency in practice that Rails doesn't address somehow.

Just out of curiosity, what are you doing with a great concurrency story in a company you start in 2024?

One strong point for productivity/getting stuff done fast in real world: good REPL. It's not just Rails of course, but worth noting when comparing interpreted languages to compiled ones. Rails console is not only a great development tool, it's also an invaluable way to tackle customer support problems quickly.

There formed a subculture inside Ruby community, of people who love code that is as structured and declarative as possible, with an abstraction over anything that has a name, and a hierarchy of namespaces that map onto paths or grouping of similar things, rather than parts of a module or a library. There are many examples of libs like these out there (I won't name names). For example, libraries that let you write "service objects" declaratively with some block/lambda trickery.

I find this to be a fun way to play with and explore Ruby, but once it comes to building stuff for production, I encourage to take a bunch of steps back and rethink what is really being gained. Many of these libraries end up turning Ruby almost unrecognizable. And the fact is that if you sit down and try to rewrite the same thing into plain imperative ruby, you'd lose nothing (it won't even be longer), but you'd gain clarity and maintainability, because code becomes simple and obvious. I know this because I've done all of the above in the past, and it humbled me a number of times. I wish more people were trying to do this exercise of ruthlessly comparing their lib's solution to the same thing done in plain ruby. It may feel bad at first because it bursts the bubble of excitement one may've inflated while building a lib. But then I find it actually makes you more excited about Ruby again.

I haven't personally used Hanami, been following it from a distance, and I might be wrong in this impression, but I found it to be leaning a little too hard into the camp described above. That said, performance gains are certainly welcome.

> I used to be a Rails developer, but I'd never start a new Rails project today. Frontend frameworks and serverless backends have made Rails obsolete.

Feels like a bold conclusion to make based on a trend, when there are so many other explanations. If Rails is no longer in the hype cycle, but still is a superior solution, does that make it obsolete? If Rails shops generally have smaller teams, does that make them obsolete? Why did the author choose that one explanation?

I'm on Safari on MacOS with AdGuard and StopTheMadness. Nothing seems to have autoplayed.

I've been contemplating the issue in the headline, as pertains to my value. When I help somebody in 40 mins with something they've been stuck on for 3 months, my value is clear to everyone. When I work there the whole time, and nobody ever gets stuck for 3 months, my value is unclear. Don't know how to deal with this paradox.

Zed is a great contender for Ruby. I'm considering it, coming from Sublime Text, only needs a few small additions. Much better first impressions than VSCode.