5 ms·

Gut Driven Development

56 points by nevatiaritika 10y ago

startupdiscuss 10y ago
The writer discusses the prevalence of "gut feeling" in development, and how justifications are often retro-fitted to justify preferences which might be driven by familiarity, or novelty. Let me say this in defense of gut feelings: Sometimes the opposite of gut feeling is process. Bezos recently talked about the potential pitfalls of process, and Jobs famously warned us against confusing process with what he calls "content." The issue is that if you have a process, you end up relying on it to make things good. It cannot. If someone were to walk into the process and say "This is just wrong. Come on, do it this way," you could (rightly) accuse them of relying on gut feeling. All of this is to say that there are gut feelings and then there are gut feelings, and it is important to tell them apart.
- rocqua 10y ago
  It felt to me like the argument was that gut-feeling stuff can impede collaboration. I'd argue that, in large collaborative settings, this is precisely where process is needed. This contrasts against safety process, where you add process to defend against mistakes as opposed to enabling collaboration.
  - noobiemcfoob 10y ago
    You have a point. A company's "process" to me has always represented the message passing system in a multicore processor. The process is the method by which each core is updated with pertinent information (consumables or just new rules for their task). Bad process looks like a lot of overhead where everyone spends more time "communicating" than working. Ultimately, as long as you can quickly and effectively communicate the impact of a gut feeling, there is no problem, but they would seem especially hard to translate into a more formalized process for communicating thought out decisions.
MichaelAza 10y ago
I'll note that from my experience as a programmer and a manager the best coders (and best code) was done by the people who "just felt this is the right way". Usually the code produced is exactly good enough for the task at hand, and by creating a code base that can be easily refactored (for example, with lots of automated tests) it can be easily changed later. I always tell my junior programmers who tend to ask a lot of questions and get stuck up on process - code whatever you feel like coding. I trust your judgment. I'll correct you during CR if needed.
- BeetleB 10y ago
  >I'll note that from my experience as a programmer and a manager the best coders (and best code) was done by the people who "just felt this is the right way". I'll note that from my experience as a programmer, the worst code was done by people who "just felt this is the right way". Note that I'm not disagreeing with you. This is a classic case of confirmation bias. Looking at what is common amongst great coders/code is the first step. But that step is incomplete unless you test against crappy code. Is that feature you found in great code often present in crappy code? Then it likely has little to do with code quality... Coding from the gut is the thing to do if you're a great coder. Not the other way round.
  - coldtea 10y ago
    >I'll note that from my experience as a programmer, the worst code was done by people who "just felt this is the right way". No, the worst code is by people who just wrote it that way because they didn't know better, and who don't have any strong opinions one way or another.
- kpmah 10y ago
  I'm not arguing against using your gut feeling, it is more that if those coders examined why they do things they way they do they could probably come up with some good reasons. And then if you want to convince other people to do it your way it is better to say "do this because X, Y, Z" than "do this because I think it's better."
- EliRivers 10y ago
jaequery 10y ago
One thing I learned working with many developers over the years it's that this is fairly dependent on the individual. Some absolutely thrives in an environment without process, I've seen some who simply crushes it without processes and procedures. Beneficial for early stages of company who wants to get a product out asap. And there are those who thrives with processes, useful and even critical for later stage of the company. I think it's important to have a good balance of these types of developers to maximize each of their strength and weaknesses.
- samiru 10y ago
  I think it has something to do with different kind of processing in the left/right hemispheres of the brain. For most people left brain type of thinking (attention to detail, focus on process) dominates, it also may be harder for them to see where and how the "gut feeling" originates.
