6 ms·

Engineers who won't commit

53 points by kiyanwang 2y ago

CharlieDigital 2y ago
I think author misses some points: 1. Sometimes engineers are right to be non-committal if the non-functional requirements are not yet fully known because the business side simply hasn't really fully scoped their NFRs which can often make a big difference in the design of the system. 2. Many orgs have a poorly managed culture around disagreements on technical design and some folks just don't want to put up with that kind of friction when the difference between using approach A or B is real, but not going to topple the project either way so why waste that energy fighting that kind of battle? EDIT: Simple analogy > Say we must choose where to get dinner. Japanese or Indian. Without constraints, I do not care. But if Antoine and Lin are coming and Antoine has a shellfish allergy while Lin is a vegetarian, I now want to commit because I like their company and Indian is the better choice. Why make a fuss about Japanese or Indian if I do not care unless there is actually a real reason to pick one over the other? Either is fine with me; I just want to go out to dinner and have a good time. I am happy with either Japanese or Indian! Do you see the difference? If Antoine and Lin are not coming, I will eat anywhere; I don't care -- let's have a good time! If Antoine and Lin are coming, I think we should pick Indian because they have requirements that we should consider -- let's have a good time! It's like asking me to choose GCP, Azure, or AWS. Does it really matter if there's no constraint? I can and have delivered systems on each of these platforms. Am I cowardly for not committing and not being a diehard for one of these when there are no NFR's that favor one over the other?
- robertlagrant 2y ago
  > Sometimes engineers are right to be non-committal if the non-functional requirements are not yet fully known because the business side simply hasn't really fully scoped their NFRs which can often make a big difference in the design of the system. Doesn't this necessitate asking the questions to get the NFRs out? You don't need to be non-committal then. Just say "we need answers to these 8 questions before we can estimate, as they will make a massive difference."
  - CharlieDigital 2y ago
    You'll get them...at some point. It may be even at the very end when the customer complains that it doesn't quite work the way they intended and it turns out, they never fully specified exactly how it was supposed to behave! If you haven't experienced this, you haven't truly lived the enterprise software delivery reality.
    - robertlagrant 2y ago
      Of course it can happen that way :) But as an engineer you have to decide on the NFRs if you don't ask anyway, so why not ask them and declare them up front if you don't get an answer? Then you can point to the problem is down the line and say we need X time to increase this NFR.
      - CharlieDigital 2y ago
        Sure, but you've missed my point: in that case, some engineers just don't want to have that debate because there's very little point in expending that energy.
        kikimora 2y ago
        Best strategy would be to declare NFR using engineer’s domain knowledge without waiting for clients to tell them. This is conditioned on engineers knowing domain sufficiently well. Which is a requirement for effective work anyway.
        CharlieDigital 2y ago
        I feel like a broken record now, but once an engineer decides to "declare NFR", then it's a situation where it's one opinion versus another not driven by actual requirements and I contend that this is a point of friction that some engineers just do not have the energy for when there are no real requirements -- just fabricated ones.
- viraptor 2y ago
  > simply hasn't really fully scoped their NFRs which can often make a big difference in the design of the system. "We're scaffolding / not implementing / delaying this part, until X, Y, Z are known." is a completely valid decision to officially make. And it helps with planning and development of related code. "I don't know, because of missing NFRs" is not a decision though.
  - CharlieDigital 2y ago
    > "We're scaffolding / not implementing / delaying this part, until X, Y, Z are known." Isn't that the same thing as "not committing"? I'm very confused.
    - viraptor 2y ago
      "what do we do with this part?" Not committing: "I don't have enough info, don't know". Decision: "We can only finish it once X is known. Until then we assume it behaves like (…). For code that relies on it, we're prioritising flexibility to change over perfect solution at this point. Y is responsible for announcing when X is known."
  - kragen 2y ago
    Generally speaking, "we're scaffolding/not implementing/delaying this part" is something you can do with functional requirements, but not with non-functional requirements. Changing non-functional requirements like security, maintainability, or testability generally requires rewriting the whole system from scratch, incrementally or otherwise.
- kragen 2y ago
  As for "non-functional requirements" ("NFRs") Wikipedia suggests examples: 1. Execution qualities, such as safety, security and usability, which are observable during operation (at run time). 2. Evolution qualities, such as testability, maintainability, extensibility and scalability, which are embodied in the static structure of the system.[5][6] Sometimes "the business side" has the expertise required to define these. Sometimes they don't, and engineers need to do it, using whatever knowledge of the business they have. "The business side" often will not take responsibility if the system is insufficiently testable, maintainable, extensible, scalable, secure, or usable, instead blaming engineering.
