61–66 of 66 posts
Earlier quoted context omitted.
Hey at least the company knew that they had hired you. I had that once, the joy of contracting agencies I guess. It was a 6 month contract and at the end of it they still had not gotten me badge access to the area I worked in.
So what did you do? Sit in the lobby waiting for your badge for six months?
Earlier quoted context omitted.
So what did you do? Sit in the lobby waiting for your badge for six months?
The lobby bit was only 3 hours. The rest of the gig entailed a lot of knocking on doors and getting onto a first name basis with every security guard.
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…
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…
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.
Earlier quoted context omitted.
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.
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"
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.
Earlier quoted context omitted.
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"
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 n…