4 ms·

Welcome, Neo, to the real world. Most companies cant afford to throw large amounts of money at a team who’s entire job is managing a Jenkins pipeline. That’s

Welcome, Neo, to the real world. Most companies cant afford to throw large amounts of money at a team who’s entire job is managing a Jenkins pipeline. That’s a part time project for a single developer at smaller places.

sefrost 3y ago
Note to OP - when that developer leaves the company they will host a session called a "handover". At the handover meeting they rapidly run through how they think the pipeline works, lay out some caveats and then they're gone. That's the documentation. You own the pipeline now. It's probably a good idea to take vacation whenever the person who owns the Jenkins pipeline announces that they've handed in their notice. Otherwise you might be invited to the handover meeting.
- jacurtis 3y ago
  Yep, been to a lot of these. We call them "KT" sessions (knowledge-transfer). I shiver all down my spine when I hear "KT". You basically take the person who's been working on something for thousands of hours most likely and has probably written a lot of work arounds and shortcuts to get their job done and they now have a 1 hour zoom session to brain dump their entire existance onto the poor souls who have to pick up the pieces when they are gone. After that hour, they basically sign off with: glhf
genocidicbunny 3y ago
> Most companies cant afford to throw large amounts of money at a team who’s entire job is managing a Jenkins pipeline. I don't agree with this at the 300 engineer level; Specifically that they can't afford it. At that point, one or two more engineers is 1-2% increase in spend on compensation, and if you can get someone to handle architecture and developer support (ideally two different people) and empower them to make useful changes, you can probably get the ball rolling. Now, if you're talking about a 20-50 engineer shop, the math can be a fair bit different and there I do agree with you. It seems more down to the evergreen issue of tech debt and fragile tech stacks being a hard-to-quantify cost and mostly hidden from those making the budget decisions. No budget for maintenance or architecture -- things are done in the cheapest most expedient way possible. Then it becomes harder to make future changes, so doing it the right way starts costing even more, and the cycle repeats. > Welcome, Neo, to the real world. Indeed. Gamedev was frustrating for this quite often.
tayo42 3y ago
When Elon went and laid off everyone at Twitter and everyone kept saying, why do they need to many people. Like this is why. It was a shit show at time but it wasn't that much of a night mare because there were teams like that.

sefrost 3y ago

Note to OP - when that developer leaves the company they will host a session called a "handover". At the handover meeting they rapidly run through how they think the pipeline works, lay out some caveats and then they're gone. That's the documentation. You own the pipeline now. It's probably a good idea to take vacation whenever the person who owns the Jenkins pipeline announces that they've handed in their notice. Otherwise you might be invited to the handover meeting.

jacurtis 3y ago
Yep, been to a lot of these. We call them "KT" sessions (knowledge-transfer). I shiver all down my spine when I hear "KT". You basically take the person who's been working on something for thousands of hours most likely and has probably written a lot of work arounds and shortcuts to get their job done and they now have a 1 hour zoom session to brain dump their entire existance onto the poor souls who have to pick up the pieces when they are gone. After that hour, they basically sign off with: glhf

genocidicbunny 3y ago

> Most companies cant afford to throw large amounts of money at a team who’s entire job is managing a Jenkins pipeline. I don't agree with this at the 300 engineer level; Specifically that they can't afford it. At that point, one or two more engineers is 1-2% increase in spend on compensation, and if you can get someone to handle architecture and developer support (ideally two different people) and empower them to make useful changes, you can probably get the ball rolling. Now, if you're talking about a 20-50 engineer shop, the math can be a fair bit different and there I do agree with you. It seems more down to the evergreen issue of tech debt and fragile tech stacks being a hard-to-quantify cost and mostly hidden from those making the budget decisions. No budget for maintenance or architecture -- things are done in the cheapest most expedient way possible. Then it becomes harder to make future changes, so doing it the right way starts costing even more, and the cycle repeats. > Welcome, Neo, to the real world. Indeed. Gamedev was frustrating for this quite often.

tayo42 3y ago

When Elon went and laid off everyone at Twitter and everyone kept saying, why do they need to many people. Like this is why. It was a shit show at time but it wasn't that much of a night mare because there were teams like that.