- Aurornis 2y ago
  > 1. Sometimes engineers are right to be non-committal if the non-functional requirements are not yet fully known because the business side simply hasn't really fully scoped their NFRs which can often make a big difference in the design of the system. I understand where you’re coming from, but in my experience this only leads to deadlock on both sides with nobody moving forward. The best engineers I learned from will push forward with a decision and also communicate the tradeoffs and consequences upward. This breaks the stalemate and forces the “business side” (which shouldn’t actually be separate from engineering) to either accept the decision or propose an alternative. The game where engineers view themselves as in a standoff with “business side” people and nothing moves forward has been a path to a slow decline everywhere I’ve seen it happen.
  - RHSeeger 2y ago
    This strikes me as parallel to "the best way to get the answer to a question online is to post the wrong answer, and people will flock to correct you".
  - CharlieDigital 2y ago
    Of course you push forward as a team, committal here I take to mean between two or more engineers trying to debate a technical option. Why must every engineer have an opinion on every technical decision if there are no hard requirements? I may only have an opinion if there is a hard requirement. I gave an example below. > Say we must choose where to get dinner. Japanese or Indian. Without constraints, I do not care. But if Antoine and Lin are coming and Antoine has a shellfish allergy while Lin is a vegetarian, I now want to commit because I like their company and Indian is the better choice. Why make a fuss about Japanese or Indian if I do not care unless there is actually a real reason to pick one over the other? I just want to go out to dinner and have a good time otherwise; I am happy with Japanese or Indian! Do you see the difference? If Antoine and Lin are not coming, I will eat anywhere; I don't care -- let's have a good time! If Antoine and Lin are coming, I think we should pick Indian because they have requirements that we should consider -- let's have a good time! It seems pretty clear to me that not every engineer must have an opinion on every technical decision to which they should commit when sometimes, the choice doesn't matter and it's easier to let the individual with a stronger opinion drive the choice because the other option is friction for no reason and expending energy debating made up constraints.
freetime2 2y ago
> Well, it depends: there are many strong technical reasons on each side, so it’s better to keep an open mind and not come down on either side. My heuristic in this case is just to go with whatever option is simpler, and gives us the most flexibility to course correct in the future if we turn out to be wrong. Basically make it clear that in the absence of sufficient data to decide on the best course of action, we are being intentionally non-committal. Then outline what new information would be required for us to make a more informed decision one way or another (e.g. an actual customer asks for the hypothetical feature that we are discussing, or performance is insufficient, etc), and what actions and effort we would need to change course. When put like this, I find that everyone in the room usually ends up pretty satisfied with the plan.
Const-me 2y ago
Some technical decisions aren’t that important. A trivial example, I have very strong preference on using tabs instead of spaces for indentation. However, I don’t force people on my team to also use tabs because I realize that’s subjective, and doesn’t affect the product we’re developing. These white spaces are ignored by the compiler after all. The tricky part is estimating consequences of these technical decisions. If you’re more or less confident in your estimations, and you believe the technical decision being made has severe consequences (not just to the product, in the long run development process is equally important), only then is the time to commit.
- tyleo 2y ago
  > However, I don’t force people on my team to also use tabs Wait a minute. Does that mean you are using mixed tabs and spaces depending on file author? Or are you just saying you start projects using tabs but don’t enforce it for others’ new projects?
  - jiehong 2y ago
    Not using python, then, because this causes useless issues.
- viraptor 2y ago
  I think this article still applies there just in a different way. If: - you're working on a project with other people and - you're at the right level to make such decisions and - people compete with different / conflicting formatting Then it is important that you make A decision. It can be "we're using my preferred style", or "we're using gofmt/rubocop/black/whatever", or something else. But any of them is going to be better than future waste of time in reformatting, merge conflicts and people arguing.
- surajrmal 2y ago
  With style, consistency matters more, so ensuring everyone either uses spaces or tabs but not both is helpful. I don't think being willing to commit means you need to decide on which one is used, unless you are a designated tie breaker and others cannot come to a choice.
