2 ms·

I've run into a few engineers, very capable people and I'd be happy to work with them, but their experience was limited to very structured environments. It sou

by duxup 2y ago

I've run into a few engineers, very capable people and I'd be happy to work with them, but their experience was limited to very structured environments. It sounded like they were in well organized organizations. One in particular worked for a sort of "side ways competitor". They were horrified to hear about my deploying a fix all by myself, no review, for a legacy product that really didn't have a good testing environment. It was inconceivable to them. On the other hand, not long after, our organization of 4 coders put out a better product in 3 months than their massive organization did in 18 ... and using that some "inferior" legacy systems that just so happened to be better suited to the job than some fancy new framework.

bornfreddy 2y ago
It's not one or the other though - a bit of safeguards here and there would make you even more productive, imho. Code reviews are indispensable for sharing knowledge within a team, automated deployments help deliver the system reliably and without unplanned downtime, and tests... People start appreciating tests when the red lights warn them about breakages in some completely unrelated places that they didn't even think were affected by what they did. And I'm not talking about 100% coverage - even covering just some of the trickier, but important flows helps immensely.
- duxup 2y ago
  I don't disagree generally, and in fact we're starting to build those safeguards where I am ;) Having said that process and bureaucracy is still what they are and they tend to eat up more cycles as time goes on, even if only because they're administered by humans.
seansmccullough 2y ago
> deploying a fix all by myself, no review, for a legacy product that really didn't have a good testing environment. This sounds like a great way to cause a live-site incident.
- duxup 2y ago
  It has risks, no doubt about it.
- deleted 2y ago
  [deleted]
lexicality 2y ago
Deploying straight to production? Eh, we've all been there. It happens. No review though? Aaaa

by duxup 2y ago

bornfreddy 2y ago

It's not one or the other though - a bit of safeguards here and there would make you even more productive, imho. Code reviews are indispensable for sharing knowledge within a team, automated deployments help deliver the system reliably and without unplanned downtime, and tests... People start appreciating tests when the red lights warn them about breakages in some completely unrelated places that they didn't even think were affected by what they did. And I'm not talking about 100% coverage - even covering just some of the trickier, but important flows helps immensely.

duxup 2y ago
I don't disagree generally, and in fact we're starting to build those safeguards where I am ;) Having said that process and bureaucracy is still what they are and they tend to eat up more cycles as time goes on, even if only because they're administered by humans.

seansmccullough 2y ago

> deploying a fix all by myself, no review, for a legacy product that really didn't have a good testing environment. This sounds like a great way to cause a live-site incident.

duxup 2y ago
It has risks, no doubt about it.
deleted 2y ago
[deleted]

lexicality 2y ago

Deploying straight to production? Eh, we've all been there. It happens. No review though? Aaaa