[tensor]

I have to admit, even I'm not sure what a "hacker mindset" is. As one technical cofounder to another, I think the most important thing is for you to understand the business side. Most importantly, how interpersonal skills matter and how emotions play out in a business setting.

Beyond 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!"

[derefr]

> As one technical cofounder to another, I think the most important thing is for you to understand the business side.

But the OP isn't asking for help themselves, and has said nothing about needing help themselves. Maybe they already understand the business side?

[kristiandupont]

Well, it could be a case of "My wife gets upset when I cheat on her. How can I make her understand that it's not a big deal?".

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.

[derefr]

Sure, but then... what's the second step? Because that's what the OP was asking for here.

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!

[zoomablemind]

> As one technical cofounder to another, I think the most important thing is for you to understand the business side.

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.

[max_effort]

> Beyond that, a solid understanding of scientific approaches to understanding is the second most important.

Are there any good resources for learning more about this?

[hprotagonist]

any ABET-accredited engineering curriculum ought to do.

[max_effort]

Sorry for the delayed reply. I actually graduated from an ABET-accredited engineering program. I was looking for something more along the lines of "learning how to learn".

For example, a scientific analysis attempting to break down what "understanding" is, or evidence-based techniques for gaining understanding more quickly.

[_curious_]

"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?

[derefr]

The broken thought-process there is mostly about when you take a shotgun approach that involves many different things that could all individually pan out (or not); or which could all be multipliers for one-another (or not.) If, in the end, you succeed, you end up believing that everything you tried was a necessary part of your success. When, in actuality, you might have succeeded despite some of those approaches, rather than because of them. They might have been actively harmful to your success, but just not harmful enough to overcome the other successful things you tried.

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.

[_curious_]

"The broken thought-process there is mostly about when you take a shotgun approach that involves many different things..."

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.

[derefr]

I mean, we're talking about advice for running a startup here—an entrepreneur would be an idiot to not do everything possible to give themselves multiple independent avenues to success (e.g. do multiple forms of inbound advertising; attempt product-market fit with multiple markets; etc.)

[vkou]

I've worn a tiger-warding talisman around my neck for years, and so far I haven't been attacked by a tiger.

Is it fair of me to assume that this talisman works, and that I can safely climb into a tiger enclosure?

[_curious_]

I would think unless and until you have tested that hypothesis (wearing of the talisman in a tiger rich environment) it's an invalid conclusion.

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 ;)

[jfkebwjsbx]

No, it could have worked for a reason independent of the thing.

[sqrt17]

It certainly worked for them. But results are not typically indicative of risk, so anyone doing X may doom themselves by doing something that doesn't work in their special context.

[mosselman]

Do you know of any resources (books preferably) on learning to understand the business and emotional side that you are referring to?

[mch82]

“The Innovator’s Prescription” (Clay Christensen) explains the Innovator’s Dilemma better than the original book and introduces jobs-to-be-done with the milkshake story.

“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.

[mosselman]

Thank you. I am already reading Creativity Inc. at the moment and I am greatly enjoying it. I will check out the others as well.