sbov 10y ago
Gut Driven Development is oftentimes confused with First Solution Encountered Driven Development or Familiarity Driven Development. Depending upon the circumstances, none of them are necessarily bad.
empath75 10y ago
I've been on a team that was absolutely paralyzed by over analyzing every choice to death. We spent months arguing about chef va ansible, for example. Sometimes you have to just say: 'Fuck it, we're using chef' (or go, or aws) because the time you waste spinning wheels is more expensive than the loss of efficiency from making the less than ideal choice. And those are the times when gut instincts matter.
- escherize 10y ago
  Sounds like the choice paralysis discussed here yesterday: https://news.ycombinator.com/item?id=14102937 https://news.ycombinator.com/item?id=14102937
  - wruza 10y ago
    It is regularly discussed. Things that should be taught in educational facilities, but aren't.
- donw 10y ago
  If the team can't hammer things out in a timeboxed meeting, there are some options. With new technology, I'll have a pair of team members spend some time doing exploratory work. Spend some time with the top 2-3 technologies and see which is the best fit. Taking notes through this process is important. If we're comparing databases, include benchmarks and tooling observations. For small organizations, this is usually a multi-day process. For large organizations, maybe up to a month. But at the end, the team can make a decision based on at least some experience and information. If, on the other hand, we have competing factions that each has experience with a specific bit of kit, but can not come to an agreement: we roll for initiative. Literally. I have a set of dice in my backpack for this exact situation. Often, the worst decision is no decision at all, and I would rather that the team go down the wrong road for a month (and learn from the process) then spend that month arguing over what color to paint the hangar de vélos.
  - amorphid 10y ago
    I'm taking my dice to work from now on.
Jtsummers 10y ago
In my experience, you can almost always examine your opinions and find some objective advantage. If you can’t, your opinion probably isn’t very solid. Recognising your gut feelings and examining them can be eye opening, and can make you a better developer. This sort of introspection is useful for more than just developers. Once you recognise biases like this it will become clear to you that people often start with a biased opinion and then reason backwards from there to support it. You’ll do it too, and it’s OK to do that as long as you can examine it and put forward a solid argument. Never think biases don’t apply to you. To help counteract this, you have to put yourself in the position of questioning your views/feelings/beliefs, and putting them in the context of the opposing views. If you think X is right, find those that think ¬X, or a variant of X, and consider why they believe it. Genuinely questioning and not just seeking out confirmation to your positions, or counterarguments to theirs. Usually the correct views are somewhere in between, or will be revealed to be subjective (that is, no right or wrong, either irrelevant because it's unprovable or a matter of tradeoffs and what's considered more important by the different parties).
jkmcf 10y ago
I practice Dirk Gently Driven Development. Basically, I more or less know what I want to do, my fingers wander, encounter things I didn't anticipate and I modify my work. When it is done, I refactor and add tests where necessary. Not the best methodology, but that's how my brain works -- all situational recall.
frozenmangos 10y ago
The Psychology of Human Misjudgment by Charles T. Munger is the single best thing I've read on this topic: http://www.hb.org/the-psychology-of-human-misjudgment-by-charles-t-munger/ http://www.hb.org/the-psychology-of-human-misjudgment-by-cha... I think it's unique to tech that people are biased toward thinking things are good just because they're new. I've found that in most of the rest of the world, people think new things are dangerous, frightening, insubordinate, disruptive, and irritating.
- cle 10y ago
  > I think it's unique to tech that people are biased toward thinking things are good just because they're new. I take it you haven't worked at a big company? Companies get big, stakes get high, people get entrenched and complacent--and newness is viewed exactly as you describe.
- kpmah 10y ago
  Forgive me for getting political, but I think Trump was a good non-tech example of 'good because it's new'. Without a voting record and few concrete policies people were free to project their hopes on to him. I have also noticed the 'dangerous/frightening because it's new' bias. I don't understand why it flips one way or the other. People are weird! :)
  - LyndsySimon 10y ago
    This seems very apt to me. I voted for Trump, and found my justification after I had decided that I would probably do so. The bottom line was that I wasn't going to vote for Clinton and Trump was the only other viable option. I've also chosen relatively untested libraries for projects because I'd already used the more mature choice for another project and hated it :)