pjc50 2y ago
> "If you don’t take a position, you’re tacitly endorsing the decision that eventually gets made" This is important in a lot of situations, not just engineering. Variants of cut-and-choose can be useful here. If you flip a coin to make the decision for you, do you object to its outcome? If so, you've picked the other one. It's also worth having a discussing about responsibility, power, and accountability here. Conventional management structures are supposed to align this, but that rarely corresponds to reality.
dogleash 2y ago
My opinions became trusted in decision making because I spoke up only when I had well-founded thoughts on things I understood. Now that I'm looked to for opinions on a wide breadth of topics, apparently "let's find (or train) someone qualified and ask them instead" is not a decision anyone wants. Telling me to just be as useful as a generalist doesn't work when it was the specialization that made me worth listening to. It's a setup for failure. And I know the platonic ideal of management understands the team has different capacity on different topics and yadda yadda yadda, but I have a job in reality.
- Msurrow 2y ago
  I genuinely curious here, if you are the trusted decision person, is it not accepted if you say “the decision is we do not have enough information at this time to make a decision, thus we need to [research x/do a timeboxed poc/drill down on y part of system/etc]”?
  - dogleash 2y ago
    > is it not accepted I haven't been fired, if that's what you mean. But I also just read an article calling out my non-committal cowardice. I'm OK-enough at managing up these days that you could weasel word around and say it doesn't apply to me. But it's a failure pattern of management that I've seen happen to more than just myself.
- gatorcode 2y ago
  I’ve been in your shoes. I found three options to work (in worst to best order): 1) I become an “overnight expert” at the expense of my work life balance and frankly the system architecture long term 2) Pushed back on management with tangible risks: a rough estimate to implement is XX and we are not confident in the solution so that could result in rework cost or worse long term scalability/maintenance cost. We propose outside (could be another expert on another team) consultation to close the risk gap. 3) We need to reassign resource X who is our most knowledgeable in adjacent tech, this takes them off feature Y and we will do a spike of duration Z to verify our approach. When you do #3 enough your management will appreciate you using existing resources, providing the trade-offs, and you will also up skill that person.
Cthulhu_ 2y ago
I found using "architectural decision records" to be helpful; it's not a panacea and I'm sure there's other approaches, but the gist of it is that you make a document, write down your thought processes, consider the different options (demonstrate you did your homework), and get the team together to proverbially shake hands on it. It's not set in stone; if anything, the writing reflects "what we know right now" about a problem and its possible solutions, but it's a message to the future when either the context of the problem changes, the problem is better understood, the underlying assumptions and/or requirements change, or something changes in the solution. It's both committing to a thing "in the moment", while leaving it open for updating down the line. It's much preferable to someone just picking something because of gut feeling / hype / assertiveness / cool factor which is how a lot of projects end up in the bin after a few years.
- RHSeeger 2y ago
  I tend to do something like this for most tickets I work on (that have choices to be made). I work through all the details and make sure I understand them all, then note what the difference choices are for various things. Where there's a choice to be made that requires "customer" input but that I have a pretty solid idea what the right choice is so am going to move forward on that, I'll make note of it, etc. It also gives me time/space to document ambiguities in the requirements. I am.. overly verbose in tickets. That being said, it's come in handy many times in the past; some of which are me trying to figure out why I made a specific choice.
  - simonw 2y ago
    "I am.. overly verbose in tickets." So am I, and I'm proud of it. I see a GitHub issue thread as effectively infinite storage for the ideas, decisions and research behind a change I make to a codebase. Here's a recent example - 51 comments and they were almost all me talking to myself https://github.com/simonw/llm/issues/617 https://github.com/simonw/llm/issues/617
michaeljx 2y ago
We have 5 different engineering teams in our company. The 4 are being led by benevolent-dictator-type of engineers, the 5th by a person extremely non-commital. This person avoids exerting any technically authority, so as not to disturb the team's balance. All decisions are made democratically, all votes being equal regardless experience/seniority. Same goes when being called for estimates. Two of the 4 teams have become so big and independent, that the dictator-leads no longer need to participate in the d2d operations/decisions, to the point where they now work mostly on individual RnD projects. The other 2 are small specialized teams, whose members have become domain experts in specific areas, to the point that they can talk with the business and move on development, with little need of interaction with their lead, and absolutely no need for a PM/PO layer. The only team that struggles to perform is the one with the non-commital lead. It became so bad, that the current discussion is to dissolve the team, and have it's members/responsibilities be absorbed by the 2 big ones.
- Aurornis 2y ago
  > the 5th by a person extremely non-commital. This person avoids exerting any technically authority, so as not to disturb the team's balance. All decisions are made democratically, all votes being equal regardless experience/seniority. Same goes when being called for estimates. This is a very common failure mode for first-time leaders and managers. They optimize for minimizing conflict and want everyone on the team to like them. A difficult lesson to learn in leadership positions is that you can’t make everyone happy and you can’t avoid every conflict. Hyper-democratic leadership styles don’t work outside of very small and tight knit teams where everyone was already on the same page. Someone needs to pull that person aside for some intense coaching to train them out of the mindset of people-pleasing and into the reality of getting work done. It’s not a fun transition but it needs to be coached. This is one of the turning points where many people realize they don’t want to be in leadership or management roles because the difficult decisions and uncomfortable conversations are in conflict with their personality.
  - michaeljx 2y ago
    Exactly. I think both parties (him and his VP) are now realising that maybe this person will be happier/better suited as an IC
