You've only added two lines – why did that take two days?
341–350 of 522 posts
Re: You've only added two lines – why did that take two days?
#342A variant of this that has driven me to quit more than one job is having a non-technical manager look at a UI prototype and consider that 90% of the solution. "The UI guys had this page ready two months ago! Why doesn't this work yet?" It's even worse when you present a working prototype. They simply don't understand that the backend functionality is what's doing the bulk of the work, and just because you can see som…
Re: You've only added two lines – why did that take two days?
#343Do people actually have fights like this with management at their companies? Not trying to knock the author, but I'm just surprised anyone would actually hear this kind of comment in 2020. I'd think by now any and all metrics tying lines of code to productivity would be long dead.
I know someone that worked at some skeezy company in Menlo Park that got passed up for a raise after spending months navigating the bureaucracy to save the company millions on their operating costs because they didn't write enough code. This was in the last four years. Edit: And they quit right afterwards.
Re: You've only added two lines – why did that take two days?
#344A variant of this that has driven me to quit more than one job is having a non-technical manager look at a UI prototype and consider that 90% of the solution. "The UI guys had this page ready two months ago! Why doesn't this work yet?" It's even worse when you present a working prototype. They simply don't understand that the backend functionality is what's doing the bulk of the work, and just because you can see som…
It's not fair for managers to assume, but it's definitely fair for them to ask. And it's our responsibility to show and explain.
There's the famous story of the first iteration of Gmail being done really, really quickly. The demo was the product. And then just iterations from there. Definitely a good model if possible.
Re: You've only added two lines – why did that take two days?
#345Re: You've only added two lines – why did that take two days?
#346"My point today is that, if we wish to count lines of code, we should not regard them as “lines produced” but as “lines spent”: the current conventional wisdom is so foolish as to book that count on the wrong side of the ledger." ~ Edsger Dijkstra
I'm sure Dijkstra could get away with saying that, but how would you phrase something equivalent to someone above you in the food chain without getting nuked from orbit in response? I can just see how the conversation would go: PHB: You've only added two lines - why did that take two days! Dev: Because it took that long to understand the requirements, understand the code, find the root cause, write a test to verify t…
Exact quote from my manger, several times. They just don’t get it. And then a trivial feature takes a month to more or less implement because it’s all built on a toppling tower of crap.
Re: You've only added two lines – why did that take two days?
#347I wish they _would_ ask me why those two lines took two days (in my case, it might be simple burnout; been coding for too long, and longer than a more conventional career track would have prescribed). Instead, nobody much cares whether I write 2 lines of code or 2000; same difference to them, and boils down to the all-important "delivering".
There's some intellectual and creative freedom in that which I suppose folks don't have with a code-involved boss who scrutinises their commits. But the opposite--nobody scrutinising your commits--isn't all it's cracked up to be, either. I almost never have to explain why I did something a certain way to anyone, not because I'm so important and command so much distinction or recognition of my expertise, but because nobody gives a crap. :-)
Re: You've only added two lines – why did that take two days?
#348E = m c² is just three letters and a bit of gutter, how long could that possibly take to figure out?
Re: You've only added two lines – why did that take two days?
#349Earlier quoted context omitted.
Early in my career, I learned a simple 'demo day' rule: never demo things that aren't end-to-end done. When you do, it can easily confuse folks who aren't deeply involved in your project ("haven't I seen this already?") and can hurt team morale because they never get a "shipped it" moment that feels good. More to the point: enforcing this rule incentivizes teams to build things in small, shippable components. Nobody…
In a company that understands and embraces agile software practices, this works well. You demo small things that are done, and prototypes are understood as just mockups designed to drive future work. Alas not everyone in power gets it. In more egregious cases, I've been in adversarial environments where teams were pitted against each other to appear "more done." Obviously a recipe for failure. I'm fortunate enough to…
I've come to realised this, "true" agile is more like being funny and smart(not that I am either). If you have to tell people you are smart or funny, you probably are not. Ever noticed how smart people(the really clever ones) are just absurdly smart without walking around telling everyone "hey I'm smart", usually the nicer they are the more intelligent they are(yea you get exceptions), same with funny :)
I feel it goes double for "agile-processes" if you have to walk around and tell everyone (management or interviewees how agile your process is, it's probably not)