ImTalking 10y ago
This is why I can't understand age discrimination. We oldies have a wealth of experience which we can turn to. How can a new programmer have a "gut feel" which should be listened-to when there is little to no experience? The oldies "gut feel" is real because it is based on true experiences; either direct experiences or experiences of (say) a colleague. And most of the experiences that I have, for example, are largely independent of a particular language or environment, they are more about the correct way to structure 'things' within programming regardless if it's GO or COBOL.
- LyndsySimon 10y ago
  For reference: I'm 32. It seems to me that developers go one of two ways as they gain experience - they either become set in their preferences and ideas and become resistant to change, or they consciously suppress that instinct and realize their preconceptions may be incomplete. I try to be the second type. For example: I have been writing HTML/CSS/JS for around fifteen years, and have established a strong pattern for separating structure (HTML), presentation (CSS), and behavior (JS). There are obviously instances where these barriers are crossed but those should be the exception rather than the rule. When I first picked up React, I was appalled by the mixture of the three. Using inline CSS is a huge code smell to me, yet that seems to be the convention in React. The other developers out there who created React and who use it idiomatically are not morons. Instead of trying to make React fit the way I want to do things, I set aside my "gut feeling" and follow the convention. I already know plenty about the type of debt that can be incurred by using inline CSS, so I watch for that to begin to accrue. If I start to run into those issues I can raise the alarm and refactor before it gets to the point where doing so would be a prohibitively complex undertaking. My point is, you can find a lot of value in that gut feeling without allowing it to control you. I'll even go so far as to say that my "gut feeling" is one of my greatest assets. If code smells to me and it costs very little to satisfy that sense, I refactor it. I don't have the space in my working memory to remember all the rules and guidelines I've developed over time much less the reasons for each of those. Now, if I'm doing a code review, that's another story. Then I'll note that something has a smell, describe how I identified that smell, and describe my justification for it. I see code review as an opportunity to transfer that knowledge.
ratliffchrisb 10y ago
I think the last paragraph in the article is key, the most interesting and tiring arguments are the ones where both parties believe the other is arguing from the gut and have retroactively reasoned while they are being perfectly rational. Being able to see when you might be doing this as well often makes the discussion much less adversarial.

56 points by nevatiaritika 10y ago

The writer discusses the prevalence of "gut feeling" in development, and how justifications are often retro-fitted to justify preferences which might be driven by familiarity, or novelty. Let me say this in defense of gut feelings: Sometimes the opposite of gut feeling is process. Bezos recently talked about the potential pitfalls of process, and Jobs famously warned us against confusing process with what he calls "content." The issue is that if you have a process, you end up relying on it to make things good. It cannot. If someone were to walk into the process and say "This is just wrong. Come on, do it this way," you could (rightly) accuse them of relying on gut feeling. All of this is to say that there are gut feelings and then there are gut feelings, and it is important to tell them apart.

rocqua 10y ago
It felt to me like the argument was that gut-feeling stuff can impede collaboration. I'd argue that, in large collaborative settings, this is precisely where process is needed. This contrasts against safety process, where you add process to defend against mistakes as opposed to enabling collaboration.
- noobiemcfoob 10y ago
  You have a point. A company's "process" to me has always represented the message passing system in a multicore processor. The process is the method by which each core is updated with pertinent information (consumables or just new rules for their task). Bad process looks like a lot of overhead where everyone spends more time "communicating" than working. Ultimately, as long as you can quickly and effectively communicate the impact of a gut feeling, there is no problem, but they would seem especially hard to translate into a more formalized process for communicating thought out decisions.

MichaelAza 10y ago

I'll note that from my experience as a programmer and a manager the best coders (and best code) was done by the people who "just felt this is the right way". Usually the code produced is exactly good enough for the task at hand, and by creating a code base that can be easily refactored (for example, with lots of automated tests) it can be easily changed later. I always tell my junior programmers who tend to ask a lot of questions and get stuck up on process - code whatever you feel like coding. I trust your judgment. I'll correct you during CR if needed.