yen223 2y ago
If you have trouble committing to an option, it's usually because the options are equally good as far as you know. There are two ways to go about this: 1. If the stakes are low, you can just pick one option at random and commit to it. 2. If the stakes are high, come up with a way to reduce your uncertainty around the options. Set a time limit, and perform an experiment that will inform your decision. If that experiment doesn't conclusively settle the options, just pick one and commit to it.
- dijit 2y ago
  In general I don't have a problem committing, but there's also some solid rules of thumb that you can follow, for example: "if all else is equal, take the option that leaves you the most opportunity later". However I have also employed Weighted Decision Matrices[0] to a pretty high degree of success if they're undertaken seriously and the outcomes taken as a learning exercise. Ironically when I employed the Weighted Decision Matrix I often didn't like the result, which was equally telling! [0]: https://en.wikipedia.org/wiki/Decision-matrix_method https://en.wikipedia.org/wiki/Decision-matrix_method
- mort96 2y ago
  Also, getting better at intuitively analysing these situations and picking an option is part of what it means to gain experience and become better at what you're doing. If you're doing things right, you will start out finding it difficult to pick an option when you're new (to programming, to a particular domain, to a particular technology, whatever), and as you get better, you 'll develop a "taste" for what seemingly-equivalent solution you prefer.
t0mek 2y ago
Famous example from the pop-culture is Burr vs Hamilton: > If you stand for nothing, Burr, what'll you fall for?
simonw 2y ago
Almost all software engineering systems are reversible. If a decision can be unmade later I find is a lot easier to accept committing to a decision despite not yet being 100% confident it's the best approach. This works in collaborative decisions too: if someone still has doubts, ask them to "disagree and commit" to the new direction but promise them that you'll evaluate if it is working out in a fixed time period - drop something on the calendar in two weeks time for example. Indecision paralysis is much more harmful to a project then picking an option that later turns out to be suboptimal.
- patrickmay 2y ago
  The question "Is this a one-way door or a two-way door?" can eliminate that paralysis in the majority of cases where, as you point out, the decision is reversible.
hakunin 2y ago
I find there's a good way to not commit, slightly different from this article. There's a non-committal way of designing software that I think we should all strive to follow. It's not things like "let's use an ORM so that we can swap the database later" or "let's write abstractions over everything so we can swap everything later". It's more that you're trying to keep the code as simple and static as possible, naively doing the exact business function, and rarely generalizing. There are a few practices I've picked up over the years for non-committal architecture of this kind (for example: doing more at "build" time, passing the functions what they need instead of what you have, keeping IO in shell layer, and a few more). The goal is not to end up with a codebase that has foretold all the possible futures, but that implements just what it needs to do now in the most straightforward way, such that it's easy to read, understand, and change. I think this kind of non-commitment is the ideal to strive for. The less committed you are in this way, the easier it remains the change the codebase as it evolves, the less shackled it is with over-engineered "solutions". It's deceptively hard to do this in practice. Everybody wants to implement their over-engineered "system for doing a thing" layered on top of the programming language. Sometimes we forget that the programming language itself is a great tool for expressing business logic.
InDubioProRubio 2y ago
Passive Non-Comittance (I will need more information, more prediction power, more certainty about future events) ironically is still more expensive, then active Non-Comittance (We just built all the implementation-components in such a way they can be exchanged later).
karmakaze 2y ago
Whenever I face this, in my own analysis or others, I apply the "let's find out" tactic. Instead of doing nothing I'll propose that we do X which I surmise as an option that a) is non-destructive and reversible, b) has a chance of working out. [You can add your own criteria, e.g. fast/easy, simple, etc] At the very least we'll learn something. When someone else is stalling, I'll phrase it something like "Unless someone has specific reasons against investigating X, I propose we prototype it and see where it goes." If still unsure, prototype Y. After that you usually realize there's not much point prototyping yet another an simply choose one and see how far it can go.
hinkley 2y ago
The flip side of this is that engineers who won’t commit aren’t trusted and thus have low status on the development team. It’s easy enough to get promoted over them if they haven’t been Peter Principled yet.
exiguus 2y ago
I strongly support this approach. By voicing my thoughts, including any weaknesses and unknowns, I invite others to contribute their insights. This not only helps to address gaps in my knowledge but also encourages a collaborative environment where other engineers can engage in discussion and decision-making. I believe this dynamic is a sign of a healthy workspace, where open communication and teamwork are valued.
waltercool 2y ago
[dead]

