4 ms·

Based on experience, I’m of the opinion that teams don’t change - there is so much guidance on how to implement these practices available already that any team

Based on experience, I’m of the opinion that teams don’t change - there is so much guidance on how to implement these practices available already that any team with the will has already done so. This opinion might be excessively negative, but I’m coming off an experience where both the manager AND half of the devs on the team were on board, and we almost didn’t manage the needle in 2 years. And I’ve read of others having to threaten to fire or actually fire team members to get the rest on board. I will definitely check out SO Careers.

1123581321 6y ago
Totally understand. I just see someone who went through an experience like that, and think, he's learned a bunch of lessons that would make him great at moving to another slightly dysfunctional organization to help them do the same thing, and they'll pay to have someone who can help! But I get wanting to spend some time producing at a place that has its act together--and that you'd want to keep multiple kinds of engineering skills sharp and that requires working in a variety of roles.
- tra3 6y ago
  I frequently don't see the organizational support for a proper CICD process. The people that hold the purse strings just don't understand the value. There's an obvious set of prerequisite here: 1. what's your code coverage? 2. what's the branching strategy like (this is a long winded way of asking: are PR branches built automatically?) 3. how frequently do you release? I guess this could be your "smoke test", without a reasonable code coverage you cannot have the PRs build automatically or a frequent release schedule. If you ask an HR person about the frequency and get anything less than "frequently" you're likely dealing with an org that doesn't have 1/2/3. It seems unlikely that something like this would make it into a job posting though.

1123581321 6y ago

Totally understand. I just see someone who went through an experience like that, and think, he's learned a bunch of lessons that would make him great at moving to another slightly dysfunctional organization to help them do the same thing, and they'll pay to have someone who can help! But I get wanting to spend some time producing at a place that has its act together--and that you'd want to keep multiple kinds of engineering skills sharp and that requires working in a variety of roles.

tra3 6y ago
I frequently don't see the organizational support for a proper CICD process. The people that hold the purse strings just don't understand the value. There's an obvious set of prerequisite here: 1. what's your code coverage? 2. what's the branching strategy like (this is a long winded way of asking: are PR branches built automatically?) 3. how frequently do you release? I guess this could be your "smoke test", without a reasonable code coverage you cannot have the PRs build automatically or a frequent release schedule. If you ask an HR person about the frequency and get anything less than "frequently" you're likely dealing with an org that doesn't have 1/2/3. It seems unlikely that something like this would make it into a job posting though.