Ask HN: Best resources for non-technical founders to understand hacker mindset?
Background: technical founder wondering what reading to recommend to a business focused founder for them to grok the hacker mindset. I've thought perhaps Mythical Man Month and How To Become A Hacker (Eric Raymond essay) but not sure they're quite right.
Any suggestions?
(In case it helps an analogue in the mathematical world might be A Mathematician's Apology or Gödel, Escher, Bach.)
111 comments
[ 2.9 ms ] story [ 154 ms ] threadBeyond that, a solid understanding of scientific approaches to understanding is the second most important. Being able to tease apart correlation and causation, and being rigorous about what you accept as real knowledge vs mere opinion or anecdote. The business world, and the tech world, has a lot of "opinion" that masquerades as fact. E.g. "well I did X and I'm successful so clearly X must work!"
If they did something...and that thing was successful then by definition that thing they did...it works, right?
In another instance, people who try one main thing (e.g. applying to a particular college) but who succeed entirely through no effort of their own (e.g. through nepotism), will end up thinking that what they did mattered.
This sounds like quite the qualifier...which is fine, but I think it's important to take your response/reasoning into a much more narrow hypothetical.
Is it fair of me to assume that this talisman works, and that I can safely climb into a tiger enclosure?
Now if you have successfully avoided tiger enclosures and subsequently not been attacked by any tigers, (regardless of what you are wearing) that method probably works ;)
But the OP isn't asking for help themselves, and has said nothing about needing help themselves. Maybe they already understand the business side?
I am not saying that it is but I do think that Stephen Coveys famous "seek first to understand, then to be understood" quote holds a lot of truth. In order to communicate your own perspective on something to someone, you need to have a sense of how theirs differs to yours.
IMHO it's kind of against the Principle of Charity to assume that someone asking a question about how to do part N of a multi-part process, hasn't already figured out how to do the previous N-1 parts of that process. They must have, to get to the point where they're motivated enough to reach out for help with part N.
In programming terms: if I'm writing a compiler, and I'm asking about codegen, the Principle of Charity would suggest that I've already solved enough other compiler-writing problems that I have an input to feed to a codegen pass!
Ignoring the Principle of Charity in cases like this can lead to some really useless/unproductive advice.
For example, I've been writing a research decompiler for an ISA that has less embedded information than usual (e.g. no reified CALL/RET ops, just plain branch instructions.) It needs some weird heuristics to derive subroutines from coroutines, and to properly scope variables. This means that I can't immediately derive an interprocedural SSA form for the variables, in order to help calculate a dominator tree. So I want to ask people how to calculate a dominator tree from stack variables, because having something like that would help as an input into those heuristics.
But every "solution" on StackOverflow-like sites insists that the context of the problem—the assumptions it makes—are impossible/invalid. They try to mentally rewind to step 1 themselves, and then can't understand how I solved it (because I didn't write out the textbook worth of novel algorithms I used to solve step 1 in the problem description), so they don't even believe there is a step 2. Rather than just... attempting to help me with step 2. Which doesn't actually require any understanding of step 1, other than its outputs.
It's sort of the opposite of the XY problem. Rather than the parent problem X being best solved through a different strategy that avoids problem Y, people believe that the parent problem X itself is unreasonable, because they model an X that is solved through Y as requiring that the solution also flow through a previous sub-problem Z; and they think that Z is something that people just don't bother to do, so nobody could actually be asking in good faith about XY.
I've also suffered through this with doctors, who literally won't believe me when I list off the entire sequence of steps they would try and say that I've tried them to no avail. I only go to the doctor when I run out of ways to try to solve the problem myself, so if I'm here, it's because the problem is a zebra instead of a horse! A horse, I would have fixed on my own!
“Creativity Inc.” (Ed Catmull) explains how Pixar manages people & throws in a few insights from mature (post Apple firing) Steve Jobs.
“Managing the Design Factory” (Don Reinertsen) explains how to prioritize projects and analyze a business for bottlenecks in order to minimize cost of delay.
Totally on-the-point advice! The mind of a business-mate is often less ranged and logical than a techy-mate would prefer. So could be your biz patner's way of understanding and discovering what makes a techy mind tick.
If this is to improve understanding between you two, the best way is to agree on zones of responsibility and what it takes to come to trust in result. The hardest for biz folks is to relinquish control, while hardcore tech guys don't like to compromise. Somehow these need to balance.
Are there any good resources for learning more about this?
For example, a scientific analysis attempting to break down what "understanding" is, or evidence-based techniques for gaining understanding more quickly.
How to understand the business/sales/marketing/leadership/political mindset. Without cynicism.
I'd also recommend Peopleware
The one case that I can think of off the top of my head that might apply to this situation is if there are disagreements re:product refinement/feature set/bug prevalence. (Basically, “why doesn’t this work as seamlessly as X?”) In that case you might do well to find the MVPs (and later iterations) of famous startups.
From 1000 ft, what's different between the two? It's all about solving problems.
The business focused founder sees a problem, a business/market opportunity. He/She needs to figure out how to solve it, how to come up with a way to satisfy that market. If a product exists, how do they get that product into the hands of the customer. If the product doesn't exist, how to get it into existence and then get it into the hands of the customer.
The hacker/developer/whatever sees a problem and He/She tries to develop a product that satisfies that problem based on the requirements they're either given or suss out themselves. The hacker mindset is an insatiable need for knowledge. How to do a thing. How to make a thing. How did others make a thing. Don't business people think that way, also? Probably one big difference might be that the hacker mindset shares knowledge. Business people are more protective of it. (Generally)
That's painting with broad strokes obviously and a person can be motivated by both. But that's the axis I would draw the distinction on.
Fiction:
Douglas Copeland's "Microserfs"
Neal Stephenson, "Snow Crash" and perhaps especially "Cryptonomicon" (the early randy chapters and anything about Eiphphyte in particular)
Real Genius (the film).
Nonfiction:
Steven Levy's Hackers: Heroes of the Computer Revolution. All the elder gods are here.
Cliff Stoll, The Cuckoo's Egg.
https://kitboga.com/
I was left agasp by some of the language (some is NSFW) and techniques ised by the scammers, but you would be the grandmother with dementia (non-technical user) vs someone who will say/do anything for money.
I read Fire in the Valley when I was young and it impacted me, although there might be a better book that's similar. I might also recommend something by Jaron Lanier or Stallman if you don't might being a little political.
https://www.are.na/zach-rose/use-misuse-rugged-consumerism-e...
So being a hacker is a practice, and in some cases it's a lifestyle (when you orient your life around hacking). But it's not a mindset. Some folks are compulsive hackers, some are methodical, some are opportunistic, others are hackers out of necessity - but they're all united by what they do, not how they think.
so maybe use your hacker mindset to deduce this is the mindset then?
If I had to define hacker attitudes, I wouldn't use information collection and application as the standard. Some people carefully select subjects study them in depth, and others just passively pick up information through exposure to experts, and others collect knowledge as a by-product of trying random stuff and failing at it. Hackers (and non-hackers) don't necessarily need to prefer one method to the other. And everyone, even non-hackers collect information - so that's not in itself a special attitude of hackers. The application part is more unique, but how is that different from what artists do?
If I had to choose particular attitudes that would enable someone to practice as a hacker, it would be:
- high tolerance for failure and unexepected behaviors, or even joy in failure under certain circumstances.
- Gains pleasure from novelty (learning new things, having new experiences, finding new applications of things). As a result, most hacker types place more value on things that are obviously flawed, but novel and unique vs things which are perfectly executed but familiar.
I think that second point differentiates hackers from at least some artists (ie, Chefs usually prefer to stick to establish culinary pattersn, musicians playing in a symphony find beauty in the same piece that has been played for hundreds of years). Other experimental artists who do seek novelty (noise music, etc) are basically hackers IMO.
Edit: but to my original point, if you have neither of the attitudes I identified, but do hacker stuff anyhow - you're still a hacker. Those attitude patterns don't take precedence over the actual reality of hacking. There just common in people who continue to do it over their lifetime.
Read books by hackers, watch conference talks. And ofc get to know hackers, go to hack spaces. Keep an open mind and be curious. That's a good starting point to see how hacker culture really is. It's mostly about unorthodox curiosity and having fun with machines and systems. Think of children playing with toys, who grew up and never stopped playing with toys.
Don't waste your time on pop culture presentations of hackers, like movies or reading articles about "great" hacks or hackers, it's misleading and not going to transform your mind to think like a hacker in any way.
The only connection between Facebook and hacking I can think of is that their software may have relied on "dirty hacks" and crutches in the past to make it work.
Hacker culture by nature is very anti-corporate, anarchistic and against subordinating everything under the dictatorship of profit maximization.
If the OP thinks "hacker mindest" equals being on a path to create the next big app or service, you are being mislead big time.
Yes! I came this close to recommending "Steal This Book" by Abbie Hoffman for that exact reason. But I got the feeling that was not exactly the type of hacker that OP was looking for...
I strongly encourage you to make your non-technical folks aware of good engineering practices, instead of this "everyone needs to learn to code and have special snowflake hacker skills" mindset that has so permeated the industry.
Please don't recommend Eric Raymond's work to people.
> technical founder wondering what reading to recommend to a business focused founder for them to grok the hacker mindset
What does "the hacker mindset" mean to you?
If you ask me: The most important thing about a hacker mindset is that it must exist outside of technology. A hacker mindset is not a "techy" mindset, it's something far more sublime, and is portable across different fields.
Hacking is about creativity and problem solving, but not in a formalized way. That doesn't always involve computers and related technology. Hacking should be fun, regardless of what industry or specialization it manifests in (which doesn't always translate well in business settings).
That isn't something that you're going to inject into someone by recommending them read a book. They have to seek it out for themselves. Without curiosity, hackers do not exist.
If they're going to be able to understand the mindset without having experienced it themselves, you might as well just share my comment here with them. If it sinks in, great! If not, I don't believe a few hundred pages of prose will have a different outcome.
Why? Do you have some problem with his advice on how to ask questions[1]?
[1] http://catb.org/~esr/faqs/smart-questions.html
Because promoting ESR's work to people has the unfortunate side-effect of elevating ESR's prestige.
See https://news.ycombinator.com/item?id=15513086 for more on why ESR is bad.
> Do you have some problem with his advice on how to ask questions[1]?
No, I think he's a bad person and we do our entire industry a disservice by continuing to elevate his status.
Find better heroes, should you even want heroes.
If I recall, there's a Buddhist proverb, where a pig is held up as a good example of enlightenment: it will happily pick truffles out of mud, taking the truffle and leaving the mud behind. It doesn't develop an opinion on the mud in the process; the truffle grew from the mud, but the mud isn't relevant to the truffle. It doesn't venerate/privilege/respect the mud—but nor does it find it disgusting. It's just mud. Irrelevant. Not food. The truffle, clean of mud, stands on its own. The truffle is a necessary part of a creature's mental model, insofar as it experiences hunger; but the mud is not.
https://news.ycombinator.com/newsguidelines.html
I recommend hackers and painters by pg.
Skims on the painting part, I thought, but it makes for an interesting insight into the personal philosophy of someone who values both creativity and logic.
Many of his ideas are universal (probably why I'm here!). Others don't port so well (or are specific to his experience).
Well worth the OPs time, given the question.
Joel on Software is also a fantastic read. More concrete in talking about specific aspects of a software developers' working experience, and ideas towards technology in general.
A mentor of mine suggested I should read it alongside Hackers and Painters.
I can't thank him and his friends enough, frankly...
Made me realise that many just do it because they like the challenge.