Hacker News Reader

To be a good X you must follow the rules. To be a great X you must have followed the rules so well as to learn why they’re there and when they should be broken.

Works for almost any X - writer, programmer, driving, etc.

To be great at X you have to write the rules.

To be legendary at X you must go beyond X and invent Y, by creating a paradigm shift that echoes throughout your field.

Not really, Messi is great at soccer, he didn't write the rules of the game, but he was able to do things with the tools available that no one thought possible. To be great you usually have to be creative.

Messi can teach the ones who teach football. Not the best example. He was doing unbelievable things when he was a literal teenager. A surprisingly better example would be Cristiano Ronaldo. Ronaldo was absolutley frustrating to watch in his early career. It was someone trying hard to do flashy moves without any end product. He needed guidance, rules and structures. He also slowly transitioned from Winger to Forward/Striker. He is immensly talented, but no bigger talent than top talents in every era. Messi is on a different level. He is an all time great. Cristiano achieved what messi achieved because Cristiano is disciplined in a way that noone before is. The guy is 36 now and just topped goal charts in Italy.

I literally have no idea what you mean by 'Messi can teach the ones who teach football' but my comment was not an invitation to discuss who is better. The rules I am talking about are the ones like 'you can't kick the ball out of bounds', 'you have to score between the goalposts', 'this is a corner kick', 'this is offsides'. Neither Messi nor Ronaldo made those rules, but they are all time greats in their competency.

I meant he could mentor the mentors in his teens - an age he should be getting mentored. He was that good, and surprisingly mature. He was a finished product in his teens. Cristiano wasn't. He was just one of the many talents among robinho, robben, rooney, van persie, fabregas, quaresma (to name a few i remember) - all of them rated better than cristiano.

And by rules, I don't mean offside, handball, freekick rules. I mean how to hold the line, when to dribble, when to shoot, to hold formation, play as a team, end product etc.

No wait, he has something here. Not about who is better; that’s irrelevant. But, on “rules”. What’s being discussed here are “best practice” rules —- strategies of social construct that are sometimes smarter to bend or break, or maybe can be changed entirely if you can prove a more successful method. The “rules” you’re mentioning are perhaps more akin to physics —- fundamental laws that govern the game. You really aren’t supposed to break those, regardless of talent or success.

Most people agree with this. The actual challenge is to discern real rules from superficial bullshit. That is a level of criticality many people do not possess and some find hostile or disgusting.

Raymond Hettinger talks about this in "Beyond PEP8", which is one of my favorite conference talks

https://www.youtube.com/watch?v=wf-BqAjZb8M

That talk is fantastic, and I don’t even write Python. Thanks for sharing!

That's a great talk. Thanks for sharing it.

He does well to explain how PEP 8 can be good but some people focus on it because they may not have experience to contribute otherwise.

Another challenge is that it's very easy to think you understand the rationale behind the rules well before you actually grok them.

At work I learned a theoretical set of best practices for the software we integrate with. I was very enthusiastic about applying them. This caused me to learn the real set of best practices, mostly leaning on the stuff that works most robustly (even to recreate other features, usually ones that prove inflexible when pushed).

especially when there are too many such rule lists often contridicting with each other. Finding the right list becomes the key for someone (beginner to a domain) who has to follow the rules. That's just luck.

It’s even more implicit than that. For example there are social criteria and considerations of vanity.

Another example is that I recently wrote a comment that received greater than 10 votes and was flagged (I presume by users) almost immediately. The comment was thus both commonly agreeable (perhaps people could empathize to the subject matter) and yet a violation of social norms. An unspoken social rule violation.

That comment also received contradictory responses: I’m not woke, but.... Contradictory responses are generally an explicit mention of internal confusion where the person cannot even agree with themselves on social conformance: I’m not lying, but.... If it’s not complete bullshit then don’t posture with a qualifier.

