4 ms·

For me, I'm most productive after hours because during the day, I get too many pings and escalations. After hours is the only time I can focus and get deep work

For me, I'm most productive after hours because during the day, I get too many pings and escalations. After hours is the only time I can focus and get deep work done myself. This is something I'd really like to improve, but I'm really not sure how. I've tried creating discussion groups and many other approaches to make knowledge transfer more efficient. However, the real issue is company growth. A huge recent period of growth has meant a focus on training people. This is only the kind of thing I could defend against if I were 1-2 ranks higher in the company, and honestly, this lack of longterm growth planning is one of the reasons I would leave my company. One approach I've been thinking of experimenting with is saving everything I say, and using an LLM with my custom knowledge base to answer a question. I actually think a borg-like communication structure in a company could be really efficient. If every communication was publicly available, and we used ML to make that information consistent and to answer queries, I think you could achieve coherence with a company much faster, move as a unit much faster, and get a lot more done. However, it's still a pipe dream at this point due to the context length limits. The actual amount of important context at a company is many times what a model can keep in mind now. As models get bigger, or if a group can run multiple models many times to make the company info widely consistent, it would be much better. For instance imagine now, 30 people at your company work on one project, and 50 people work on another. They might take a slightly different definition for a term, and do work which is ultimately counterproductive to each other. Usually, it takes a conflict arising to resolve this, and people are long stuck with the mutually-incorrect definition. If an ML algorithm can look at everything both groups are saying and point out inefficiencies, I think you could get more cohesion, especially before problems get big enough to be a drain. That being said, this type of system is more of a pipe dream, and I don't think it will be feasible for a few more years. In the meantime, I'm struggling how to balance communication with work. Advice appreciated.

twodave 3y ago
I ran into this problem after a promotion and some company growth left me over a much larger footprint of our engineering department than I was used to. I ended up making a couple rules for myself and establishing a couple new routines, which all have helped: “Handbooking” - this is something I learned from reading about Gitlab and ended up adopting for my department. If it’s important, it goes into the handbook. If it’s not, then I probably don’t need to know it anyway. This alone took a lot of burden off me (people only ping me now if something is missing from the handbook or if they didn’t understand it, both of which are signals that the handbook needs work). Office hours - I don’t do this consistently, but when I feel like the interruptions are still too frequent I’ll just post some office ours in our dev channel and tell people they can bother me in a few 2-hour blocks that week. Otherwise I sit there and livestream whatever work it is that I’m doing for whomever is interested in that sort of thing. Trusting - I found much of my increased stress was a lack of faith in others to do a passable job of things, so I’d burden myself with them. In a lot of cases things went as badly as I expected by letting go, but my personal stress was reduced nonetheless.
- seeknotfind 3y ago
  Thanks for the tips. I tried live streaming work a few times. I think it can work as long as people don't ask questions too much, but I feel a bit too egotistical to do it. It doesn't feel great.
  - twodave 3y ago
    Yeah, I feel that. Usually I have like a 2 hour coding block planned with something new/interesting, so it would end up being more of a workshop, like e.g. here’s how to build a really quick cron job for our k8s cluster or whatever. I tend to keep an eye out for little ~2 hour tasks that would be interesting and just save them for those blocks. Aside from that, ego is a lot more about attitude than action. If you remain inquisitive/curious/accepting/etc. then you won’t be seen as cocky. Also, just a reminder if you’re in an advanced position then showing off your coding skills is less about ego and more about helping. I had a boss early on point out to me (much to my surprise) that the programmers sitting around me were drowning trying to put together even simple solutions to their problems, and I had the ability to save them hours with just a few minutes of attention. Obviously you can only take that so far, but it gave me a lot of confidence to know I could help folks out.
twhitmore 3y ago
Yes, there's this amazing thing called "documentation". Confluence works well if you KISS - write just what the audience needs to know, in terms they can read & find. Avoid writing grand tracts of wanna-be architecture, policy, theory or planning; just write useful actionable material on topics your audience needs. You will find this works. Source: I led 400 devs and this was the only way that could scale. http://literatejava.com/documentation/how-to-write-good-wiki-documentation/ http://literatejava.com/documentation/how-to-write-good-wiki...

twodave 3y ago

I ran into this problem after a promotion and some company growth left me over a much larger footprint of our engineering department than I was used to. I ended up making a couple rules for myself and establishing a couple new routines, which all have helped: “Handbooking” - this is something I learned from reading about Gitlab and ended up adopting for my department. If it’s important, it goes into the handbook. If it’s not, then I probably don’t need to know it anyway. This alone took a lot of burden off me (people only ping me now if something is missing from the handbook or if they didn’t understand it, both of which are signals that the handbook needs work). Office hours - I don’t do this consistently, but when I feel like the interruptions are still too frequent I’ll just post some office ours in our dev channel and tell people they can bother me in a few 2-hour blocks that week. Otherwise I sit there and livestream whatever work it is that I’m doing for whomever is interested in that sort of thing. Trusting - I found much of my increased stress was a lack of faith in others to do a passable job of things, so I’d burden myself with them. In a lot of cases things went as badly as I expected by letting go, but my personal stress was reduced nonetheless.

seeknotfind 3y ago
Thanks for the tips. I tried live streaming work a few times. I think it can work as long as people don't ask questions too much, but I feel a bit too egotistical to do it. It doesn't feel great.
- twodave 3y ago
  Yeah, I feel that. Usually I have like a 2 hour coding block planned with something new/interesting, so it would end up being more of a workshop, like e.g. here’s how to build a really quick cron job for our k8s cluster or whatever. I tend to keep an eye out for little ~2 hour tasks that would be interesting and just save them for those blocks. Aside from that, ego is a lot more about attitude than action. If you remain inquisitive/curious/accepting/etc. then you won’t be seen as cocky. Also, just a reminder if you’re in an advanced position then showing off your coding skills is less about ego and more about helping. I had a boss early on point out to me (much to my surprise) that the programmers sitting around me were drowning trying to put together even simple solutions to their problems, and I had the ability to save them hours with just a few minutes of attention. Obviously you can only take that so far, but it gave me a lot of confidence to know I could help folks out.

twhitmore 3y ago

Yes, there's this amazing thing called "documentation". Confluence works well if you KISS - write just what the audience needs to know, in terms they can read & find. Avoid writing grand tracts of wanna-be architecture, policy, theory or planning; just write useful actionable material on topics your audience needs. You will find this works. Source: I led 400 devs and this was the only way that could scale. http://literatejava.com/documentation/how-to-write-good-wiki-documentation/ http://literatejava.com/documentation/how-to-write-good-wiki...