3 ms·

I think if you're afraid to ship after 4pm, then you should write better code and/or test it better. There are things I'm afraid to do late (say upgrading 3rd p

by 0x457 4y ago

I think if you're afraid to ship after 4pm, then you should write better code and/or test it better. There are things I'm afraid to do late (say upgrading 3rd party software), but shipping a new version of my software? Don't see why not.

alar44 4y ago
Right, just write perfect code! Things can and do break. It's impossible to test everything. That's why.
outworlder 4y ago
> I think if you're afraid to ship after 4pm, then you should write better code and/or test it better. There are things I'm afraid to do late (say upgrading 3rd party software), but shipping a new version of my software? Don't see why not. Your wording seems to indicate that you work by yourself. That's fine, but things change when large teams and systems are involved. You can't vouch for every single change or the inter-dependencies between all systems. It's pretty elitist too. "Your code only breaks because you suck" doesn't make for good software engineering practices. Everyone makes mistakes.
- 0x457 4y ago
  No, I don't work by myself. We are just good at writing tests and have a good QA team that writes good e2e tests.
- lnxg33k1 4y ago
  That's why he wrote "test it better", it's intrinsic in that statement that he's well aware of the fallibility of humans
opportune 4y ago
Really depends on what you’re working on. Less complex things that are easily tested, sure. For more complex things that are hard to fully test, bad idea. If you have a micro service that takes requests over / foo and /bar and returns JSON that needs to fit certain properties, and you’re submitting a change to fix a corner case bug or add a new property that isn’t read, sure. If you are working on low level networking infrastructure that is used in tandem with thousands of different workloads you need to support, won’t work.
mattmanser 4y ago
This is just faulty reasoning. Test as much or as well as you want, a deploy is always going to be a risk. Eventually, your totally avoidable gamble will backfire.
yodsanklai 4y ago
I don't want to be the oncall in your team
- 0x457 4y ago
  Your loss. I haven't gotten PagerDuty ping in a year. You know where I did get pings all the time? In companies that had strict release windows and would never deploy on Friday. Which in result motivated people to "push now & hotfix later" to meat the release cutoff date.
wonderwonder 4y ago
I can actually see the narcissism emanating from this post. Try shipping code built by 4 - 6 teams each with 4 - 6 devs. See if something slips through.
stjohnswarts 4y ago
Doesn't make any sense if you want your workplace to have work/life balance. Ship on Monday, your customers will get used to it. That's what we do and it's fine, we don't ship on Fridays and it works out great.

by 0x457 4y ago

alar44 4y ago

Right, just write perfect code! Things can and do break. It's impossible to test everything. That's why.

outworlder 4y ago

> I think if you're afraid to ship after 4pm, then you should write better code and/or test it better. There are things I'm afraid to do late (say upgrading 3rd party software), but shipping a new version of my software? Don't see why not. Your wording seems to indicate that you work by yourself. That's fine, but things change when large teams and systems are involved. You can't vouch for every single change or the inter-dependencies between all systems. It's pretty elitist too. "Your code only breaks because you suck" doesn't make for good software engineering practices. Everyone makes mistakes.

0x457 4y ago
No, I don't work by myself. We are just good at writing tests and have a good QA team that writes good e2e tests.
lnxg33k1 4y ago
That's why he wrote "test it better", it's intrinsic in that statement that he's well aware of the fallibility of humans

opportune 4y ago

Really depends on what you’re working on. Less complex things that are easily tested, sure. For more complex things that are hard to fully test, bad idea. If you have a micro service that takes requests over / foo and /bar and returns JSON that needs to fit certain properties, and you’re submitting a change to fix a corner case bug or add a new property that isn’t read, sure. If you are working on low level networking infrastructure that is used in tandem with thousands of different workloads you need to support, won’t work.

mattmanser 4y ago

This is just faulty reasoning. Test as much or as well as you want, a deploy is always going to be a risk. Eventually, your totally avoidable gamble will backfire.

yodsanklai 4y ago

I don't want to be the oncall in your team

0x457 4y ago
Your loss. I haven't gotten PagerDuty ping in a year. You know where I did get pings all the time? In companies that had strict release windows and would never deploy on Friday. Which in result motivated people to "push now & hotfix later" to meat the release cutoff date.

wonderwonder 4y ago

I can actually see the narcissism emanating from this post. Try shipping code built by 4 - 6 teams each with 4 - 6 devs. See if something slips through.

stjohnswarts 4y ago

Doesn't make any sense if you want your workplace to have work/life balance. Ship on Monday, your customers will get used to it. That's what we do and it's fine, we don't ship on Fridays and it works out great.