3 ms·

Getting engineers to commit code ASAP can become entrenched to the point that it's unhelpful; the tail wags the dog and all of a sudden you're leaving easy bugs

by hashkb 6y ago

Getting engineers to commit code ASAP can become entrenched to the point that it's unhelpful; the tail wags the dog and all of a sudden you're leaving easy bugs unfixed or small UX issues or whatever to make sure you have "first day" tickets. Just so you can say "our new hires ship code on day one" or whatever your flex is. Does it really matter? Aren't you teaching the lesson that speed is the first principle? It's just another excuse to avoid building actual onboarding, whatever that looks like for you. Too relaxed, too aggressive... are you really doing it thoughtfully?

wink 6y ago
My experience is more that there's always a bunch of tickets/bugs that are a) not critical b) not 5-minute fixes and c) tend to be "we should really..." - those are optimal, because they wouldn't get done otherwise anyway.
- hashkb 6y ago
  That's a serious problem. Whether work gets done should be independent of whether or not you have new hires around. And what lesson are you teaching if that's how you complete that kind of work? Onboarding is "hey do this thing nobody else will ever do, so we can say engineers ship on day one"
  - wink 6y ago
    I disagree, it's a much more helpful way to let them explore the code base than "here, write a test for some feature you also don't understand". Where I was it was never a stated goal to have them ship asap, the goal was a) to let them learn quickly and b) let them not hate their new job. Incidentally, everyone except one person liked this approach. Hands-on, have the genuine feeling to do something sensible (maybe not important, but hey, it's your first week) and NOT spend 2w just reading docs.
    - hashkb 6y ago
      I think that's a false dichotomy. For example, have new hires pair with someone who is making good progress on something medium sized and medium impact. Share in a nearly guaranteed success, learn, and no need to hoard one-pointers.

by hashkb 6y ago

wink 6y ago

My experience is more that there's always a bunch of tickets/bugs that are a) not critical b) not 5-minute fixes and c) tend to be "we should really..." - those are optimal, because they wouldn't get done otherwise anyway.

hashkb 6y ago
That's a serious problem. Whether work gets done should be independent of whether or not you have new hires around. And what lesson are you teaching if that's how you complete that kind of work? Onboarding is "hey do this thing nobody else will ever do, so we can say engineers ship on day one"
- wink 6y ago
  I disagree, it's a much more helpful way to let them explore the code base than "here, write a test for some feature you also don't understand". Where I was it was never a stated goal to have them ship asap, the goal was a) to let them learn quickly and b) let them not hate their new job. Incidentally, everyone except one person liked this approach. Hands-on, have the genuine feeling to do something sensible (maybe not important, but hey, it's your first week) and NOT spend 2w just reading docs.
  - hashkb 6y ago
    I think that's a false dichotomy. For example, have new hires pair with someone who is making good progress on something medium sized and medium impact. Share in a nearly guaranteed success, learn, and no need to hoard one-pointers.