Gut Driven Development
kevinmahoney.co.uk
kevinmahoney.co.uk
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.
I think if we had a difficult decision to make and someone wanted to roll dice, it would feel pretty frustrating, like giving up. A more motivating process would involve giving someone responsibility, empowering them to succeed, and just letting them make the call.
Solves nearly all decisions.
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.
This contrasts against safety process, where you add process to defend against mistakes as opposed to enabling collaboration.
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.
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.
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.
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."
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.
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.
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.
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! :)
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 :)
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.
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.
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.
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.
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.