hakunin

I was always curious, why would anyone believe that hard work leads to economic gains in the first place? That's like saying "flapping your hands very fast leads to building a house". Nothing about working hard has anything to do with economic gains. This has always felt to me like magical thinking: if I check certain boxes, I'm automatically entitled to "hard work funds" allocated to me. Like anything in capitalist market, the only thing that matters is what people want to pay for, and doing that for them. It's not even that important how "hard" you "work" doing it, but yes, the more you do of what people want, the more you'll probably get paid for it.

Part of the issue is that when you're young, the school really imposes lots of schoolwork on you, that you can't ignore. It's like school takes over your time, but none of the liability for whether the time will be well-spent. And at this point you don't have good foresight to know the difference.

The more general wisdom I think that should be learned early in life: you always make your own path. Schools are tools for getting there, but the buck stops with you. If you decide to accept a "pre-made path" given to you by a school, you still have to be the one researching whether it makes sense and signing off on it. Just like when you work with doctors, financial advisors, or other contractors, you have to be the project manager of your life's project. Cannot delegate this part. Not easy to learn early unfortunately, but at least start with the understanding that the only thing that matters for economic gains is doing what people want to pay for.

Yeah, this does require a certain team culture building effort. Just starting cold without any expectation-setting might not be received well.

One "rule" I try to meta-promote is — working code is the first step, and a great foundation to then proceed to clear and maintainable code.

Another, is that code reviews are first-class citizens deserving mindfulness.

Yeah, not easy, but it helps to build some rapport first, so people learn what you’re after. The way I tend to do that is by leaving a review comment with an example code snippet that makes me understand it better, and a question “what do you think about this version? I tried to clarify a few things here.”. + Explain what was clarified. I find the effort usually pays off.

Agreed, I wrote more in depth about it a few years ago: https://max.engineer/maintainable-code

I found this type of approach (where you try to meet subjective readability goals with objective/statistical metrics) to not produce clear code in practice. Instead, I suggest this one weird trick: if your colleagues are confused in code review, then rewrite and comment the code until they aren't confused anymore. Don't just explain it to them ad-hoc, make the code+comments become the explanation. There is no better linter than subjective reading by your colleagues. Nothing else works nearly as well. Optimize to your team's understanding, that's it. Somehow, this tends to keep working great even as the team changes.

I grew to believe that feelings have hard-to-recognize rationales that can be explained if you dig deep enough. Very few people ever do however. Recognizing the rationale is a great skill to have in many circumstances where you give feedback, like code reviews for example. It's also a skill that makes you a better teacher.

Not the commenter, but also had experience with making music and writing software. I think the same applies to any creative endeavor. It’s super hard to consume what you produce as “someone else” (I.e. read what you write, listen to what you compose with fresh perspective). Usually it takes time to forget and disassociate from your work, because you get too used to it while producing it. Coming back to it another day can work sometimes, but very quickly you’ll get used to it again. I think this is one of the most effective ways to achieve quality tasteful results in anything. If you can train yourself to read your own code with fresh eyes almost as soon as you write it, you’d be unlocking a powerful shortcut, a cheat code to life. It’ll make the biggest impact on your code’s (and any other creative work’s) quality. This is also why sometimes you can spend hours painstakingly trying to design something, and it comes out terrible, nobody likes it. And you can do something in 20 minutes just improvising your way through, and it comes out an elegant masterpiece. That’s because you never gave yourself time to “get used to” your work such that you couldn’t perceive the problems with it anymore. You maintained that fresh impatient perspective the entire time.

This is anecdotal, but one thing I do when comparing languages and frameworks, is browse the most popular libraries on GitHub from that ecosystem, and see how much maintenance they're getting. I usually use the contributors graph, as well as review how/when issues are handled. Ruby projects seem to have the most contributors maintaining the "deepest" libraries of any ecosystem I've seen, consistently, for the longest time. In other ecosystems I keep seeing one guy trickle-maintain some massively popular (based on stars) project that fizzled out over time. You could argue that some of that is due to "completeness", but I keep seeing evidence to the contrary: still many unsolved issues, but the initial activity spike subsides down to a trickle. To me that's what represents the health of an ecosystem: not how many new projects are created, but rather how well supported existing projects are.

