Gut Driven Development

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.

The writer discusses the prevalence of &quot;gut feeling&quot; in development, and how justifications are often retro-fitted to justify preferences which might be driven by familiarity, or novelty.<p>Let me say this in defense of gut feelings:<p>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 &quot;content.&quot;<p>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 &quot;This is just wrong. Come on, do it <i>this</i> way,&quot; you could (rightly) accuse them of relying on gut feeling.<p>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.

I&#x27;ll note that from my experience as a programmer and a manager the best coders (and best code) was done by the people who &quot;just felt this is the right way&quot;. 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&#x27;ll correct you during CR if needed.

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

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

This is why I can&#x27;t understand age discrimination. We oldies have a wealth of experience which we can turn to. How can a new programmer have a &quot;gut feel&quot; which should be listened-to when there is little to no experience? The oldies &quot;gut feel&quot; is real because it is based on true experiences; either direct experiences or experiences of (say) a colleague.<p>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 &#x27;things&#x27; within programming regardless if it&#x27;s GO or COBOL.

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.

<p><pre><code> 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. </code></pre> This sort of introspection is useful for more than just developers.<p><pre><code> 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. </code></pre> To help counteract this, you have to put yourself in the position of questioning your views&#x2F;feelings&#x2F;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&#x27;s unprovable or a matter of tradeoffs and what&#x27;s considered more important by the different parties).

One thing I learned working with many developers over the years it&#x27;s that this is fairly dependent on the individual.<p>Some absolutely thrives in an environment without process, I&#x27;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.<p>And there are those who thrives with processes, useful and even critical for later stage of the company. I think it&#x27;s important to have a good balance of these types of developers to maximize each of their strength and weaknesses.

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.