3 ms·

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 engine

by xrd 11mo ago

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 smart collaboration and not in progress collaboration. Getting things done is an important metric. Getting the right things done is much harder to measure and I think the hive mind helps a lot with this. If you have good writing skills and can communicate well about what you are working on, feedback and collaboration can be fast and effective. And, is the only barrier to tunnel vision. You cannot be a good engineer without some kind of self absorbed focus on a problem, and you can easily lose sight of the forest in the trees when doing that. Without collaboration it is unlikely you can pull yourself at the optimal time. "Perseverance bias" or "sunk cost fallacy" and "cognitive entrenchment" are not mentioned in the article, but they should have been. We've lost focus on the importance of good writing skills and good communication skills. AI is going to make that so much worse. If you can effectively communicate in progress tasks, many of the collaboration problems described here can be avoided.

bunderbunder 11mo ago
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 naturally none of us could be expected to know every nook and cranny.
- xrd 11mo ago
  I've been fighting for this approach for ten years now. I can divide organizations into two camps. One will see value in it. The other will not, and they have innumerable problems because they have to constantly refactor, have bugs, and most importantly, no one on the team has any clue of the goals or why of the code.
lionkor 11mo ago
> 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? That sounds like an ad-hoc planning for a single issue, which you could also just do for a subset of the open issues, every, lets say, 2 weeks. And so we invented SCRUM.
- anthonypasq 11mo ago
  scrum planning doesnt usually get too nitty gritty on implementation details in my experience if you dont want the meeting to last 4 hours.
- lmm 11mo ago
  > That sounds like an ad-hoc planning for a single issue, which you could also just do for a subset of the open issues, every, lets say, 2 weeks. So you'd require the whole team to spend time on matters that interested only a subset, and you'd do this in a blocking way rather than asynchronously? What possible benefit would that have?
  - lionkor 11mo ago
    Then your team is too big. If you have more than, say, 7 people in a planning, your team is too large. And it's never really asynchronous. It's more honest to block everyone who might have input. Planning the effort (points) also helps see if anyone thinks its more complex than it is, which can reveal issues before implementation begins.. It's not perfect, but if you're gonna do planning, just do it properly.
    - lmm 11mo ago
      > And it's never really asynchronous. It's more honest to block everyone who might have input. How? Even if you decide you need everyone to look at it, letting everyone check it off asynchronously is more respectful of people's time and concentration. Maybe occasionally there's a big difference in people's assessment and you need to have a synchronous discussion, but there's no need to pessimize the common case for the sake of the rare case. > It's not perfect, but if you're gonna do planning, just do it properly. What's "properly"? Doing your planning in a more difficult, time-consuming way might feel virtuous, but it's not actually beneficial.
mupuff1234 11mo ago
So a design doc?
parpfish 11mo ago
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 be better as a method for this class over here...) the only way i could come up with a precise plan for how the code needs to change is to just build the thing.
- xrd 11mo ago
  Consider this: you could, given enough time. You probably haven't had management that gave you that time. Or demanded you take the time. 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.
nomel 11mo ago
> 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. If you have periodic meetings of what you plan to do, and allow people to comment/participate, they'll see themselves as contributing in a small way, which helps them remember, which helps them understand the effort. Worst, if you plan well and prevent future problems, nobody can know your good decisions. So, the optimal route seems to be, have periodic meetings that high ups can participate in, to some extent, and let "unforeseen problems" happen, so you can be in meetings with higher ups, fix the problems, and be the hero. This isn't even really my jaded opinion. In the org I'm in now, it was such as widely understood phenomenon that a special reward package, and recognition, had to be put together for people who prevented problems from happening.
- andai 11mo ago
  As the old saying goes... if code was shipped but nobody heard it get shipped... did it really Provide Value?
- johnnyanmac 11mo ago
  >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. 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
- xrd 11mo ago
  Sadly, I can't disagree. 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.
