191–200 of 262 posts
Nearly Everything the author suggests to do to root out collaboration is collaboration… > So if collaboration is your enemy, how do you defeat it? Here’s what we say: > Default to shipping. Pull requests > issues > Slack messages. This seems orthogonal to collaboration…creating unnecessary issues or messaging people when you already have the solution isn’t collaboration. It’s just being annoying (or maybe an overbear…
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…
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.
I wrote a book about GitHub a while back. I interviewed a bunch of GitHub engineers. One comment was really fascinating: at least some teams required the engineer to write up an empty PR (with zero code) about how they were going to do things before writing any code. The team would need to sign off on that PR before any "work" was done. Can anyone describe that in any way other than collaboration? But, that's really…
> Getting things done is an important metric. The older and more jaded I get, the more I realize this is just not true. The most important metric is the meetings and visibility, for a larger org. If you just get things done, the effort won't be perceived or understood. . If you just have meeting about what you did , they'll be forgotten the next day, because it's some complicated detail that can't be bothered with. I…
Earlier quoted context omitted.
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.
> their partner complains about unimportant stuff. 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.
communication = both parties learning to communicate in effective ways
"tab stops might seem unimportant, but I can read and review your code easier"
"Ok I see your concern and will set up my editor"
"toilet seat seems unimportant, but if I fall in in the middle of the night, it will disturb both of us"
:)
The author talks about having a clear bias for action (a great thing!) but in the process throws the baby out with the bathwater. Without collaboration you'll end up with silos, overconfident decision-makers, and all sorts of preventable production issues, all in the name of avoiding the dirty C word. How about following the approach of pragmatism and finding a solid middle ground that achieves the best results longt…
For the other extreme, the largest issue I've seen is integration. You make two different systems with no plan on how they integrate. Neither team really takes the time to make them talk properly. That's where some agreed upon architecture helps.
I wrote a book about GitHub a while back. I interviewed a bunch of GitHub engineers. One comment was really fascinating: at least some teams required the engineer to write up an empty PR (with zero code) about how they were going to do things before writing any code. The team would need to sign off on that PR before any "work" was done. Can anyone describe that in any way other than collaboration? But, that's really…
> Getting things done is an important metric. The older and more jaded I get, the more I realize this is just not true. The most important metric is the meetings and visibility, for a larger org. If you just get things done, the effort won't be perceived or understood. . If you just have meeting about what you did , they'll be forgotten the next day, because it's some complicated detail that can't be bothered with. I…
Well we can divide it in 4 ways:
- the "sales engineer" (not a literal sales enginer, but one who wants to sell themself) wants to maximize visibility.
- the startup engieer wants to pitch just enough, but mostly wants to ship
- the craftman engineer (or the researcher) wants to get things done "right"
- the blue collar engineer wants to check off tickets.
Your metrics of success will vary, and some engineers are more punished in some spaces than others.you'll need different skills to navigate depending on your environment
I wrote a book about GitHub a while back. I interviewed a bunch of GitHub engineers. One comment was really fascinating: at least some teams required the engineer to write up an empty PR (with zero code) about how they were going to do things before writing any code. The team would need to sign off on that PR before any "work" was done. Can anyone describe that in any way other than collaboration? But, that's really…
> Getting things done is an important metric. The older and more jaded I get, the more I realize this is just not true. The most important metric is the meetings and visibility, for a larger org. If you just get things done, the effort won't be perceived or understood. . If you just have meeting about what you did , they'll be forgotten the next day, because it's some complicated detail that can't be bothered with. I…
You are very right to call out that in a corporate environment getting things done is judged by the eye of the beholder. This, imho, makes this article even more naive because posthog is pretending they don't do that, and no organization is immune to it.
Ironically, GitHub started having lots of problems when they enbraced the holocracy, i.e. flat management. No one was in charge and no amount of "empty PRs" as I described above could mitigate the vacuum of leadership.
That this article made it past posthog's leadership means they might be having a leadership crisis.
I wrote a book about GitHub a while back. I interviewed a bunch of GitHub engineers. One comment was really fascinating: at least some teams required the engineer to write up an empty PR (with zero code) about how they were going to do things before writing any code. The team would need to sign off on that PR before any "work" was done. Can anyone describe that in any way other than collaboration? But, that's really…
I worked on a team that did something like that for important stuff. (We didn't bother for the relatively routine or uncontroversial changes.) Although in our case we did it in a team meeting rather than asynchronously. It really was horrendously valuable. Many, many times someone would save a their teammate an ungodly amount of time by pointing out an easier way to do something. It was a big complex system so natura…
I wrote a book about GitHub a while back. I interviewed a bunch of GitHub engineers. One comment was really fascinating: at least some teams required the engineer to write up an empty PR (with zero code) about how they were going to do things before writing any code. The team would need to sign off on that PR before any "work" was done. Can anyone describe that in any way other than collaboration? But, that's really…
i get preplanning big picture architecture or strategy, but i CANNOT plan out the actual code i write. i'm not sure if i just develop deficient mental models of the codebase, but my process for figuring out what to build is to just sit down and build it. my process is very iterative. lots of stubbing things out and working backwards (if i need this function to return an X, it needs args A and B which means it might b…
Writing things down takes a lot more time than you think. It is hard work. You get better with practice.
You would find, if you were given the time, or permitted yourself to have that time, that you would find all the skills you have accumulated up to this point would converge into that plan. There is a very exciting zen you get into writing things down and you can think about the architecture and the people and the teams involved, and it's a very different thing to create. And very satisfying.
Then you'll be a senior engineer.
The author talks about having a clear bias for action (a great thing!) but in the process throws the baby out with the bathwater. Without collaboration you'll end up with silos, overconfident decision-makers, and all sorts of preventable production issues, all in the name of avoiding the dirty C word. How about following the approach of pragmatism and finding a solid middle ground that achieves the best results longt…
Why not just: ship it, get feedback from actual usage, iterate.