> To be a good X you must follow the rules. To be a great X you must have followed the rules so well as to learn why they’re there and when they should be broken.

In my experience slavishly following the "rules" or "best practices" can actually be worse than never following them. Not understanding when it's good to deviate usually means of a lack of understanding of why the "rules" or "best practices" exist in the first place. So much attention is spent following the letter of the rule rather than what problems it was meant to solve.

Look no further than modern day "Agile" vs the actual Agile Manifesto

At the extremes, this is known as cargo-culting. People who have only the most shallow understanding of the rules in my experience also push back the hardest against anyone who "breaks the rules", and get locked into the 'one right way' even when it's actively harming the delivery of a project.

"Rules" often contradict each other. For example, in software development, "keep it simple" often directly conflicts with "dont repeat yourself" as it takes increased complexity to achieve reuse of code. I often see keeping it simple take a back seat in newer developers as they slavishly follow the don't repeat yourself trail. The end result is routinely a brittle, rigid, and overly complex solution.

Don’t repeat yourself or making code “DRY” sounds/sells so much better than tightly coupled.

> For example, in software development, "keep it simple" often directly conflicts with "dont repeat yourself" as it takes increased complexity to achieve reuse of code.

KISS and DRY are different paradigms, i.e. come from different schools of programming.

KISS -

Most people would not recognize simple code if it hit them I'm the mouth.

KIES (keep it easy, stupid) is what they mean, and that means following idioms, frameworks, that are familiar.

DRY I would argue doesn't conflict nearly as much with a nuanced approach. "Apply Aggressive Compression to Your Code" certainly flies in the face of many other nice features of code as a working body, though

My more nuanced take I guess is "don't duplicate logic, except if it may in fact be mutable data". It does take some forward thinking to think that this e.g. list of 10 rules should be unrolled and not compressed by meaningless helpers, etc

http://thecodelesscode.com/

DRY and KISS talks about different things.

DRY is about knowledge management. The intention is to not avoid duplication of code which is a knowledge representation of the same thing. It does not mean every coincidentally similar looking code must be made into a function, as it would result in a premature abstraction, etcetera etcetera. It's why "minimum three duplication" principle is effective, because it filters which duplication represents the same knowledge and which does not.

KISS is (ironically) a more complex topic. C2 wiki talks about this in an interesting way. https://wiki.c2.com/?KeepItSimple

A lot of good ways of looking at this, and your phrasing @bombcar it's really nicely put.

In my opinion, once you play a game for a while, it's easy to know exactly when and how to break ANY rule: you must understand what the rules are there for.

Think of any agile framework, a ton of them are practiced like cults by the most. However, if you think that those are there for 2 simple purposes:

  1. you want to ensure nobody in the team is ever idle
  2. you want to ensure everyone is working on the most relevant available task that hasn't been picked up from others

Then it's easy to see which rules are useful to the goals and which are hurting you, thus you just gotta break them!

This is just an easy example, this is really about anything in life though!

You have taken a completely different 2 key lessons from agile than I would have picked.

I think mine are closer to the agile manifesto, but perhaps yours are closer to how agile is actually practiced in most places.

Problem 1: you want to ensure that you build the right thing.

Solution 1: you should get feedback from end users as frequently as possible.

Problem 2: you want to be using work processes that are appropriate for your team and task.

Solution 2: teams should be able to modify their own work processes.

Applies really nicely to music. First you learn the rules so you know when you can break them. But if you start breaking the rules from the start, people will think you have never learned them in the first place.

Reminds me of a quote from the Mustard Seed Garden Manual of Painting:

"Some consider it noble to have a method; others consider it noble not to have a method. Not to have a method is bad; to stop entirely at method is worse still. One should at first observe rules severely, then change them in an intelligent way. The aim of possessing method is to seem finally as if one had no method."

The Matrix.

To throw another quote into the mix:

“Learn the rules like a pro, so you can break them like an artist.” - Pablo Picasso

