> It used to always be about "tricking" the result out of the computer by applying deep understanding of both system and problem to find the fewest, most perfor

> It used to always be about "tricking" the result out of the computer by applying deep understanding of both system and problem to find the fewest, most performant steps required to yield the result. We didn't used to have product teams as large as engineering teams. You can still engineer software the way you want, you're just beholden to some product persons idea about deadlines now. If you can turn your little unit of work around quickly no one will bat an eye (of course, we all know that's not realistic most of the time). If you dare trying to take longer than their perception of how long it ought to take then you better be prepared to discuss the "value add" of your performance minded solution as nauseum.