rbaudibert 11mo ago
And PostHog does that too with [RFCs](https://posthog.com/handbook/company/communication#requests-for-comment-rfcs https://posthog.com/handbook/company/communication#requests-...) when you require some sort of smart collaboration. The way I read OP's post is not about isolation, but rather about trust.
capyba 11mo ago
This works really well in mechanical engineering, too. We don’t necessarily use tickets specifically, but planning out work or a design upfront with a small audience saves a lot of time and wasted effort. On some level this is just basic project planning, which in my view is an underdeveloped skill in most modern engineering teams. In the case of the ‘empty ticket’, it’s project planning but at a lower level. Not every bit of work needs this, but many would benefit, especially when the taskee is at a more junior level. I wholeheartedly support this approach. Nearly every major project requires a team, not an individual, and coordinating and collaborating are basic functions of getting things done.
- bunderbunder 11mo ago
  "Without good [design] documentation every mistake, large or small, is analyzed by one man who probably made the mistake in the first place because he is the only man who understands the program area." - Winston Royce, "Managing the development of large software systems" That said I've also seen over-collaboration lead to a similar situation. In that case everybody ends up with their own personal model of what the plan is, based on their own interpretation of all the endless talking around in circles. Maybe there is also a design document that purports to be the source of truth, but nobody is actually paying attention to it. Possibly because all the bickering and confusion turns maintaining it into an impossible task.

by xrd 11mo ago

bunderbunder 11mo ago

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 naturally none of us could be expected to know every nook and cranny.

xrd 11mo ago
I've been fighting for this approach for ten years now. I can divide organizations into two camps. One will see value in it. The other will not, and they have innumerable problems because they have to constantly refactor, have bugs, and most importantly, no one on the team has any clue of the goals or why of the code.

lionkor 11mo ago

> 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? That sounds like an ad-hoc planning for a single issue, which you could also just do for a subset of the open issues, every, lets say, 2 weeks. And so we invented SCRUM.

anthonypasq 11mo ago
scrum planning doesnt usually get too nitty gritty on implementation details in my experience if you dont want the meeting to last 4 hours.
lmm 11mo ago
> That sounds like an ad-hoc planning for a single issue, which you could also just do for a subset of the open issues, every, lets say, 2 weeks. So you'd require the whole team to spend time on matters that interested only a subset, and you'd do this in a blocking way rather than asynchronously? What possible benefit would that have?
- lionkor 11mo ago
  Then your team is too big. If you have more than, say, 7 people in a planning, your team is too large. And it's never really asynchronous. It's more honest to block everyone who might have input. Planning the effort (points) also helps see if anyone thinks its more complex than it is, which can reveal issues before implementation begins.. It's not perfect, but if you're gonna do planning, just do it properly.
  - lmm 11mo ago
    > And it's never really asynchronous. It's more honest to block everyone who might have input. How? Even if you decide you need everyone to look at it, letting everyone check it off asynchronously is more respectful of people's time and concentration. Maybe occasionally there's a big difference in people's assessment and you need to have a synchronous discussion, but there's no need to pessimize the common case for the sake of the rare case. > It's not perfect, but if you're gonna do planning, just do it properly. What's "properly"? Doing your planning in a more difficult, time-consuming way might feel virtuous, but it's not actually beneficial.

mupuff1234 11mo ago

So a design doc?

parpfish 11mo ago

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 be better as a method for this class over here...) the only way i could come up with a precise plan for how the code needs to change is to just build the thing.

xrd 11mo ago
Consider this: you could, given enough time. You probably haven't had management that gave you that time. Or demanded you take the time. 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.

nomel 11mo ago

> 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. If you have periodic meetings of what you plan to do, and allow people to comment/participate, they'll see themselves as contributing in a small way, which helps them remember, which helps them understand the effort. Worst, if you plan well and prevent future problems, nobody can know your good decisions. So, the optimal route seems to be, have periodic meetings that high ups can participate in, to some extent, and let "unforeseen problems" happen, so you can be in meetings with higher ups, fix the problems, and be the hero. This isn't even really my jaded opinion. In the org I'm in now, it was such as widely understood phenomenon that a special reward package, and recognition, had to be put together for people who prevented problems from happening.

andai 11mo ago
As the old saying goes... if code was shipped but nobody heard it get shipped... did it really Provide Value?
johnnyanmac 11mo ago
>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. 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
xrd 11mo ago
Sadly, I can't disagree. 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.

rbaudibert 11mo ago

And PostHog does that too with [RFCs](https://posthog.com/handbook/company/communication#requests-for-comment-rfcs https://posthog.com/handbook/company/communication#requests-...) when you require some sort of smart collaboration. The way I read OP's post is not about isolation, but rather about trust.

capyba 11mo ago

This works really well in mechanical engineering, too. We don’t necessarily use tickets specifically, but planning out work or a design upfront with a small audience saves a lot of time and wasted effort. On some level this is just basic project planning, which in my view is an underdeveloped skill in most modern engineering teams. In the case of the ‘empty ticket’, it’s project planning but at a lower level. Not every bit of work needs this, but many would benefit, especially when the taskee is at a more junior level. I wholeheartedly support this approach. Nearly every major project requires a team, not an individual, and coordinating and collaborating are basic functions of getting things done.

bunderbunder 11mo ago
"Without good [design] documentation every mistake, large or small, is analyzed by one man who probably made the mistake in the first place because he is the only man who understands the program area." - Winston Royce, "Managing the development of large software systems" That said I've also seen over-collaboration lead to a similar situation. In that case everybody ends up with their own personal model of what the plan is, based on their own interpretation of all the endless talking around in circles. Maybe there is also a design document that purports to be the source of truth, but nobody is actually paying attention to it. Possibly because all the bickering and confusion turns maintaining it into an impossible task.