Hacker News Reader

Comment by qwery | Hacker News Reader

I think the disagreement to this generally falls into the trap of taking(rejecting) this advice as a purported unbreakable law. I can't speak for the author, of course, but I think like most (good) advice about how to do a thing (better), it's simply a suggestion that maybe some of the time you should try to be more like this.

YAGNI is a somewhat similar advice, and a good one -- at least for my overengineering inclined brain. But if for every single decision you invoke YAGNI, because overengineering is bad, you can also end up with bad code. Even in that case though, the standard for what is "bad code" depends on context (goals, deadlines, etc.). Even "objectively" bad code might not have a significant impact on the project, again depending on context.

Article is from 2010-12-24, posted a bunch of times. Earliest: https://news.ycombinator.com/item?id=2037576

View on HN

I think the ability to be pragmatic, and make technical decisions with nuance and taking context into consideration is the sign of a quality engineer. _Everything_ is a tradeoff in engineering, and experience simply gives you more signals to know when and which tradeoffs to make.

If one can also be humble, and take other opinions into consideration, then that's someone I enjoy working with. I strive to be this person towards others.

100% agree. And the context is not only what you build but also who you are working with. A team with high turnover to it and a founder with 2-3 engineer should prop have diffrent ways of doing things, and there is a lot of business context that people are missing. A lot of code do not need to scale or be extended and may be thrown away or stopped worker on in just a few years. And we we as a industry's has gone to far in many places thinking about good code. Its highly dependent on the context

The blog is about being a "Recovering Programmer", as in, someone who is trying to cast aside programming as an identity.

And I think all the advice has to be taken through that lens. Of course someone who is in the midst of their programming journey is going to say, "No, I want to do the advanced thing now. I'm advanced."

But if "being a programmer" is a disease one wishes to rid themselves of, then advanced programming is merely advanced disease. And that point is roughly when you start to be able to make the right call when asserting YAGNI, because then you can identify with more clarity when the code deserves to be heavy, load-bearing stuff, and when it needs to be more like "code as an asset" - simple loops and branches that help configure the heavy machinery.

>YAGNI is a somewhat similar advice, and a good one -- at least for my overengineering inclined brain. But if for every single decision you invoke YAGNI, because overengineering is bad, you can also end up with bad code.

Examples?

YAGNI is a very abused term. I tend to find when people talk about exceptions to it theyre talking about things which don't actually fall under the header of preemptive features or preemptive refactoring.

Yes, this! Quite related... I forget where I heard it, but someone said the way you know you're talking to an expert is that their answers to a lot of questions start with "It depends...". Being an expert often comes down to understanding the nuance of when to follow standard practices and when it's better to violate them.

You went through YAGNI. DRY is the same thing. It's often very good advice. But there are certainly limits to DRY... calculating the area of a rectangle from its width and height in two different repositories in the same company probably wouldn't justify creating a library to be shared between them. There's a line somewhere in the middle. Being skilled at understanding what side of that line a given case should fall on is something we build with experience.

I think YAGNI and DRY are at their best as advice when they come packaged together, putting them in tension in order to prompt us to find the right balance and not to blindly follow either one. Taken together, they give us a framework for thinking about one set of tradeoffs. I believe the core of software engineering (and many other pursuits) is identifying the most important tradeoffs and finding a good balance among them. Blindly following advice can get in the way of that.

Reply on news.ycombinator.com