BeetleB 10y ago
>I'll note that from my experience as a programmer and a manager the best coders (and best code) was done by the people who "just felt this is the right way". I'll note that from my experience as a programmer, the worst code was done by people who "just felt this is the right way". Note that I'm not disagreeing with you. This is a classic case of confirmation bias. Looking at what is common amongst great coders/code is the first step. But that step is incomplete unless you test against crappy code. Is that feature you found in great code often present in crappy code? Then it likely has little to do with code quality... Coding from the gut is the thing to do if you're a great coder. Not the other way round.
- coldtea 10y ago
  >I'll note that from my experience as a programmer, the worst code was done by people who "just felt this is the right way". No, the worst code is by people who just wrote it that way because they didn't know better, and who don't have any strong opinions one way or another.
kpmah 10y ago
I'm not arguing against using your gut feeling, it is more that if those coders examined why they do things they way they do they could probably come up with some good reasons. And then if you want to convince other people to do it your way it is better to say "do this because X, Y, Z" than "do this because I think it's better."
EliRivers 10y ago

jaequery 10y ago

One thing I learned working with many developers over the years it's that this is fairly dependent on the individual. Some absolutely thrives in an environment without process, I've seen some who simply crushes it without processes and procedures. Beneficial for early stages of company who wants to get a product out asap. And there are those who thrives with processes, useful and even critical for later stage of the company. I think it's important to have a good balance of these types of developers to maximize each of their strength and weaknesses.

samiru 10y ago
I think it has something to do with different kind of processing in the left/right hemispheres of the brain. For most people left brain type of thinking (attention to detail, focus on process) dominates, it also may be harder for them to see where and how the "gut feeling" originates.

sbov 10y ago

Gut Driven Development is oftentimes confused with First Solution Encountered Driven Development or Familiarity Driven Development. Depending upon the circumstances, none of them are necessarily bad.

empath75 10y ago

I've been on a team that was absolutely paralyzed by over analyzing every choice to death. We spent months arguing about chef va ansible, for example. Sometimes you have to just say: 'Fuck it, we're using chef' (or go, or aws) because the time you waste spinning wheels is more expensive than the loss of efficiency from making the less than ideal choice. And those are the times when gut instincts matter.

escherize 10y ago
Sounds like the choice paralysis discussed here yesterday: https://news.ycombinator.com/item?id=14102937 https://news.ycombinator.com/item?id=14102937
- wruza 10y ago
  It is regularly discussed. Things that should be taught in educational facilities, but aren't.
donw 10y ago
If the team can't hammer things out in a timeboxed meeting, there are some options. With new technology, I'll have a pair of team members spend some time doing exploratory work. Spend some time with the top 2-3 technologies and see which is the best fit. Taking notes through this process is important. If we're comparing databases, include benchmarks and tooling observations. For small organizations, this is usually a multi-day process. For large organizations, maybe up to a month. But at the end, the team can make a decision based on at least some experience and information. If, on the other hand, we have competing factions that each has experience with a specific bit of kit, but can not come to an agreement: we roll for initiative. Literally. I have a set of dice in my backpack for this exact situation. Often, the worst decision is no decision at all, and I would rather that the team go down the wrong road for a month (and learn from the process) then spend that month arguing over what color to paint the hangar de vélos.
- amorphid 10y ago
  I'm taking my dice to work from now on.

Jtsummers 10y ago

In my experience, you can almost always examine your opinions and find some objective advantage. If you can’t, your opinion probably isn’t very solid. Recognising your gut feelings and examining them can be eye opening, and can make you a better developer. This sort of introspection is useful for more than just developers. Once you recognise biases like this it will become clear to you that people often start with a biased opinion and then reason backwards from there to support it. You’ll do it too, and it’s OK to do that as long as you can examine it and put forward a solid argument. Never think biases don’t apply to you. To help counteract this, you have to put yourself in the position of questioning your views/feelings/beliefs, and putting them in the context of the opposing views. If you think X is right, find those that think ¬X, or a variant of X, and consider why they believe it. Genuinely questioning and not just seeking out confirmation to your positions, or counterarguments to theirs. Usually the correct views are somewhere in between, or will be revealed to be subjective (that is, no right or wrong, either irrelevant because it's unprovable or a matter of tradeoffs and what's considered more important by the different parties).

