4 ms·

I think it's helpful if EMs to continue coding, even if it isn't at work. I've been an EM for 4 years now and keep working on side projects every now and then.

I think it's helpful if EMs to continue coding, even if it isn't at work. I've been an EM for 4 years now and keep working on side projects every now and then. 1. As an EM you do sometimes have to resolve conflicts about code between senior members of the team(if it involves the team's tech lead) and it helps to not to have strayed too far. 2. It's much easier to drive new engineering initiatives if you are fluent at code and can quickly read and understand code documentation about a new library/way of doing things. 3. Sometimes while chasing deadlines, it helps if an EM can just sit with an individual contributor and do pair programming. Reminding developers about deadline won't motivate them as much as an EM sitting beside them and helping them out with coding. 4. EM jobs can be a bit hard to find, so being fluent at coding helps you to secure a job much easily since individual contributor jobs are far more prevalent than EM jobs. I usually try to pick up a side learning project every couple of months to just have some fun and learn something new. After moving to an EM role, I missed coding a lot and had thoughts about moving back to being an IC since EM at my company was a lateral move. Though I chose to stick on since the amount of stuff that I could pick up at a given point of time was no longer limited by my own personal bandwidth. I completely agree with your point about team members not having to dumb down complex concepts. Sometimes team members can come up with really novel solutions to problems which cost more time to implement on the short term but pays off in the longer term. Unless one is comfortable with the technical chops of a project, it's easy to dismiss ideas which aren't conventional.

thanatropism 8y ago
> 3. Sometimes while chasing deadlines, it helps if an EM can just sit with an individual contributor and do pair programming. Reminding developers about deadline won't motivate them as much as an EM sitting beside them and helping them out with coding. I'm in a somewhat different field, but I had this experience a couple of times when I was younger-ish and didn't feel good about it. I don't think it raised my productivity It may have been a good management move -- mitigating a high-stakes delivery risk by literally keeping an eye close, i.e. sitting next to me at my desk, but it felt more like panicky micromanagement (lasting for two or three days only, thankfully) than sharing the burden of an unplanned delivery. (Unplanned delivery requests sometimes happen in my field. But what we do isn't as bottom-up as programming; it's more like a progressive GIF, iterative refinement from high level concept down to action plan, so unexpected intermediate deliveries can be good for the client.)
- me551ah 8y ago
  That's a nice insight, I'll be sure to check with the dev next time it happens to see if it's actually helping or not. I personally do it in crunch situations for the following reasons: 1. Since there are more eyes on the code being written, mistakes made are an intersection of what either the driver or navigator would make. 2. It makes the developer less likely to procrastinate. I only use this as a last resort though and timebox it to an hour.

thanatropism 8y ago

> 3. Sometimes while chasing deadlines, it helps if an EM can just sit with an individual contributor and do pair programming. Reminding developers about deadline won't motivate them as much as an EM sitting beside them and helping them out with coding. I'm in a somewhat different field, but I had this experience a couple of times when I was younger-ish and didn't feel good about it. I don't think it raised my productivity It may have been a good management move -- mitigating a high-stakes delivery risk by literally keeping an eye close, i.e. sitting next to me at my desk, but it felt more like panicky micromanagement (lasting for two or three days only, thankfully) than sharing the burden of an unplanned delivery. (Unplanned delivery requests sometimes happen in my field. But what we do isn't as bottom-up as programming; it's more like a progressive GIF, iterative refinement from high level concept down to action plan, so unexpected intermediate deliveries can be good for the client.)

me551ah 8y ago
That's a nice insight, I'll be sure to check with the dev next time it happens to see if it's actually helping or not. I personally do it in crunch situations for the following reasons: 1. Since there are more eyes on the code being written, mistakes made are an intersection of what either the driver or navigator would make. 2. It makes the developer less likely to procrastinate. I only use this as a last resort though and timebox it to an hour.