53 points by kiyanwang 2y ago

I think author misses some points: 1. Sometimes engineers are right to be non-committal if the non-functional requirements are not yet fully known because the business side simply hasn't really fully scoped their NFRs which can often make a big difference in the design of the system. 2. Many orgs have a poorly managed culture around disagreements on technical design and some folks just don't want to put up with that kind of friction when the difference between using approach A or B is real, but not going to topple the project either way so why waste that energy fighting that kind of battle? EDIT: Simple analogy > Say we must choose where to get dinner. Japanese or Indian. Without constraints, I do not care. But if Antoine and Lin are coming and Antoine has a shellfish allergy while Lin is a vegetarian, I now want to commit because I like their company and Indian is the better choice. Why make a fuss about Japanese or Indian if I do not care unless there is actually a real reason to pick one over the other? Either is fine with me; I just want to go out to dinner and have a good time. I am happy with either Japanese or Indian! Do you see the difference? If Antoine and Lin are not coming, I will eat anywhere; I don't care -- let's have a good time! If Antoine and Lin are coming, I think we should pick Indian because they have requirements that we should consider -- let's have a good time! It's like asking me to choose GCP, Azure, or AWS. Does it really matter if there's no constraint? I can and have delivered systems on each of these platforms. Am I cowardly for not committing and not being a diehard for one of these when there are no NFR's that favor one over the other?

robertlagrant 2y ago
> Sometimes engineers are right to be non-committal if the non-functional requirements are not yet fully known because the business side simply hasn't really fully scoped their NFRs which can often make a big difference in the design of the system. Doesn't this necessitate asking the questions to get the NFRs out? You don't need to be non-committal then. Just say "we need answers to these 8 questions before we can estimate, as they will make a massive difference."
- CharlieDigital 2y ago
  You'll get them...at some point. It may be even at the very end when the customer complains that it doesn't quite work the way they intended and it turns out, they never fully specified exactly how it was supposed to behave! If you haven't experienced this, you haven't truly lived the enterprise software delivery reality.
  - robertlagrant 2y ago
    Of course it can happen that way :) But as an engineer you have to decide on the NFRs if you don't ask anyway, so why not ask them and declare them up front if you don't get an answer? Then you can point to the problem is down the line and say we need X time to increase this NFR.
    - CharlieDigital 2y ago
      Sure, but you've missed my point: in that case, some engineers just don't want to have that debate because there's very little point in expending that energy.
      - kikimora 2y ago
        Best strategy would be to declare NFR using engineer’s domain knowledge without waiting for clients to tell them. This is conditioned on engineers knowing domain sufficiently well. Which is a requirement for effective work anyway.
        CharlieDigital 2y ago
        I feel like a broken record now, but once an engineer decides to "declare NFR", then it's a situation where it's one opinion versus another not driven by actual requirements and I contend that this is a point of friction that some engineers just do not have the energy for when there are no real requirements -- just fabricated ones.
viraptor 2y ago
> simply hasn't really fully scoped their NFRs which can often make a big difference in the design of the system. "We're scaffolding / not implementing / delaying this part, until X, Y, Z are known." is a completely valid decision to officially make. And it helps with planning and development of related code. "I don't know, because of missing NFRs" is not a decision though.
- CharlieDigital 2y ago
  > "We're scaffolding / not implementing / delaying this part, until X, Y, Z are known." Isn't that the same thing as "not committing"? I'm very confused.
  - viraptor 2y ago
    "what do we do with this part?" Not committing: "I don't have enough info, don't know". Decision: "We can only finish it once X is known. Until then we assume it behaves like (…). For code that relies on it, we're prioritising flexibility to change over perfect solution at this point. Y is responsible for announcing when X is known."
- kragen 2y ago
  Generally speaking, "we're scaffolding/not implementing/delaying this part" is something you can do with functional requirements, but not with non-functional requirements. Changing non-functional requirements like security, maintainability, or testability generally requires rewriting the whole system from scratch, incrementally or otherwise.