Maybe you're right today, but I'm making an argument against the AI "endgame", not its current iteration.

Solution: update to Sequoia 15.6 (which comes with Safari 18.6) and it works.

Weird, it's installed but it won't let me enable it in Safari. The "enable" checkbox is inactive. Safari 18.5 on MacOS Sequoia 15.5. Restarting the browser, and reinstalling the extension has no effect.

My entire (decades) career I worked primarily in small start up teams, and even when people didn't see eye to eye, they always maintained these kinds of basic practices. I think a lot of disagreement on these expectations is rooted in the size and "tight-knit"ness of your team.

I can think of reasons for this (e.g. storing date/time as it was originally represented 100, 1000 years ago in a historical context vs storing live time for present-day time calculations vs storing non-timezone time for, say, operating hours relative to subject's location), so this statement alone doesn't show fault.

Good old cucumber. I remember a discussion over coffee with someone who swore by it back in the day (~2010). They forced customers to sit down and write these things together side by side. Kind of cringe in retrospect. Wonder what happened to them.

Business people don't really care about this stuff. Over the years I realize more and more that we engineers are naive in thinking that business side is concerned with edge cases and race conditions.

Just to give an analogy software people might get better, if you come to a lawyer because, say, you want to buy a house, you are not going to sit down with them and say "given I want to buy a house, when the seller hides water damage costing over $2000, I get to walk away from the deal". You just hope the lawyer is good and will protect you from various edge cases. You have a lot more to deal with than just closing paperwork. You probably are thinking about renovating, moving, getting inspection, etc.

Businesses are just like that with engineering. They don't want to sit down and meticulously analyze every possible edge case. They have other things to do. Especially when stakes are not that high. Most of these errors can probably be resolved with a phone call and a database edit.

I think this is probably for the best. A good engineer will make sure you're standing on a solid ground, and ask the right questions at the right time. They wouldn't need this amount of hand holding. Leave business time to focus on making deals, connections, organizing the whole operation to move forward, etc. Let them give you vague requirements, and crystallize them yourself. It's way better than a micro-managing business that thinks they know exactly how everything should be.

P.S. Also, I'm not sure why everyone is so hung up on regex = bad, it's not like switching to an AST-based language would've made anything better here. Regex is fine imo, just the entire concept isn't.

This can apply to anything. Why care about how well a shovel is built if all you care about is a hole in the ground. Why care about the quality of the hole in the ground if all you need is laying foundation that can hold a house… Why care about a neat kitchen, if all you care about is a cooked dish. At every layer there are multiple sets of end users. Code is used by programmers and businesses as the source of truth and automation. Just like shovels are used by people who dig with them, not just customers who need holes.

If your point is nobody will ever need to read the code, there's a reason why truly self-driving cars aren't happening yet. We will need human intervention as a failsafe, probably for a while. And humans have been known to care deeply about way lesser things than reducing friction for handling a failure contingency.

It's not about solving puzzles for us, craft-focused developers. It's about caring about the clarity of our writing, for the same reason a writer wouldn't want an AI agent writing their book.

Sounds very interesting, and at first I thought maybe you're an outlier, but the more I read people mention "solving puzzles", the more I notice a more fundamental difference in enjoying programming. For me it's not solving puzzles, but rather finding elegant/eloquent expression of something complex (feel like I'm more of a writer than an engineer). That's what makes me tick: clear code that can itself serve as a primary source of knowledge of how a business functions. If I work with an AI agent, I become an editor rather than a writer — a very different job.

I guess there are some who would've enjoyed coding, but circumstances pulled them away from it. The word "intimacy" comes to mind. If you lose intimate relationship with code writing (or never gain one), you will be more okay with AI.

Perhaps I'm trying to point out that sometimes you lose it accidentally, while still instinctively thinking that you enjoy writing code.

You're probably right, but this dividing line only became prominent now that AI coding agents polarized the community across it. This in itself is interesting to me.

I love experiences folks shared in response to this. Makes me realize that there are many significant factors that influence how people see programming. My own experience for most years has been a combination of the joy of clear/convincing writing with the joy of a high level ergonomic language (Ruby) to express the code. In Ruby and its frameworks, you almost never write boilerplate, so everything is the interesting part. And the surest way to have good understanding of the code is to type it out. (That's why most books ask you to manually type the example code). Figured I'd share my experience too.

Couple of questions: the most senior people in your personal network — are they hands-on _lately_? And are they ~>25y experience? If it's a no to either, I took those into account.

We are in a similar length of experience, but weirdly as I got older, it's the opposite for me: I got more particular about clarity, readability, especially in the context of handling edge cases. The 10% of situations that require 90% of effort. My new hobby is a codebase that can read as a business rulebook.

I was going to include "people who use verbose programming languages/environments" :), but perhaps it's more of a likelihood scale across all groups. The more verbose the language, the more drawn to AI you will be.

That's what I mean by product-building vs programming (3rd group).

I haven't seen many folks who actually hands-on programmed this long willingly and grown to hate it. Instead one is usually trying to become something else (CTO, executive, etc) but due to financial difficulties, struggle to make connections and promote themselves, had to keep writing code. Are you sure this wasn't more of your case? That said, I haven't programmed for 35 years yet (approaching 30 in my case), so I don't know how I might feel when I get there.

I've been noticing the pattern among the kind of people who like/dislike AI/agentic coding:

1) people who haven't programmed in a while for whatever reason (became executives, took a break from the industry, etc)

2) people who started programming in the last 15 or so years, which also corresponds with the time when programming became a desirable career for money/lifestyle/prestige (chosen out of not knowing what they want, rather than knowing)