Also the social benefit of staying in stage 2 is strong. Stage 3 folks don’t mingle together easily, not just because there are less of them, but also because they have in some ways become themselves. It’s much easier for people to stick together when they believe in something together, whether it’s imperfect or not.

And then some stage 3 folks make a new stage 2 thing and the cycle continues. But I think people don’t want stage 3 attainment by giving up the social buffer (which is very reasonable, as being a social animal in most cases is better life path than a lonely scholar/innovator).

EDIT: I think what I am talking about applies better to spiritual/philosophical/psychological attainment, rather than technological. The effect is probably still there for less spiritual things like tech or writing, but probably less so.

I can subscribe to that.

> Hedgehogs are at stage 2. You move from stage 1 to stage 2 by adopting frameworks; hence, hedgehogs are seen as "thought leaders" because they teach the frameworks that lead MOST people to more mastery. Except when you're at stage 3, in which case frameworks lead you to more inefficiencies compared to your own understanding.

While interviewing recently, I've found a similar anti-correlation between general competency and people who focus on teaching frameworks and libraries.

The more competent candidates basically don't do any teaching based on frameworks/libraries (but they might have experience mentoring individuals); whereas the candidates who focused on teaching frameworks specifically (often to groups) were the least competent - the more they focused on teaching the less competent they seemed to be! I found this kinda surprising and worrying, though my sample size is fairly small. To clarify, I know only so much can be evaluated in an interview, this is basic competency.

There’s an old pithy quote about this that I won’t repeat here. I’ve seen the same results, but I also know that I may be totally underestimating their competency in an interview: I am not always competent to judge someone’s competency. Keep an open mind —teaching can become a skill trap like any other and it may take time for people to readjust if that’s no longer their primary responsibility.

Frameworks are not domain knowledge. They look good on a resume, but you're being hired to deliver software, not play with React all day.

Your response to this article about how contingent advice is usually better than universal advice is to propose a universal theory?

I did notice the irony myself :)

The article talks about contingent advice being better than universal advice only in stage 3. If you're not then universal advice is helpful. I think that holds true for most people and most subjects, including myself.

Originally, I thought the article did a great job describing a common scenario that occurs usually in decision making and I wanted to describe my intuition on why I think it comes about. It's not really a universal theory, more my own digestion / explanation on the interrelation around hedgehogs vs foxes and my own interpretation of the issues that the articles describes.

That makes sense!

I just realised my reply may have come across as mean-spirited rather than the light joke I intended. Sorry about that.

no worries! It is rather ironic.

I'm sure there are contingencies that can make contingent advice worse than universal advice.

Sure —- in situations where time is critical, for example, fast, suboptimal decisions can be more effective than slow, optimized decisions. So having something general drilled into your head can, in those cases, be preferable.

No, they just taught you, a person with a level 1 understanding of domain expertise, about how domain expertise works ;)

A universal theory is not the same thing as universal advice. What would one universally do just because one knows the universal theory?

...Now that you bring it up, the OP is offering a piece of universal advice. The irony seems stronger there. Not sure if that invalidates his advice or not. Probably just invalidates taking it as a hard and fast rule.

> detailed domain mastery in contrast is difficult, time consuming, and highly contextualized

In its defense, it's also extremely intellectually gratifying

Also: often good knowledge allows to see similiarities in other domains - feels like mastery/intuition/domain inteligence :) - it allows to instantly grasp new concepts in new domains. Works like isomorphism in math.

A mathematician is a person who can find analogies between theorems; a better mathematician is one who can see analogies between proofs and the best mathematician can notice analogies between theories. One can imagine that the ultimate mathematician is one who can see analogies between analogies.

Stefan Banach

Sounds like category theory.

This is a useful way to frame it. I would add here that stage 2 is the likely the most comfortable and that the migration from stage 2 to 3 has an embedded disincentive structure.

While this progression may exist, it is not what I took from the article, nor the original idea behind the hedgehog classification.