kragen 2y ago
As for "non-functional requirements" ("NFRs") Wikipedia suggests examples: 1. Execution qualities, such as safety, security and usability, which are observable during operation (at run time). 2. Evolution qualities, such as testability, maintainability, extensibility and scalability, which are embodied in the static structure of the system.[5][6] Sometimes "the business side" has the expertise required to define these. Sometimes they don't, and engineers need to do it, using whatever knowledge of the business they have. "The business side" often will not take responsibility if the system is insufficiently testable, maintainable, extensible, scalable, secure, or usable, instead blaming engineering.
Aurornis 2y ago
> 1. Sometimes engineers are right to be non-committal if the non-functional requirements are not yet fully known because the business side simply hasn't really fully scoped their NFRs which can often make a big difference in the design of the system. I understand where you’re coming from, but in my experience this only leads to deadlock on both sides with nobody moving forward. The best engineers I learned from will push forward with a decision and also communicate the tradeoffs and consequences upward. This breaks the stalemate and forces the “business side” (which shouldn’t actually be separate from engineering) to either accept the decision or propose an alternative. The game where engineers view themselves as in a standoff with “business side” people and nothing moves forward has been a path to a slow decline everywhere I’ve seen it happen.
- RHSeeger 2y ago
  This strikes me as parallel to "the best way to get the answer to a question online is to post the wrong answer, and people will flock to correct you".
- CharlieDigital 2y ago
  Of course you push forward as a team, committal here I take to mean between two or more engineers trying to debate a technical option. Why must every engineer have an opinion on every technical decision if there are no hard requirements? I may only have an opinion if there is a hard requirement. I gave an example below. > Say we must choose where to get dinner. Japanese or Indian. Without constraints, I do not care. But if Antoine and Lin are coming and Antoine has a shellfish allergy while Lin is a vegetarian, I now want to commit because I like their company and Indian is the better choice. Why make a fuss about Japanese or Indian if I do not care unless there is actually a real reason to pick one over the other? I just want to go out to dinner and have a good time otherwise; I am happy with Japanese or Indian! Do you see the difference? If Antoine and Lin are not coming, I will eat anywhere; I don't care -- let's have a good time! If Antoine and Lin are coming, I think we should pick Indian because they have requirements that we should consider -- let's have a good time! It seems pretty clear to me that not every engineer must have an opinion on every technical decision to which they should commit when sometimes, the choice doesn't matter and it's easier to let the individual with a stronger opinion drive the choice because the other option is friction for no reason and expending energy debating made up constraints.

freetime2 2y ago

> Well, it depends: there are many strong technical reasons on each side, so it’s better to keep an open mind and not come down on either side. My heuristic in this case is just to go with whatever option is simpler, and gives us the most flexibility to course correct in the future if we turn out to be wrong. Basically make it clear that in the absence of sufficient data to decide on the best course of action, we are being intentionally non-committal. Then outline what new information would be required for us to make a more informed decision one way or another (e.g. an actual customer asks for the hypothetical feature that we are discussing, or performance is insufficient, etc), and what actions and effort we would need to change course. When put like this, I find that everyone in the room usually ends up pretty satisfied with the plan.

Const-me 2y ago

Some technical decisions aren’t that important. A trivial example, I have very strong preference on using tabs instead of spaces for indentation. However, I don’t force people on my team to also use tabs because I realize that’s subjective, and doesn’t affect the product we’re developing. These white spaces are ignored by the compiler after all. The tricky part is estimating consequences of these technical decisions. If you’re more or less confident in your estimations, and you believe the technical decision being made has severe consequences (not just to the product, in the long run development process is equally important), only then is the time to commit.

tyleo 2y ago
> However, I don’t force people on my team to also use tabs Wait a minute. Does that mean you are using mixed tabs and spaces depending on file author? Or are you just saying you start projects using tabs but don’t enforce it for others’ new projects?
- jiehong 2y ago
  Not using python, then, because this causes useless issues.
viraptor 2y ago
I think this article still applies there just in a different way. If: - you're working on a project with other people and - you're at the right level to make such decisions and - people compete with different / conflicting formatting Then it is important that you make A decision. It can be "we're using my preferred style", or "we're using gofmt/rubocop/black/whatever", or something else. But any of them is going to be better than future waste of time in reformatting, merge conflicts and people arguing.
surajrmal 2y ago
With style, consistency matters more, so ensuring everyone either uses spaces or tabs but not both is helpful. I don't think being willing to commit means you need to decide on which one is used, unless you are a designated tie breaker and others cannot come to a choice.

pjc50 2y ago

> "If you don’t take a position, you’re tacitly endorsing the decision that eventually gets made" This is important in a lot of situations, not just engineering. Variants of cut-and-choose can be useful here. If you flip a coin to make the decision for you, do you object to its outcome? If so, you've picked the other one. It's also worth having a discussing about responsibility, power, and accountability here. Conventional management structures are supposed to align this, but that rarely corresponds to reality.

dogleash 2y ago