3) people who never cared for programming itself, more into product-building

To make the distinction clear, here are example groups unlikely to like AI dev:

1) people who programmed for ~25 years (to this day)

2) people who genuinely enjoy the process of programming (regardless of when they started)

I'm not sure if I'm correct in this observation, and I'm not impugning anyone in the first groups.

100% agree, esp. on the soundtrack. I thought I was going crazy when in Witcher 3's Skellige island it started playing the soundtrack from HOMM4. (See Track 14 here: https://youtu.be/F9sG0r_9f4M?t=4400).

> Personally - if I really want to be fast and efficient I'm not picking Ruby anyways (or python for that matter - but at least python has the huge ecosystem for the LLM/AI space right now

"Fast and efficient" can mean almost anything. You can be fast and efficient in Ruby at handling thousands of concurrent llm chats (or other IO-bound work), as per the article. You can also be fast and efficient at CPU-bound work (it's possible to enjoy Ruby while keeping in mind how it will translate into C). You probably cannot be fast and efficient at micro-managing memory allocations in Ruby. If you're ok to brush ruby aside over a vague generalization, maybe you just don't see its appeal in the first place, which is fair, but that makes the other reasons you provide kind of moot.

Gotta give credit for wonderfully clear writing. You can tell a person understands what they're saying by how well they express it. Reads smooth, and makes me see the author's mental model.

As far as substance: I love ruby libraries that allow you to simply "insert any ruby code". Many libraries tell you to call specific declarative functions, but I think Ruby shines at letting you use Ruby, instead of some limited subset of it. Examples of not-great approaches (imo) are libraries that try to take over how you write code, and give you a special declarative syntax for runtime type checking, building services out of lambdas, composing functions. Ruby's async is an example of "just insert any ruby in here". You can build runtime type checking the same way — allow people to check the value with any ruby code they like. Essentially, I agree with author's sentiment, and wish more people appreciated the beauty of this approach.

I don't honestly know why most people do code reviews, because it's often presented as some kind of "quick sanity check" or "plz approve". Here's why we do code reviews where I get to lead the practice:

1. Collaborate asynchronously on architectural approach: (simplify, avoid wheel reinvention)

2. Ask "why" questions, document answers in commits and/or comments to increase understanding

3. Share knowledge

4. Bonus: find issues/errors

There are other benefits, like building rapport, getting some recognition for especially great code.

To me code reviews are supposed to be a calm process that takes time, not a hurdle to quickly kick out of the way. Many disagree with me however, but I'm not sure what the alternative is.

Edit: people tend to say reviews are for "bug finding" and "verifying requirements". I think that's at best a bonus side effect, that's too much to ask a person merely reading the code. In my case, code reviews don't go beyond reading the code (albeit deeply, carefully). We do however have QA that is more suited for verifying overall functionality.