jkmcf 10y ago

I practice Dirk Gently Driven Development. Basically, I more or less know what I want to do, my fingers wander, encounter things I didn't anticipate and I modify my work. When it is done, I refactor and add tests where necessary. Not the best methodology, but that's how my brain works -- all situational recall.

frozenmangos 10y ago

The Psychology of Human Misjudgment by Charles T. Munger is the single best thing I've read on this topic: http://www.hb.org/the-psychology-of-human-misjudgment-by-charles-t-munger/ http://www.hb.org/the-psychology-of-human-misjudgment-by-cha... I think it's unique to tech that people are biased toward thinking things are good just because they're new. I've found that in most of the rest of the world, people think new things are dangerous, frightening, insubordinate, disruptive, and irritating.

cle 10y ago
> I think it's unique to tech that people are biased toward thinking things are good just because they're new. I take it you haven't worked at a big company? Companies get big, stakes get high, people get entrenched and complacent--and newness is viewed exactly as you describe.
kpmah 10y ago
Forgive me for getting political, but I think Trump was a good non-tech example of 'good because it's new'. Without a voting record and few concrete policies people were free to project their hopes on to him. I have also noticed the 'dangerous/frightening because it's new' bias. I don't understand why it flips one way or the other. People are weird! :)
- LyndsySimon 10y ago
  This seems very apt to me. I voted for Trump, and found my justification after I had decided that I would probably do so. The bottom line was that I wasn't going to vote for Clinton and Trump was the only other viable option. I've also chosen relatively untested libraries for projects because I'd already used the more mature choice for another project and hated it :)

ImTalking 10y ago

This is why I can't understand age discrimination. We oldies have a wealth of experience which we can turn to. How can a new programmer have a "gut feel" which should be listened-to when there is little to no experience? The oldies "gut feel" is real because it is based on true experiences; either direct experiences or experiences of (say) a colleague. And most of the experiences that I have, for example, are largely independent of a particular language or environment, they are more about the correct way to structure 'things' within programming regardless if it's GO or COBOL.

LyndsySimon 10y ago
For reference: I'm 32. It seems to me that developers go one of two ways as they gain experience - they either become set in their preferences and ideas and become resistant to change, or they consciously suppress that instinct and realize their preconceptions may be incomplete. I try to be the second type. For example: I have been writing HTML/CSS/JS for around fifteen years, and have established a strong pattern for separating structure (HTML), presentation (CSS), and behavior (JS). There are obviously instances where these barriers are crossed but those should be the exception rather than the rule. When I first picked up React, I was appalled by the mixture of the three. Using inline CSS is a huge code smell to me, yet that seems to be the convention in React. The other developers out there who created React and who use it idiomatically are not morons. Instead of trying to make React fit the way I want to do things, I set aside my "gut feeling" and follow the convention. I already know plenty about the type of debt that can be incurred by using inline CSS, so I watch for that to begin to accrue. If I start to run into those issues I can raise the alarm and refactor before it gets to the point where doing so would be a prohibitively complex undertaking. My point is, you can find a lot of value in that gut feeling without allowing it to control you. I'll even go so far as to say that my "gut feeling" is one of my greatest assets. If code smells to me and it costs very little to satisfy that sense, I refactor it. I don't have the space in my working memory to remember all the rules and guidelines I've developed over time much less the reasons for each of those. Now, if I'm doing a code review, that's another story. Then I'll note that something has a smell, describe how I identified that smell, and describe my justification for it. I see code review as an opportunity to transfer that knowledge.

ratliffchrisb 10y ago

I think the last paragraph in the article is key, the most interesting and tiring arguments are the ones where both parties believe the other is arguing from the gut and have retroactively reasoned while they are being perfectly rational. Being able to see when you might be doing this as well often makes the discussion much less adversarial.