My opinions became trusted in decision making because I spoke up only when I had well-founded thoughts on things I understood. Now that I'm looked to for opinions on a wide breadth of topics, apparently "let's find (or train) someone qualified and ask them instead" is not a decision anyone wants. Telling me to just be as useful as a generalist doesn't work when it was the specialization that made me worth listening to. It's a setup for failure. And I know the platonic ideal of management understands the team has different capacity on different topics and yadda yadda yadda, but I have a job in reality.

Msurrow 2y ago
I genuinely curious here, if you are the trusted decision person, is it not accepted if you say “the decision is we do not have enough information at this time to make a decision, thus we need to [research x/do a timeboxed poc/drill down on y part of system/etc]”?
- dogleash 2y ago
  > is it not accepted I haven't been fired, if that's what you mean. But I also just read an article calling out my non-committal cowardice. I'm OK-enough at managing up these days that you could weasel word around and say it doesn't apply to me. But it's a failure pattern of management that I've seen happen to more than just myself.
gatorcode 2y ago
I’ve been in your shoes. I found three options to work (in worst to best order): 1) I become an “overnight expert” at the expense of my work life balance and frankly the system architecture long term 2) Pushed back on management with tangible risks: a rough estimate to implement is XX and we are not confident in the solution so that could result in rework cost or worse long term scalability/maintenance cost. We propose outside (could be another expert on another team) consultation to close the risk gap. 3) We need to reassign resource X who is our most knowledgeable in adjacent tech, this takes them off feature Y and we will do a spike of duration Z to verify our approach. When you do #3 enough your management will appreciate you using existing resources, providing the trade-offs, and you will also up skill that person.

Cthulhu_ 2y ago

I found using "architectural decision records" to be helpful; it's not a panacea and I'm sure there's other approaches, but the gist of it is that you make a document, write down your thought processes, consider the different options (demonstrate you did your homework), and get the team together to proverbially shake hands on it. It's not set in stone; if anything, the writing reflects "what we know right now" about a problem and its possible solutions, but it's a message to the future when either the context of the problem changes, the problem is better understood, the underlying assumptions and/or requirements change, or something changes in the solution. It's both committing to a thing "in the moment", while leaving it open for updating down the line. It's much preferable to someone just picking something because of gut feeling / hype / assertiveness / cool factor which is how a lot of projects end up in the bin after a few years.

RHSeeger 2y ago
I tend to do something like this for most tickets I work on (that have choices to be made). I work through all the details and make sure I understand them all, then note what the difference choices are for various things. Where there's a choice to be made that requires "customer" input but that I have a pretty solid idea what the right choice is so am going to move forward on that, I'll make note of it, etc. It also gives me time/space to document ambiguities in the requirements. I am.. overly verbose in tickets. That being said, it's come in handy many times in the past; some of which are me trying to figure out why I made a specific choice.
- simonw 2y ago
  "I am.. overly verbose in tickets." So am I, and I'm proud of it. I see a GitHub issue thread as effectively infinite storage for the ideas, decisions and research behind a change I make to a codebase. Here's a recent example - 51 comments and they were almost all me talking to myself https://github.com/simonw/llm/issues/617 https://github.com/simonw/llm/issues/617

michaeljx 2y ago

We have 5 different engineering teams in our company. The 4 are being led by benevolent-dictator-type of engineers, the 5th by a person extremely non-commital. This person avoids exerting any technically authority, so as not to disturb the team's balance. All decisions are made democratically, all votes being equal regardless experience/seniority. Same goes when being called for estimates. Two of the 4 teams have become so big and independent, that the dictator-leads no longer need to participate in the d2d operations/decisions, to the point where they now work mostly on individual RnD projects. The other 2 are small specialized teams, whose members have become domain experts in specific areas, to the point that they can talk with the business and move on development, with little need of interaction with their lead, and absolutely no need for a PM/PO layer. The only team that struggles to perform is the one with the non-commital lead. It became so bad, that the current discussion is to dissolve the team, and have it's members/responsibilities be absorbed by the 2 big ones.

Aurornis 2y ago
> the 5th by a person extremely non-commital. This person avoids exerting any technically authority, so as not to disturb the team's balance. All decisions are made democratically, all votes being equal regardless experience/seniority. Same goes when being called for estimates. This is a very common failure mode for first-time leaders and managers. They optimize for minimizing conflict and want everyone on the team to like them. A difficult lesson to learn in leadership positions is that you can’t make everyone happy and you can’t avoid every conflict. Hyper-democratic leadership styles don’t work outside of very small and tight knit teams where everyone was already on the same page. Someone needs to pull that person aside for some intense coaching to train them out of the mindset of people-pleasing and into the reality of getting work done. It’s not a fun transition but it needs to be coached. This is one of the turning points where many people realize they don’t want to be in leadership or management roles because the difficult decisions and uncomfortable conversations are in conflict with their personality.
- michaeljx 2y ago
  Exactly. I think both parties (him and his VP) are now realising that maybe this person will be happier/better suited as an IC