It is more about some thought-leader being keen on blockchains, machine learning, supply-side economics, or what have you, and looking at every problem/situation through the lens of wanting to apply this technology/policy to solve it, possibly ignoring the downsides/details/side-effects.

The article gives the fictional example of a project “just needing a relational database” but the “domain expert” trying to push them to use SpringySearch because that can also work as a relational database (and because this hedgehog is sold on SpringySearch).

But why should I trust your 3-stage framework?

What makes you question it?

This also accounts for why you see such a noisy contingent of people clamoring for difficult things (ex: software architecture) to be reduced to a discrete process: it suits the way they are currently learning, avoids sunk costs in said learning, sidesteps the hard question of, "do I really know this?" and maintains the current social status quo.

At stage 3, things aren't necessarily easy, but you have the skills to navigate much larger amounts of uncertainty than stage 1 or 2.

This is pretty brilliant.

So frequently do I see the hottest new ECMAScript feature presented by one these folks on Twitter, and I'm thinking how out of the box, older browsers won't support it, and most junior developers don't have a great grasp on polyfills or transpilers. So the first thing I'm seeing is limitations in how I might use it in a production environment (or the small but non-zero work to update my tooling to properly support ES5), but most of these folks don't seem to develop in environments requiring older browser support, but in either case, the nuance always seems missed. It's a caricature of the depth that we sometimes need to dig into.

For the stuff I work on, if the user's browser can't handle it then it's 99% sure they are not my target market in the first place. Of course YMMV.

I think this progression could make sense as a personal learning progression. The real world is probably more complex than this though.

See for example https://news.ycombinator.com/item?id=27468360 where the person mentions pressure to simplify advice and Tetlocks own work shows that the hedgehogs were the more famous and successful people. So some people may migrate backwards by simplifying a message for maximum impact.

This is an excellent break down. Remind me a lot of the mithril comparison page: https://mithril.js.org/framework-comparison.html

Definitely at stage 3, could also be the reason not as many people using it.

Domain mastery seems to be not as sequential as you stated. Stage 2 and 3 can happen at the same time.

If one stays open to new idea while at the same time keeps asking why that idea can be good or bad, one can escape the stage 2 trap.

What you've described suspiciously resembles the 'midwit' meme.

This ist a great framework to think about domain mastery. Thank you!

Great post, adding that the vast majority of hiring is based around stage 2 which creates a feedback loop of resume-driven development.

This is absolutely spot on, great interpretation.

I love this comment. IMHO would be perfect addition to original article

Thanks

> All of this makes it hard to move beyond stage 2 into stage 3.

Often, moving to the stage 3 is a waste of time and resources. There are a few cases if your business's main secret sauce is stage 3, but for most other things - commoditize and focus.

I've seen so many teams and engineers trying to master stage 3 but no real business need and ROI. Engineers love mastering things but good leaders guide them in the right things to master and avoid getting addicted to useless stage 3 expertise.

There is some value in it, you can become the guy people call in when their needs go beyond the standard framework. In the right situation this sort of work can pay handsomely.

> commoditize and focus

You say that as if there were any agreement about what that means. But the point of the article is that this is not true; you'll always find someone that insists on using technology (or technique) X for your project, only technology X will be different for each person. Moreover, X might be actually making the project harder to understand, longer to develop or have other significant downsides.

The point of reaching step 3 is not necessarily to be able to develop your own custom solution (although that can be sometimes valuable), but to able to pick the right technologies for a given project given the myriad options available.

Here's how I interpret "commoditize and focus": standardize on a well-established and popular solution that's known to be widely applicable, so you can focus on adding business value in your product. Don't go for the new shiny thing being promoted by thought leaders, but an old workhorse. Do it even though you know the old workhorse is suboptimal on one or more technical axes, because in the bigger picture, the third-party ecosystem, talent pool, and other correlates of popularity and maturity are more important.

