It's like the old story of the engineer who charged 10k to fix a loose screw[0]. It's not just the obvious effort, it's the effort behind the experience and know-how to recognize and find the most appropriate fix for the problem.
You've only added two lines – why did that take two days?
271–280 of 522 posts
Re: You've only added two lines – why did that take two days?
#272>Because I tested the change thoroughly and verified that it addressed the problem for all the different code paths that were affected.
Doesn't this imply that the'd be more than two lines of code unless they're not counting the tests.
Re: You've only added two lines – why did that take two days?
#273>Because I tested the change thoroughly and verified that it addressed the problem for all the different code paths that were affected. Doesn't this imply that the'd be more than two lines of code unless they're not counting the tests.
Not necessarily, not all testing means automated tests written in code. Manual testing can be more effective in the short run sometimes
Re: You've only added two lines – why did that take two days?
#274With unit tests included it would probably be more than two lines.
This.... so much this.
I remember working on a bug and writing tonnes of unit tests, a bunch of scripts and eventually implementing an entire e2e suite when it wasn't reproducable anywhere else.
Change to actual shipped code: 5 chars.
Re: You've only added two lines – why did that take two days?
#275A 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…
> They simply don't understand that the backend functionality is what's doing the bulk of the work.
You say this in present tense which makes it seem like a generalization. This is also a mistake that non-technical managers (and others) often make. The frontend frequently rivals and sometimes exceeds the backend in complexity. It is very application specific.
Re: You've only added two lines – why did that take two days?
#276Earlier quoted context omitted.
Also, never use the word "done" in any context in a meeting like that. Do not even say: "I'm not done". They won't hear the "not". Say, "Development is still in progress" or something similar. I got chewed out for something being released (where it was found to be broken) to a customer because I said something like: "I'm about 80% done with testing, but I haven't run into any issues yet." They released it even though…
Did you really get chewed out? That seems pretty much like a deal breaker for me. Managers are collaborators, not parents, and have no place talking to co-workers in such a diminutive manner.
Parents shouldn’t talk to kids in a diminutive manner either for that matter!
Re: You've only added two lines – why did that take two days?
#277Do 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.
Yes. The industry moves at a snail's pace, and is very different from what you'd read on HN. A huge % of dev jobs are still using old software/processes, with managers that haven't written software in 20 years, if at all. In 2014 I worked at a company that switched to Git and then started measuring LoC to assess performance/involvement. Engineers took to committing/removing things like node_modules directories to mak…
> Yes. The industry moves at a snail's pace, and is very different from what you'd read on HN. A huge % of dev jobs are still using old software/processes, with managers that haven't written software in 20 years, if at all.
Spot on. Talented engineers can usually be picky and change job if they don't like the environment, but not everyone has this option. There's plenty of developers who are stuck in shitty companies (lack of skills/experience, or struggle with interviews, or just live in places with limited opportunities). And the longer you stay in a bad place, the harder it gets to escape it. 2 years ago I was the hiring manager for a few open positions and I was honestly shocked by some candidates. So many "senior devs" that despite having 5-10 years in the industry wouldn't have passed the interview even if they applied for a junior role.
It's very easy to have a distorted view of the industry if you are privileged enough to have only worked in great tech companies. I'm guilty of this myself, making friends with other devs in my city was definitely eye-opening for me.
Re: You've only added two lines – why did that take two days?
#278"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
Re: You've only added two lines – why did that take two days?
#279Earlier quoted context omitted.
Reiterating what gp said , not all dev is like that, lesser you are doing IT and more comp science or any unfamiliar territory really it is harder to break down ahead of time . Many times I can’t tell you what tasks need to done let alone how much time is needed and break it into smaller chunks during planning phase. If planning has to work you should be familiar with what you are building , with poor information on…
When you’re doing exploratory work, the discipline of stopping, examining what you have learned already, deciding whether the goal still makes sense, and correcting course and reprioritizing seems even more important to me. You don’t know what you will be doing more than a few days ahead? Then your sprint length should be a few days and at the end you recombine and replan. I mean obviously this only makes sense as a…
It is not just only research that is exploratory, even the kind of bug fixes the article talks about can be hard to predict. replication of an issue or understand a new module can be uncertain, race conditions or data specific issues are uncertain too.
Identifying and solving something similar to [1] with a team is not simply possible when you plan with agile. I am likely going to go the next item once I mitigate the effect without bothering to dig deeper just because someone is clocking me on a timeline I committed.
It kills all the joy and fun, work becomes boring, this is by design, it is hard to run an organization unpredictably. If only management trusted you to deliver without looking over shoulder constantly ( when the situation warrants it)..
It is not only a engineer's gripe, it applies to management too, the board/ market forces them to be very short sighted, unless you are musk/jobs/buffet it is hard not to buckle to market pressure and invest in longer term opportunities.
The point is not that planning is bad, it can do a world of good in many including unpredictable situations, it is more that blinding pushing a framework especially agile because it worked somewhere and everyone says so, or the manager can't be bothered or won't risk doing something different as the situation warrants.
[1] https://cloud.google.com/blog/products/management-tools/sre-...
Re: You've only added two lines – why did that take two days?
#280One of my favorite bug fixes took me two weeks to find, and the fix was to swap two assembly language instructions (this was a bug in the Apple Newton context switch code, and swapping the instructions let timer interrupts happen reliably, which is kind of important for thread scheduling). We'd been having intermittent problems for months, with no smoking gun. I got mad at it, and found it.
No one was upset at the fix -- if anything, the checkin's brevity communicated its correctness -- and I got a couple of pats on the back for it.