yen223 2y ago

If you have trouble committing to an option, it's usually because the options are equally good as far as you know. There are two ways to go about this: 1. If the stakes are low, you can just pick one option at random and commit to it. 2. If the stakes are high, come up with a way to reduce your uncertainty around the options. Set a time limit, and perform an experiment that will inform your decision. If that experiment doesn't conclusively settle the options, just pick one and commit to it.

dijit 2y ago
In general I don't have a problem committing, but there's also some solid rules of thumb that you can follow, for example: "if all else is equal, take the option that leaves you the most opportunity later". However I have also employed Weighted Decision Matrices[0] to a pretty high degree of success if they're undertaken seriously and the outcomes taken as a learning exercise. Ironically when I employed the Weighted Decision Matrix I often didn't like the result, which was equally telling! [0]: https://en.wikipedia.org/wiki/Decision-matrix_method https://en.wikipedia.org/wiki/Decision-matrix_method
mort96 2y ago
Also, getting better at intuitively analysing these situations and picking an option is part of what it means to gain experience and become better at what you're doing. If you're doing things right, you will start out finding it difficult to pick an option when you're new (to programming, to a particular domain, to a particular technology, whatever), and as you get better, you 'll develop a "taste" for what seemingly-equivalent solution you prefer.

t0mek 2y ago

Famous example from the pop-culture is Burr vs Hamilton: > If you stand for nothing, Burr, what'll you fall for?

simonw 2y ago

Almost all software engineering systems are reversible. If a decision can be unmade later I find is a lot easier to accept committing to a decision despite not yet being 100% confident it's the best approach. This works in collaborative decisions too: if someone still has doubts, ask them to "disagree and commit" to the new direction but promise them that you'll evaluate if it is working out in a fixed time period - drop something on the calendar in two weeks time for example. Indecision paralysis is much more harmful to a project then picking an option that later turns out to be suboptimal.

patrickmay 2y ago
The question "Is this a one-way door or a two-way door?" can eliminate that paralysis in the majority of cases where, as you point out, the decision is reversible.

hakunin 2y ago

I find there's a good way to not commit, slightly different from this article. There's a non-committal way of designing software that I think we should all strive to follow. It's not things like "let's use an ORM so that we can swap the database later" or "let's write abstractions over everything so we can swap everything later". It's more that you're trying to keep the code as simple and static as possible, naively doing the exact business function, and rarely generalizing. There are a few practices I've picked up over the years for non-committal architecture of this kind (for example: doing more at "build" time, passing the functions what they need instead of what you have, keeping IO in shell layer, and a few more). The goal is not to end up with a codebase that has foretold all the possible futures, but that implements just what it needs to do now in the most straightforward way, such that it's easy to read, understand, and change. I think this kind of non-commitment is the ideal to strive for. The less committed you are in this way, the easier it remains the change the codebase as it evolves, the less shackled it is with over-engineered "solutions". It's deceptively hard to do this in practice. Everybody wants to implement their over-engineered "system for doing a thing" layered on top of the programming language. Sometimes we forget that the programming language itself is a great tool for expressing business logic.

InDubioProRubio 2y ago

Passive Non-Comittance (I will need more information, more prediction power, more certainty about future events) ironically is still more expensive, then active Non-Comittance (We just built all the implementation-components in such a way they can be exchanged later).

karmakaze 2y ago

Whenever I face this, in my own analysis or others, I apply the "let's find out" tactic. Instead of doing nothing I'll propose that we do X which I surmise as an option that a) is non-destructive and reversible, b) has a chance of working out. [You can add your own criteria, e.g. fast/easy, simple, etc] At the very least we'll learn something. When someone else is stalling, I'll phrase it something like "Unless someone has specific reasons against investigating X, I propose we prototype it and see where it goes." If still unsure, prototype Y. After that you usually realize there's not much point prototyping yet another an simply choose one and see how far it can go.

hinkley 2y ago

The flip side of this is that engineers who won’t commit aren’t trusted and thus have low status on the development team. It’s easy enough to get promoted over them if they haven’t been Peter Principled yet.

exiguus 2y ago

I strongly support this approach. By voicing my thoughts, including any weaknesses and unknowns, I invite others to contribute their insights. This not only helps to address gaps in my knowledge but also encourages a collaborative environment where other engineers can engage in discussion and decision-making. I believe this dynamic is a sign of a healthy workspace, where open communication and teamwork are valued.

waltercool 2y ago

[dead]