
Efficiency Is Not Our Goal - pixelcort
https://medium.com/the-future-of-work-1/7ab1e8476adb
======
userulluipeste
"they probably could have shipped three more features in the time they spent
blocked waiting on agreement" \- because what we do is a race against time of
volume shipping products crammed with features before everything else! This,
is the kind of cowboy-developer I am trying to stay away from. (Here I am
making a difference in terms between the general "programmer" and the
"developer" which for me is not usually involved in later maintenance, testing
and other kind of "boring" tasks that the work might require. That kind that
only develops and tags it "done" jumping on something else.) This talk is
focused on efficiency on development, deliberately ignoring the need for a
system of development's checks and balances for other dependent tasks. I am
sure that "We’ve all hated those jobs." and prefer a job where we'd be able to
externalize the mess.

------
jared314
I think I understand what this is trying to say, but I believe the problem
lies more in each person's narrow scope of control, not some blind drive
towards efficiency or ignorance of total throughput.

------
vishaldpatel
Your argument would be much helped by actual anecdotes.

------
cbsmith
Spoken like someone who has never had to operationally support hundreds of
slightly different applications for a decade...

~~~
fournm
Yeah. I understand the sentiment on some level, but when you find 10+ broken
implementations of the same thing in a large codebase because every team
decided to do it slightly differently you start to really, really appreciate
those meetings for a change.

Not to mention the (usually) resulting inconsistencies in how it works which
can really annoy users.

