> Imagine a dentist who is passionate about pulling teeth out ... That's a great metaphor for code-before-you-know developers.
A key difference between a big decision and a small decision is what it's like to change your decision afterwards.
I don't think we can compare reverting a pulled tooth vs 2 hours of programming the "wrong" thing.
In the programming case, you may have went down a rabbit hole that wasn't correct but at least now you're 1 step closer to the right solution. You probably learned something and the business can write that off as R&D.
In the pulled tooth case, well, I'm not sure I want to Google that haha. Is it possible to fully replant a pulled tooth in a way where it's 100% healthy and you'd never notice it was pulled? I know there's implants but I mean the real natural tooth, complete with its root. I'm sure the process in any case would not be fun for the person who needs the work done.
You could classify one of these as a small decision and the other one as large.
I still think planning and understanding the problem before coding most things is a very good idea btw, but I would feel way more comfortable experimenting with code in short periods of time vs experimenting in a dental chair / operating room.
I maybe wrong but let me paraphrase what I think they meant (and why I think it's a great analogy).
I don't want my teeth pulled just because. If it's a fix to a problem - a means to an end - and there's no other way to do it, I'll consider it. Likewise, I don't want to work with developers who are super passionate about typing code into vim. I want to work with developers who are passionate about solving problems. Code can be a means to that end, and by the time it gets to us we typically already know we need some code for it, but the danger is spending days or weeks writing code nobody needs and nobody asked for because it's "their passion."
Also, I see every custom line of code written as a future burden. Part of software engineering is effectively minimizing and managing that burden.
If we write 10,000 LoC for something that we didn't end up needing... the team's going to be tempted to wrangle that into the actual purpose instead of throwing it out.
So overly aggressive fingers on keyboard lead to more bloated results, as requirements drift during development and more code is written to target them.
Meetings advance problem-solving insofar as they inform the code eventually typed into vim.
Some problems genuinely require a lot of this kind of deliberation, but most don’t. Some meetings aimed at this kind of deliberation make meaningful progress, but most don’t. The person who can terminate or pre-empt an inflated or stalled conversation with working code is extremely valuable.
Even if that code is not the ultimate solution, it has a definite shape and objective properties that can be investigated and weighed, which brings rigor to discussions that get lost in abstraction.
Organizational politics and entropy also tend to create too much talking: it is good for your career to present the work you’re doing as requiring a lot of collaboration (whether or not it does), it is easier to spitball in meetings than to actually solve problems (if you even have the skills), and you have to go to all the meetings you’re invited to (while coding time gets ruthlessly prioritized).
A key difference between a big decision and a small decision is what it's like to change your decision afterwards.
I don't think we can compare reverting a pulled tooth vs 2 hours of programming the "wrong" thing.
In the programming case, you may have went down a rabbit hole that wasn't correct but at least now you're 1 step closer to the right solution. You probably learned something and the business can write that off as R&D.
In the pulled tooth case, well, I'm not sure I want to Google that haha. Is it possible to fully replant a pulled tooth in a way where it's 100% healthy and you'd never notice it was pulled? I know there's implants but I mean the real natural tooth, complete with its root. I'm sure the process in any case would not be fun for the person who needs the work done.
You could classify one of these as a small decision and the other one as large.
I still think planning and understanding the problem before coding most things is a very good idea btw, but I would feel way more comfortable experimenting with code in short periods of time vs experimenting in a dental chair / operating room.