3 ms·

Not every decision has to be done with maximum research. That’s usually a waste of time. It’s more efficient to try a couple things until something works and mo

Not every decision has to be done with maximum research. That’s usually a waste of time. It’s more efficient to try a couple things until something works and move on (“satisficing”). A key skill you learn over time is why decisions actually matter. But it’s not inherently bad that there’s no good reason for something, it really depends on the context. And sometimes things that had good reasons turn out bad anyway because the assumptions proved wrong or circumstances changed.

jfengel 3y ago
A good life lesson in general. My version of it: "most of the most important decisions you make in life will be made in the basis of insufficient information." As programmers we may be used to the notion that we can optimize if we know enough. We often can't. Decisions won't get better with more information because it's still insufficient. All you can do is use your best judgment -- of when to use your best judgment. And live with the consequences. That doesn't help you make the decision. But it can help you avoid spending too much time kicking yourself over it.
PragmaticPulp 3y ago
> Not every decision has to be done with maximum research. I’ve been at a couple companies that wouldn’t take any proposal seriously unless you showed up with a list of citations to blog posts, books, or even podcasts. The root cause was a management structure that wanted to do everything with a maximum of evidence. It opened the door to a lot of terrible decisions winning for no reason other than someone found a blog post that Google does it this way, or Uber wrote a blog post about this, or Martin Fowler wrote a post about that. The most egregious abuse was when a team that had to deal with maybe 100 logins per day spent over 6 months researching how to build their auth system to match Big Tech. They could have picked any off the shelf solution and been done in a week, but instead it became an endless boondoggle of research, presentations, proposals, and committees. Several people were even planning conference talks around it, so it started to evolve into whatever would sound best for their talks. That was my cue that I was at the wrong type of company.
- ilyt 3y ago
  Or in general wanting to do "what industry does", not the solution that people they pay and work with actual product and their customers invented. > The most egregious abuse was when a team that had to deal with maybe 100 logins per day spent over 6 months researching how to build their auth system to match Big Tech. They could have picked any off the shelf solution and been done in a week, but instead it became an endless boondoggle of research, presentations, proposals, and committees. Several people were even planning conference talks around it, so it started to evolve into whatever would sound best for their talks. To be entirely fair, after dealing with the reverse way of solving it ("just the simplest solution that works", which was just a bunch of static passwords per app) I'd say spending a bit extra to start with good solution for auth in your 50 man company will save a whole massive amount of pain when company grows both in internal service count, users, and compliance requirements.
- hitekker 3y ago
  I’ve been at the flip side where a few google searches would have contradicted much of the fun complexity proposed by the developers of the system. Or the PMs “talked to the users”, didn’t write anything down, and then demanded features that weren’t used at all. Just enough research should be the theme for any decisions of great consequence.
Enginerrrd 3y ago
So I come from a background of Civil Engineering. We basically don't do ANYthing arbitrarily. There's a reason for basically every aspect of a design. Sometimes there are competing criteria that leave it to humans to decide, but honestly it's rare. Usually the constraints drive the design from concept down to minute details. Within the constraints and criteria, there's codes and manuals that cover almost everything. It's always seemed to me that software has really suffered from a lack of this approach. Is it the best way to maximize innovation? No, but in some ways, you might be surprised how much placing heavy constraints on a project will drive innovation.

jfengel 3y ago

A good life lesson in general. My version of it: "most of the most important decisions you make in life will be made in the basis of insufficient information." As programmers we may be used to the notion that we can optimize if we know enough. We often can't. Decisions won't get better with more information because it's still insufficient. All you can do is use your best judgment -- of when to use your best judgment. And live with the consequences. That doesn't help you make the decision. But it can help you avoid spending too much time kicking yourself over it.

PragmaticPulp 3y ago

> Not every decision has to be done with maximum research. I’ve been at a couple companies that wouldn’t take any proposal seriously unless you showed up with a list of citations to blog posts, books, or even podcasts. The root cause was a management structure that wanted to do everything with a maximum of evidence. It opened the door to a lot of terrible decisions winning for no reason other than someone found a blog post that Google does it this way, or Uber wrote a blog post about this, or Martin Fowler wrote a post about that. The most egregious abuse was when a team that had to deal with maybe 100 logins per day spent over 6 months researching how to build their auth system to match Big Tech. They could have picked any off the shelf solution and been done in a week, but instead it became an endless boondoggle of research, presentations, proposals, and committees. Several people were even planning conference talks around it, so it started to evolve into whatever would sound best for their talks. That was my cue that I was at the wrong type of company.

ilyt 3y ago
Or in general wanting to do "what industry does", not the solution that people they pay and work with actual product and their customers invented. > The most egregious abuse was when a team that had to deal with maybe 100 logins per day spent over 6 months researching how to build their auth system to match Big Tech. They could have picked any off the shelf solution and been done in a week, but instead it became an endless boondoggle of research, presentations, proposals, and committees. Several people were even planning conference talks around it, so it started to evolve into whatever would sound best for their talks. To be entirely fair, after dealing with the reverse way of solving it ("just the simplest solution that works", which was just a bunch of static passwords per app) I'd say spending a bit extra to start with good solution for auth in your 50 man company will save a whole massive amount of pain when company grows both in internal service count, users, and compliance requirements.
hitekker 3y ago
I’ve been at the flip side where a few google searches would have contradicted much of the fun complexity proposed by the developers of the system. Or the PMs “talked to the users”, didn’t write anything down, and then demanded features that weren’t used at all. Just enough research should be the theme for any decisions of great consequence.

Enginerrrd 3y ago

So I come from a background of Civil Engineering. We basically don't do ANYthing arbitrarily. There's a reason for basically every aspect of a design. Sometimes there are competing criteria that leave it to humans to decide, but honestly it's rare. Usually the constraints drive the design from concept down to minute details. Within the constraints and criteria, there's codes and manuals that cover almost everything. It's always seemed to me that software has really suffered from a lack of this approach. Is it the best way to maximize innovation? No, but in some ways, you might be surprised how much placing heavy constraints on a project will drive innovation.