I think the real problem here is "decision making" as opposed to "collaboration"
I can't think of a single time where having someone else review my work or give me feedback is a meaningfully bad thing. It's an opportunity to learn. But getting feedback is different to making the final decision.
Instead, the real problem is the either 1) lack of knowing who makes the final decision or 2) requiring everyone must agree to a final decision. You will move a lot faster if you know who the final decision maker is, ideally have fewer (or only one person) making that final decision, and encourage people to make decisions quickly (most decisions are reversible anyway)
This is the key insight for me about this post, and I fully agree with you.
No collaboration means less opportunities for learning from people (even the post admits!) that are "better at what you are doing than you are", which imo stunts personal growth.
Decision makers need to be clearly appointed, accountable, and empowered to follow through. But that power then also comes with listening to feedback from all relevant parties. As long as they trust that they're being listened to, they don't get a say in the actual decision making process themselves.
I also agree about taking reversible decisions faster.
Another point I deeply disagree with is
> collaboration forces the driver to slow down and explain stuff (background, context, their thinking).
Yeah, and that's a good thing. It forces them to properly think through their thoughts, if they can't explain what they want to do clearly and why, it probably shouldn't be done. Quality goes up by slowing down.
> if they can't explain what they want to do clearly and why, it probably shouldn't be done. Quality goes up by slowing down.
I kind of agree. Without what you describe, teams often get lost. But I’ve also seen that approach keep teams stuck in comfortable local minima. Sometimes you’ve got to take risks.
People need agency, and feel empowered to go forward. I'm not arguing against that interpretation of the post.
But having agency doesn't equal a lack of accountability, or being able to explain what you're doing.
In the end, it's a tricky balance between moving fast and slow, which is why no one has found the perfect, long-term viable solution yet.
Not necessarily. You get biggest insights about quality after you ship, not before. Slowing down means you ship later, which means the insights are delayed. Unless you work in a rocket industry et all, slowing down will be detrimental to the quality.
> Instead, the real problem is the either 1) lack of knowing who makes the final decision or 2) requiring everyone must agree to a final decision. You will move a lot faster if you know who the final decision maker is, ideally have fewer (or only one person) making that final decision, and encourage people to make decisions quickly (most decisions are reversible anyway)
I'll add one more to this - not knowing how set in stone any decision is. I'm a PM, and I'm often the one charged with making the final call on many things. One thing I've often seen go wrong is a PM or an exec will say something like, "we should do x" in some review, and the team moves heaven and earth to achieve x, only to find out later it was just a drive by comment from said person, not something they deeply cared about.
One thing I've started doing is adding a GAF score (Give A Fuck score) to many of my decisions that have engineering ramifications, especially for anything that affects platform or architectural aspects. IE I might say something like, "this needs to have less than a 200ms round trip, this is a GAF-10" if something is direly important, and if we should commit significant engineering effort to making the decision happen. Or I might say, "I think we should go with approach A instead of B, but this is a GAF-2, so come back to me if you feel like A becomes untennable".
This way the team can move forward, but wont overindex on decisions that become bad decisions.
> I can't think of a single time where having someone else review my work or give me feedback is a meaningfully bad thing
I have ample examples, unfortunately. I had a coworker whom I liked as a person, but had a nasty habit of using PRs as a way to hijack all decision making. He’d leave PR feedback for his personal preferences and mark them as “changes requested.”
Everyone feels like an asshole giving an approval when someone has requested changes, so you had to comply with all of his preferences if you wanted to merge your code.
I’ve had several companies where I submitted a PR and had someone say, “You’re guarding against an edge case that won’t happen. This is over engineered. Remove it.”
And it made it less than a week in production before we hit the edge case that I’d been forced to neglect.
I had a team come to me with a request, so I built it. They were thrilled. Then another engineer was like, “I don’t like (some technical detail). You need to change (major architectural decision).”
I gave the re-architected version to the team who requested it and they said, “Wait, I loved what you built before. What is this? I don’t want this!”
This post resonated with me pretty hard. Hire good people and deputize them to make decisions. You’ll end up with something good more often than not. I’ve never seen design-by-committee produce a great product.
I’ve had too many experiences with seeing decent contributions get worse and worse as they go through successive rounds of feedback.
> I’ve had too many experiences with seeing decent contributions get worse and worse as they go through successive rounds of feedback.
This is a great observation. Having a PR feedback process that involves everyone commenting on every tiny decision is a guaranteed way to end up with "design by committee" syndrome. Everyone feels obligated to push their little agenda, no matter how insignificant it may be. The end result is what the original article tries to explain: When everyone is responsible for every PR, no one is really responsible for any PR. The quality and suitability of the code are not proportional to the volume of feedback the pull request receives. There is a sweet spot, and beyond that, quality and development velocity deteriorate quickly
The other is knowing what the collaboration brings to the table and shaping the rules of engagement to fit that expectation. Sometimes you collaborate with SMEs; they bring the domain knowledge - you don't, but you understand the goal better than them. Sometimes you are creating or refining the corporate strategy based on the actions from individual projects or partners; you are learning ground realities from them. Sometimes you need help from others to improve your take on a subject.
In each of these cases, you have to be clear about what you expect from the collaborators (and motivate them to contribute). Without being clear on what the collaboration is about and what they get in return is the number one killer of collaborative projects even though there is no ill-intent anywhere.
One of the things that good managers/leaders do is not "make decisions", ie do it this way, but increase the number of decisions that can be made autonomously.
THat could be giving guidance; The product is aimed at x, which means that feature y will need to happen before feature z
Or a framework; We choose to prioritise small throwaway prototypes vs ground up intensive planning
or just taking away decision dimensions: buy this software in and concentrate on this other thing
The thing is: once you have feedback, you have to act on it. Ignoring the feedback is dangerous unless sanctioned by higher leadership.
This is our nature, and the blog does hit this point where we default to collaborate.
There is of course a better way. A senior employee should be more intentional about feedback e.g. whether can be done later, put it on a backlog, or must address right now. A junior employee should be intentional about what specific feedback they need.
I agree with your comment that getting feedback is different to making the final decision.
But I'm not sure the real problem fits solely in your two buckets.
I've been in recent situations where there is a less-technical person charged with making the "final decision" and a lot of other senior people in the room who don't all /have/ to agree. But the degree of "why not do it this way?" questioning+discussion will grow with the number of meeting participants (and/or worse, the # of meetings before a decision is made if it is not settled in one meeting and then new stakeholders arrive and have their own thrashing out to do.) And even with one final decider, you can end up a bit still with "Design By Committee" decisions when the final decider goes along with the group consensus or doesn't have a strong point of view on an issue.
> I can't think of a single time where having someone else review my work or give me feedback is a meaningfully bad thing. It's an opportunity to learn. But getting feedback is different to making the final decision.
Getting measured feedback is good when it’s coming from a place of genuine helpfulness.
I’ve been in multiple companies where, for various reasons, feedback rounds turned into a game of being maximally contrarian. It didn’t matter what you proposed, a few people would make it their mission to fabricate some objections and come up with reasons to rewrite it into something else. It was a way of exerting control and stealing ownership/credit by replacing others’ ideas with your own.
The most frustrating situations were when you’d rewrite something to accommodate some staff engineer or manager, then at the feedback session for the review they would complain and propose your original version, seemingly forgetting that they had rejected it once previously.
100%. Three decision-making styles are dictators (make decisions without feedback), arbitrators (listen to feedback, then the arbitrator makes the call), and mediators (mediators guide discussion until consensus is reached). Arbitrators are far and away the most successful and best liked. The key insight is that a culture of arbitration is not natural and must be intentionally built.
We built the Shell Plugin Store into Fig[https://fig.io] to solve a lot of the problems mentioned in this thread. Namely:
* Plugins are hard to install/uninstall
* Plugins are hard to customise once installed
* Plugins add bloat and/or degrade performance in shell load time
* It's hard to find plugins in the first place (there is not centralised directory)
* It's hard to sync plugins and configurations across devices
In Fig, adding a plugin is easy as clicking a button. And if you have issues with it, you can uninstall in a click too
Founder of Fig here. For context, Fig integrates with your existing terminal and shell.
A few things we've found:
1. Developers are understandably opinionated about their terminal/shell setup. It's a matter of personal productivity.
2. We have noticed a general trend of more terminal use happening in IDE, not a standalone terminal.
3. Most terminal "collaboration" happens asynchronously not synchronously (e.g. shared scripts, CLIs, secrets etc as opposed to live terminal sharing)
4. Most of the collaboration happens at the shell level not the terminal level
Given the above, we made the conscious conscious decision not to build our own terminal.
> We have noticed a general trend of more terminal use happening in IDE, not a standalone terminal.
This. I barely use terminal outside of Jetbrains, and heard similar things from other devs.
And people who live in vim/emacs (I used to live in vim)- I would be surprised if they'd pickup something that might interfere with their setup, like tmux or special plugins etc. (forcing login stuff aside- assuming that'll be removed at some point)
But maybe warp folks will find a way to play nice with everything, or be simply too useful to not use.
This Google Trend graph shows an increase popularity. The increase has been fairly linear since 2014 but there were notable spikes in late 2021 and early 2022
Agreed. Nix always means Nix Package Manager unless NixOS is specified. Its hard to distinguish `Nix` from `Nix package manager` in google trends though, so the "NixOS" trendline might be the best proxy for popularity of the entire ecosystem.
RegExr is my go to tool for testing regex. It’s always been able to solve my needs and I’ve never had any need to change. In saying that, I’ve always wondered if regexr is missing out on something that other regex build/test tools have?
I typically use Regex101. It's been good enough for my needs and I'm just used to it at this point. Looking at RegExr, it seems like the only big difference is that Regex101 supports substitution, though I think I've only used it once.
Ah, I see it now. Usually when I do replace/substitution it's in a larger project so it's not a feature I typically use on the site. Most of my Regex101 use is just figuring out why a regex I wrote isn't executing like I expected.
I normally use the replace/substitution in situations such as:
I have list of, say, 1000+ things/rows in a single column. I want to put them in a single line and separate by comma. It is is pretty easy to go there and substitute \n for ", ".
That said, that's also doable in a text editor, but I like that I can visualize the pattern and results more easily.
- code generator, with support for a lot of languages,
- a complete quick reference with examples,
- an extensive regex library,
- a regex quiz for "golfing" and learning purposes,
Perhaps, most importantly, it runs entirely client side and does not submit any information to the server unless you hit save (which returns a delete link to remove all data). You can even run the website and (most) of its features offline.
Regexr submits all input to the server for processing.
I use regex101.com, that looks a lot like RegExr. I remember using RegExr at some point, and I think I default to regex101 just because the name is a bit easier to remember. I'll try to remember to switch to RegExr since it's open source.
But also just to clarify, the intention for this post was how to fix this issue if it had already occurred NOT a "how to install brew correctly" guide.
If the issue had occurred, you wouldn't need to run the eval command again, it would have already been run 1,000 times from your .zprofile. Hence I suggest just to delete all references of it then add back one.
But I do take your point that my post could also have been seen as ambiguous and hence added in your suggested changes.
I can't think of a single time where having someone else review my work or give me feedback is a meaningfully bad thing. It's an opportunity to learn. But getting feedback is different to making the final decision.
Instead, the real problem is the either 1) lack of knowing who makes the final decision or 2) requiring everyone must agree to a final decision. You will move a lot faster if you know who the final decision maker is, ideally have fewer (or only one person) making that final decision, and encourage people to make decisions quickly (most decisions are reversible anyway)