I've repeatedly failed to follow this approach myself and have come to regret it. As I mentioned the other day, I chose Pulumi over Terraform for infrastructure as code, because Pulumi is undeniably technically superior in some ways. I now believe that was a mistake.

I'm trying to figure out how to implement the "commoditize and focus" approach when it comes to standardizing on a web application framework for my company. I believe the classic server-rendered, multi-page approach is the right one most of the time, so I'm talking about that kind of server-side web framework. I implemented our current product in Elixir using Phoenix, and I now believe that was a mistake as well. If we suppose that the top three server-side workhorse languages are Java, Python, and JavaScript via Node.js (as implied by the availability of a certain Amazon SDK for those three), then I should choose a popular framework in one of those languages. If I still try to hang onto technical merit within these constraints, then I suppose I should go with Java and Spring, since Java is statically typed and the JVM is high-performance. But Spring has such an enterprisey smell about it. If I go with what I already know, that would be Python and Django. But CPython has such awful performance, dynamic typing has known drawbacks at scale, and choosing something just because it's what I already know feels far too much like becoming old and set in my ways (I'm 40). And a strike against Spring and Django, as well as Rails and others, is that they require knowledge of a different language on the back-end than the one we already have to use on the front-end. So I guess I should go with Node.js. Maybe Express with a view engine like Pug? But to really take advantage of using the same language on both the front-end and the back-end (I don't shy away from complex front-end JS where it's needed), I should use an isomorphic framework, something like Next.js. But Next.js throws away web fundamentals like being able to submit a form the old way without JavaScript. And what about bundle size and performance on low-end devices? Yes, I'm supposed to hold my nose and tolerate mediocrity for the greater good, but should I even do that at the end-user's expense? And the better isomorphic JS frameworks (Remix, Marko, SvelteKit...) are too bleeding-edge. I don't know...

So, you're right, there's no one right way to "commoditize and focus". Sorry for the wall of text; this thread hit too close to home.

I think your description of the thought process and the eventual realisation that it is really hard to choose something that is pragmatic is spot-on.

FWIW, I would agree that most of the time you don't need an overly fancy solution. Some technologies are good for many (but not all) situations - such as relational databases. Others are useful in much more specific scenarios. That still leaves a lot of room for debate about which specific tools to use. It also leaves a lot of room for debates along the lines of "yes, I know that the whole 2000 people company uses bongoDB at scale, but in this particular case, it's actually not a good idea", something which unfortunately many people can probably relate to if they've worked at a bigger company.

Domain expertise looks like understanding all the pitfalls holistically and knowing the right ways around them. In the case you describe (deciding on technologies), this type of decision often falls to CTOs because they need complete understanding of all pitfalls of an eng department, many of which are business, people, or financial issues, not tech.

Technical advantages needs to be weighed against scaling up technical velocity (hiring developers). This is why you you might want to forgo more niche technologies for mainstream. However, if you're never going to scale past 3-10 people or the technology really suites your business case well (ie. whatsapp built on erlang), you can break that rule. Thought leaders on both sides will advise for either case, but stage 3 will know their requirements very, very well, and how to choose the right thing that will avoid all pitfalls. Another way to put it; if you hit an unanticipated pitfall down the road later, you didn't really understand the domain.

Some decisions are literally millions of dollars or more for the business, and can only be made once - in this case, you definitely want a stage 3 person who sees all the pitfalls. If you decide on lisp for your language and you can't hire enough developers to scale up, you might be bleeding customers due to lack of engineering velocity, or large price tag acquisitions may fall through because they can't do anything with your code.

Other decisions are worth 0 dollars to the business, and many engineers spend too much time on them trying to do stage 3 decision making. They usually do this with an incomplete understanding of the pitfalls (most 0 dollar decisions don't have pitfalls by definition, just a bunch of "better or worse" arguments from thought leaders - react vs vue anyone?).