161–170 of 262 posts
Earlier quoted context omitted.
One of the many reasons I'm still at Apple. My manager honors my decisions (sometimes, let's be honest, with gritted teeth). ("People don't leave jobs, they leave managers")
one tactic is forming a group which bullies a manager out of their job. it's depressingly effective and rife within the professional public sector
Earlier quoted context omitted.
We are by and large hired for cleverness, so there’s a lot of selection that makes that true even if undergrads are not far off from average. It would be better if we were hired for wisdom. Don’t confuse cleverness and foolishness. You can be both. But devs aren’t usually the ones treating their reports like children and then acting surprised when their prophecies become self fulfilling. You can blame Taylor for that…
It’s not clever to brag about how smart you are or imply you and your entire cohort are smarter than other occupations. It’s a sign of how much you are the opposite of clever. Additionally the average IQ of software developers is measured to be 110-113. That’s barely above one std of the average so you’re actually wrong. Software devs aren’t particularly clever but a disproportionate number likes to think they are sm…
This is simply an awful thought piece and is wrongheaded. The problem is not collaboration nor feedback. It is the lack of a decider. Deciding by committee is a bad way to run as an org grows. Collaboration is still key. One person needs to be the person who decides. Decides what? That is the trick. The further down you push decision making, the faster things go. But someone is the decider, not a group.
It's not a clear cut thing, definitely helping each other is useful, but like everything there's a balance, and striking it is bot straightforward
> Every time you see collaboration happening, speak up and destroy it. Say “there are too many people involved. X, you are the driver, you decide.” (This is a great way to make friends btw). Corollary for managers: Do not say "it's your call", then once the decision has been made (and you skipped all the meetings pertaining to that decision), comment about how you would have done it differently and then retroactively…
One of many reasons I left Apple. My manager's manager would say stuff like this all the time, and then when I actually made my PR he would basically have me redesign stuff from scratch. It made me dread working on projects because I knew that no matter what I did I would be forced to rewrite it from scratch anyway.
The attitude I like to have is that the author can choose to do the design (doc + approval, or live discussion, some kind of buy in) first or go straight to the PR.
If the design is agreed on first, reviewers would need a really good reason to make the author go back and rethink the design—it happens, sometimes a whole team misses something, but it should be very rare. Usually, there's just implementation things, and ones that are objective improvements or optional. (For project style preferences, there should be a guide to avoid surprises.)
If the author goes straight to a PR, it's an experiment, so they should be willing to throw it away if someone says "did you think about this completely different design (that might be simpler/more robust/whatever)".
This is not the approach suggested by this article, and I'm okay with that. I tend to work on high reliability infrastructure, so quality over velocity, within reason.
> Every time you see collaboration happening, speak up and destroy it. Say “there are too many people involved. X, you are the driver, you decide.” (This is a great way to make friends btw). Corollary for managers: Do not say "it's your call", then once the decision has been made (and you skipped all the meetings pertaining to that decision), comment about how you would have done it differently and then retroactively…
> Every time you see collaboration happening, speak up and destroy it. Say “there are too many people involved. X, you are the driver, you decide.” (This is a great way to make friends btw). Corollary for managers: Do not say "it's your call", then once the decision has been made (and you skipped all the meetings pertaining to that decision), comment about how you would have done it differently and then retroactively…
If you don’t collaborate before it’s shipped and don’t retroactively review after it’s shipped, how do you provide input?
While I don't agree with Charles' (clearly nuts) distaste for sparkling water, I'm happy to see people finally talking about this issue publicly. I've suffered through this at several companies, down to the level of sometimes spending like 3x the time it took to implement the actual feature on answering and 'fixing' pedantic stylistic nitpicks during code reviews. While having a homogenous style is important, I'm sol…
Can't help but think this is human nature. Ask anyone in a relationship if their partner complains about unimportant stuff. With experience and practice you can get past this stuff. so... experienced reviewers.
I can't know how you meant it, but if your partner if complaining about something 5 times a day, you might want to rethink if it's really unimportant, and understand why they care instead of "get past this stuff".
That reminds me of the guys getting dumped after 10 years of marriage complaining they genuinely have no idea why their partner left them.
For example, if a draft is made available for someone else to review, then someone can comment in case they find something wrong that the original author does not (it is also possible that the original author might find something later that was not originally found).