5 ms·
> before the end of your first day, you have your first code changes in production. Like adding yourself to a maintainer list or some prepared token handholdin
by rightbyte 5y ago
> before the end of your first day, you have your first code changes in production.
Like adding yourself to a maintainer list or some prepared token handholding task? Or what could you possibly do in the first day before having the time to read the code.
- icedchai 5y agoAt an early startup I worked at (about 10 years ago), it was fixing a small bug. You updated a couple lines of code and got familiar with the deploy process.
- bitcharmer 5y agoYeah, their statement about expecting to push changes to prod on day 1 is hilariously unrealistic. The sense of entitlement is strong in this one. Glad we don't hire people like this.
- Aeolun 5y agoDepends on how large your app/org/process is. I have worked in places where it would be expected (6 people org), and absolutely laughable (10k+), not least of which is that any release takes at least two months in the first place.
- eutropia 5y agowe have our new engineers update the “our team” wall of faces with their photo on day 1 in prod. Not sure why that’s unrealistic if your deploy process doesn’t suck?
- HWR_14 5y agoGood lord, why do people have team walls with pictures at all? I've seen it a lot and never understood why, but since you seem to be an advocate for it, I'll ask why my picture matters.
- eutropia 5y agoI don’t know why, I don’t have an opinion on it, it’s just something we have done. My point was only that pushing (any) code to prod on day 1 doesn’t have to be an entitled fantasy.
- HWR_14 5y agoOh, yes. You can push some small predetermined change like that through, or something else that doesn't require codebase knowledge. Although that is a thinly veiled test of your knowledge of the build process, in the same way "find a dog" is a made up thing to do for an internal directory tool.
- mrslave 5y agoOK there's a lot of good points on both sides of this. For one: pushing meaningful code change on day 1 may be unrealistic. For another: at least we've initiated the new team member into the full process of contributing to the product's code base, and their manager knows there are no administrative blockers (workstation, account, 2FA token, etc.). I know which I prefer. Also fixing a small (and admittedly probably low priority) defect is an achievable goal and a pretty cool way to get your toes wet. At least you're in the pool.
- wildmanx 5y agoIt's one step in building personal connections with your co-workers. It's one thing to get into a fight with somebody who is only a username on your screen. It's very different if you get to know your co-workers, understand how they think, how they work, what their culture is, their way of expressing things. Seeing a face is one of the first steps in this process. Much of the online ranting (and frankly, hate), including in this thread, would be avoided if people would just spend some time getting to know the human beings behind the text on their screen. The very thing that has been called "infantilizing" somewhere else in this thread.
- HWR_14 5y ago
- sverhagen 5y agoI worked in a place where it happened. If you dismiss that, it speaks to your experiences, not to mine. In my current job, it's not quite possible, the developer setup just isn't as mature yet, and it takes a few days. But at least I can aspire to do better. Of course, on your first day, you don't implement a new feature, but a small, well selected bug fix with a clear suggestion of how to fix it already contained in the ticket, is still possible. Also, of course, if you have a 2-month release cycle, it also doesn't work, so this story is from a team with a working Continuous Delivery practice.