
You've only added two lines – why did that take two days? - gregdoesit
https://www.mrlacey.com/2020/07/youve-only-added-two-lines-why-did-that.html
======
caymanjim
A 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 something, that doesn't mean it's
secure, performant, scalable, or even functional beyond demoing with dummy
data.

~~~
ftio
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 wants to be left out of demo day multiple
weeks in a row.

~~~
core-questions
> incentivizes teams to build things in small, shippable components.

Isn't this a bit of a fallacy? Not everything can be broken down into chunks
of work that fit into a single sprint.

There's a reason I stopped bothering with Scrum a while ago, and this is high
on the list.

~~~
lmm
> Not everything can be broken down into chunks of work that fit into a single
> sprint.

In my experience everything can be broken down if you spend five minutes
actually trying to break it down. And the benefits are very much worthwhile.

~~~
hinkley
How much brownfield work have you done?

People can hide the fact that they have a big ball of mud fir a very long
time, and they only want to talk about improvement after hunts have gotten
miserable.

~~~
lmm
> How much brownfield work have you done?

4-11 years depending on exactly what you'd define as "brownfield"

> People can hide the fact that they have a big ball of mud fir a very long
> time, and they only want to talk about improvement after hunts have gotten
> miserable.

True but beside the point. The same point stands: you can always find a way to
make a worthwhile improvement in two weeks - something that's useful on its
own, even if it's also the first step of a much bigger improvement plan.

------
rubyn00bie
Oh this reminds me of what went from one of the most infuriating questions I
would get asked by investors to one where I almost wanted to bait them into
asking it...

"Why/how is this worth X dollars/time? I know someone who says they can do it
in a week." To which, I eventually learned to reply: "Wow, well... In that
case, let me shoot you an article on how to build a Twitter clone in 15
minutes. [awkward pause while I smile at them] There's a lot more than just
literal lines of code that goes into building a successful software product."

~~~
el_oni
It reminds me of a pycon talk [0] which, while i dont agree with the whole
thing, has the message "we ship features, not code". That also reminds me of
"when a measure becomes a target, it ceases to be a good measure".

LOC is a decent measure, but features are our targets

[0]
[https://m.youtube.com/watch?v=o9pEzgHorH0&t=1235s](https://m.youtube.com/watch?v=o9pEzgHorH0&t=1235s)

~~~
k3liutZu
> LOC is a decent measure, but features are our targets

Only if your measure of success is tied to fewer LOC.

~~~
greggman3
that just sounds like it will have different unintended consequences like
making every line as terse, complicated and unreadable as possible just to get
it down to less LOC.

------
elnygren
An alternative take to this article would be that this person wasted two days
because he was reluctant to ask more questions from the person who filed the
bug report.

How often do you actually receive quality bug reports at work? My experience
is that external or internal users almost never provide sufficient information
and you as a coder are always expected to drill down on what they reported
with a barrage of questions.

ie. if you are not doing
[https://en.wikipedia.org/wiki/Five_whys](https://en.wikipedia.org/wiki/Five_whys)
then you might be doing it wrong and wasting time because of it.

I'm referring to this:

> Some developers would have immediately gone back to the person reporting the
> problem and required more information before investigating. I try and do as
> much as I can with the information provided.

Which seems like being stubborn and making a mistake because of it.

Couple other parts also seem a bit overdoing it:

> Because I investigated if there were other ways of getting to the same
> problem, not just the reported reproduction steps. > Because I took the time
> to verify if there were other parts of the code that might be affected in
> similar ways.

These seem like taking a gamble. Maybe something comes up, but is it more
probable that this work should be minimised until there is more proof of
"other ways of getting to the same problem"? Developer time is expensive, is
this really the best way of using it? Would it make sense to just fix the
issue at hand and only put in more time if more bug reports come in after the
fix or if there is some other indication that this part of the code might be
more broken?

~~~
dreamercz
> How often do you actually receive quality bug reports at work?

Very, very often. I work as a QA engineer whose main responsibilities is to go
through the bugfixing queue and add needed info where necessary. And I have to
spend a lot of time every day doing this. Sometimes it gets so bad I have to
assign the ticket back to the reporter to add more info, because even I don't
know where to look without it.

Interestingly enough, it's always the more senior people at our company who
are guilty of writing crap bug reports.

~~~
Uberphallus
I went from huge shop to medium shop and I really miss that layer of QA
engineers before the bugs got to us, it filtered so much nonsense that I had
tremendous respect for those guys.

Half of my current tickets barely have 2 sentences in so-so English.

------
kevsim
Do 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.

~~~
duderific
They don't always make the comment out loud, but you can tell they're thinking
it.

They absolutely use lines of code metric at my company. I don't miss any
chance to tell my manager it's complete bullshit. His answer: "Engineers are
supposed to write code, just like construction workers are supposed to build
houses."

~~~
bavila
What an absurd response from your manager.

If you give a construction worker a design to build a wall, and the worker is
given 2,000 bricks that must be used to build the wall, then, yes, of course
the worker must lay down all 2,000 bricks to build that wall. However, if I am
asked to build a computer-simulated model of said wall, and if there is a way
to build the model with 200 lines of code that looks and performs identically
to a model built with 2,000 lines of code, then, yes, of course I am going to
build the wall with 200 lines of code.

I hope you find better pastures.

~~~
Aeolun
Hell, if you can find a construction worker that somehow, magically can build
the wall with 200 bricks instead of 2000, everyone would want to hire them
because they’re saving them 90% of the cost.

------
snidane
"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

~~~
l0b0
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 the root cause, and then 2
minutes to write the code to fix it. The resulting code verifiably fixes the
root problem for at least reasonable inputs, with minimal code and thus
minimal chance of a bug.

PHB: Why not add 50 lines of code and be done in an hour?

Dev: Because that would be enormously more likely to be buggy.

PHB: But it would fix the symptom, right? Don't let perfect be the enemy of
the good!

Dev: 50 lines would not to be "good", it would be crap. And we would have to
revisit that code in a week or a month.

PHB: But in the meantime we will have _delivered,_ dammit! We're on a
deadline, with three managers and five customer representatives breathing down
my neck, and you're telling me you want to spend two days on something you
admit could be fixed in an hour?

Dev: I never said I could, only that 50 lines would be a crap solution.

PHB: Are you calling me a liar? Or just an idiot?

[Continue until the developer is fired or gives in, loses hope in humanity,
and starts planning their exit.]

Thankfully I have never worked with someone like that, but if the starting
point is as bad as the first sentence above then it's only going to go
downhill from there.

~~~
ornornor
> Don't let perfect be the enemy of the good!

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.

~~~
Piskvorrr
"In our case, we're letting good enough be the enemy of barely tolerable."

------
mirekrusin
This is achilles heel of non-tech managers. You can link as many articles like
that as you want, it will still be a problem. They may be more aware of it,
but it will still be, daily struggle. Non-tech manager should be paired with
tech-lead with high trust relationship for this not to be a problem.

This example is just one case/symptom of much larger problem.

Non-tech managers will only see fast progress on combination of: \- poor
developer \- doing fast progress \- with shitty code \- on good quality
codebase

They will see tech lead/good coder as asshole in general, with poor
performance in general, who for some unknown reason is respected for their
code and sometimes magically ticks off hard problems quickly which "must be a
coincidence, overestimated work to begin with or something like that" on
combination of: \- person who actually cares about the project \- who repairs
shitty code/tech debt \- who thinks more deeply about the problem \- and as a
bigger picture issue, not just ticking off ticket with the lowest resistance
possible \- writes good quality code \- if the problem breaks current
abstrations, refactors abstration itself \- who cares about readers of the
code

~~~
ipnon
People who don't know how to write software have to use "boss" heuristics when
determining who is a superstar. Qualities that take prominence over quickly
writing high-quality software:

1\. "Can do" attitude 2\. Never backs down from a challenge 3\. Being the glue
that holds the company together 4\. ...

As you can see these are all the kind of things you can't put your finger on
but you "know it when you see it". When they see it, it nearly always looks
like their reflection.

------
ww520
The one that drives me up the wall is the schedule/cost anchoring question,
"this should be easy to do, right?" every time they asking for a new feature.
It's set to manipulate you to lower the schedule or the cost. If you say it's
not easy, they would question your competency. If you say it's easy, they
would say, well then you can get it done this week.

It always gives me a pause, and then I would double the schedule.

~~~
giovannibajo1
On the other hand, programmers are very good at wasting weeks creating
incredible software architectures to try the latest library they read about or
try a design pattern, or in general over engineer something so that it’s
“better designed”, more generic, more “flexible”, and so on.

In other words, if a project manager sets an expectation that a task is a
“task that takes two weeks”, the developer will somehow manage to use about
two weeks to make it, that is find the “best way” to do it given that
timeframe, where “best” is probably evaluated under some kind of metric which
has nothing to do with product or user value.

Sometimes the question “explain me why it should take more than two days, when
i know it takes two days to do just that in the context of a minimal MVP” goes
a long way in making programmers focusing on delivering the maximum value for
the product.

So I think there is actually some value in having a technical person
continuously challenging developers in shortening their path to implement a
feature.

~~~
corebit
Programmers actually hate working on the same thing for longer than necessary.
They like new problems and new challenges, as your identifying in your
misguided take on always wanting new libs/frameworks. If you are finding that
you actually believe this, you've somehow cultivated a very toxic technology
environment where your developers are hiding necessary tasks from you and
attempting to make up the difference wherever they can. You have probably
browbeat them and cowed them from speaking about their ideas in the past.

~~~
malyk
That's a very broad generalization.

I've been getting paid to write code since 1998. The last few years in
management. So I know something about actually being a programmer.

I hired someone who was _awesome_ from a technical knowledge perspective.
Friendly, personable, smart, driven, etc. Loved talking tech with him and he
had really great ideas.

Anyway, the problem was, I'm running a startup and every single project he was
on he tried to model it as "the perfect open source project". So instead of
doing something simple in a couple of days he would build this really well
abstracted, over engineered (but pretty damn good code!), "beautiful" thing
that would take 3 or 4 weeks to deliver.

In the end, it didn't work out for him.

Anyway, my point is that it is _not_ true that programmers hate working on the
same thing for longer than necessary. I do. You do. Many others do. But some
just love being architecture/purity astronauts and refining that 3 line method
into a 7 class inheritance hierarchy.

------
newshorts
The assumption that asking for more information to recreate the bug is a lazy
tactic to get out of the bug fix is also a terrible assumption and discredited
the opinion IMO.

Often times asking for more information can speed things up and lead to a
quicker resolution.

~~~
c0nsumer
Unfortunately, working in a big enterprise world, I've seen both sides of
this. After a while it becomes somewhat obvious if someone is legitimately
asking for more info, or if they are just punting the ticket down the queue.
(The former is when you can tell they are becoming focused whereas the latter
seems to be more general, swirling questions.)

~~~
bonestamp2
Agreed, although we (mostly) solved this a number of years ago. Our validation
team has screen recording software running all the time. If they see an issue,
they attach the video to the bug report. These videos dramatically improve
everyone's ability to accurately report bugs and quickly resolve them.

------
pdpi
“I’m sorry for the long letter, but I didn’t have the time to write a shorter
one.”

------
rmason
Because I had to explore all the things that wouldn't work before finding the
two lines that did.

~~~
newshorts
This summarizes the argument pretty well and should suffice as a tl;dr.

------
rburhum
My most challenging bug was fixing a memory overwrite of a COM reference
counter (of all things!) that would only happen under very rare conditions -
when a 3rd party C library that was compiled with different calling convention
would be called with a certain amount of parameters. It took me a month to
chase down - frankly, it would have been impossible for me to figure out if
Visual Studio did not have _data_ breakpoints implemented for C++. It took a
month... and the fix was also a two-liner. Still proud of that fix 17 years
later!

~~~
r_c_a_d
Nice! I had something similar. It took over a week and the fix was to _remove_
one line of code.

------
dev_tty01
-2000 lines of code. [https://www.folklore.org/StoryView.py?project=Macintosh&stor...](https://www.folklore.org/StoryView.py?project=Macintosh&story=Negative_2000_Lines_Of_Code.txt)

~~~
tommyage
I smirked reading your linked text. Commonsense required though.

------
phreack
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.

[0][https://www.snopes.com/fact-check/know-where-
man/](https://www.snopes.com/fact-check/know-where-man/)

------
sriku
One solution to the OP's problem is to continuously document the activity
leading up to those two lines of code. That way you can point to the notes and
say "here's why" .. and I've found that quite often justifiable and shows
you've not been goofing off. Furthermore, it also helps someone who'll have to
look at those two lines later on to grab some context and understand why
they're there.

This could be as simple as notes logged against an issue about experiments
done, etc.

~~~
franky47
Also, adding this log to the commit message itself, to preserve context for
future developers reaching that code. Duplication might be necessary for
discovery depending on the tools used.

[https://dhwthompson.com/2019/my-favourite-git-
commit](https://dhwthompson.com/2019/my-favourite-git-commit)

~~~
sriku
Some fun folklore involving Bill Atkinson at Apple - logging "-2000" lines of
code written.

[https://www.folklore.org/StoryView.py?story=Negative_2000_Li...](https://www.folklore.org/StoryView.py?story=Negative_2000_Lines_Of_Code.txt)

------
abalashov
There's no paradise anywhere. I've been self-employed for 13 years in a rather
niche area, as an involuntarily solipsistic army of one for lack of ability to
grow my business. Most of my customers are highly technical, but don't
understand what I do quite enough to have a "lines of code" resolution on it.

I 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. :-)

------
arnvald
Oh, that reminded me of my "two lines" moment. Years ago I was writing
software for some university project, and one feature took me a few days to
figure out and implement, and when I checked the diff I realized that "all" it
took was removing some 20 lines of code. I literally added a feature by
removing some constraints that I had previously introduced.

~~~
zdw
Deleting code is giving your future self a gift of not having to maintain that
code anymore.

~~~
Scramblejams
Yes, I like to say it as "A line of code deleted is a line of code debugged."

------
whoisjuan
If someone is measuring productivity in code, based on the amount of lines of
code written, then they have never written code. Anyone with a tiny
understanding of how programming works would totally get why something so
small could take so long.

~~~
mv4
Seriously, Albert? You spent 7 years and "E = mc2" is all you produced? We
need to talk.

~~~
quickthrower2
Michelin Star: 1kg food

2 Stars: 2kg food

3 Stars: 3kg food

“Well KFC can do it...”

------
eikenberry
> I don't like having to fix bugs.

???

I rather enjoy fixing bugs, particularly really hard ones. They can be fun
logic puzzles that take some sleuthing to figure out and offer multiple pay
outs... First time reproducing it. Figuring out the problem. Figuring out the
best fix. Test case fail -> test case pass.

~~~
andrewflnr
It's kind of a personal style thing. Debugging can be really rewarding to the
extent it actually does feel like a puzzle rather than digging through a
sewer, but I myself like green-field development lots more.

------
rurp
This article made a number of great points.

> I know some developers don't like having to fix bugs, and so do whatever
> they can to get out of it. Claiming there isn't enough is a great way to
> look like you're trying to help but not have to do anything.

God, this behavior has annoyed me so much at times. I've worked with a few
developers that were not bad overall, but would use the slightest excuse to
punt on fixing an issue they were tasked with but didn't want to track down.
Regularly weaseling out of tasks like this wastes the time of multiple people
and either ends up back with the original dev or gets dumped on a more
responsible worker.

> Because I took the time to verify if there were other parts of the code that
> might be affected in similar ways.

Not looking for other places in the code that are very likely to be affected
by the same issue is bafflingly common, in my experience. Although I would say
that managers are much more often to blame for this behavior than the devs.
Any workplace that puts less weight on fixing an issue well than on artificial
metrics like number of tickets closed is incentivizing exactly this type of
behavior. Why bother getting criticized for spending all day fixing a simple
bug the right way when you can fix 5 different iterations of that same bug and
close 5 tickets in the same amount of time?

~~~
flukus
> Regularly weaseling out of tasks like this wastes the time of multiple
> people and either ends up back with the original dev or gets dumped on a
> more responsible worker.

A lot of this depends on the environment and circumstances. If you're in the
middle of working on feature X it's very annoying to have to drop it to look
at a bug, sometimes it's necessary but usually it can wait. This is where
having great user support comes in too, capturing what the user was doing,
getting relevant logs and knowing how to reproduce are important and if you
don't have a good support team that falls to the developers.

The other big factor is external pressures, if you have management asking for
frequent updates and putting pressure on to get through tickets quickly
(especially common at consultancy type shops) then bug fixing is miserable
high pressure work that I will avoid at all costs. An environment without
those and bug fixing can be fun, give me the biggest most spaghetti like
enterprise system and no time pressure and it feels like getting paid to solve
a giant Sudoku puzzles all day.

While we're all swapping war stories I'll share my most epic 2 line fix at a
place were I was afforded the time. I was working on this huge mess of over
abstracted, multi threaded, spaghetti enterprise OO, trying to track down a
bug that happened maybe once a fortnight. I tried narrowing it down to
reproduce but nothing was working, the stack trace was about 15 levels of
indirection away from the trigger so the most I could narrow it down to was
hundreds of thousands of lines of code. After a couple of weeks of trying
things and getting nowhere I told the boss we'd probably never track this down
but they insisted I keep trying. Eventually I wrote a script to copy all the
logs locally where I could search and do some analysis on them, after grepping
18 months of logs I noticed that on 3 or 4 occasions the same error was
happening within 5 seconds of each other. From there it was a matter of
finding "Sleep(5000)" in the code to know exactly where the error was. Turns
out that 15 levels of indirection was quite slow and getting a stale piece of
data we already had anyway so the time wasted turned into a nice little
improvement.

The scripts for the logs become invaluable too. So many times we got "you
incompetent idiots broke x with your last update" we could reply a minute
later with "x has been happening since <time before any of us worked there>,
you only just noticed".

------
adrianmonk
You've only rendered one two-word verdict -- why did that take five days of
deliberation? You had twelve people working on it!

------
otikik
Those two lines took two minutes to write.

Knowing which lines to add, and where, took 25 years of experience.

That's what you are paying.

~~~
Cthulhu_
There's an anecdotal quote from Picasso to that effect: tl;dr he doodled on a
coaster and asked 60K for it. Not because it took him 5 minutes, but because
it took him 50 years.

Personal anecdote, the 'old' UI I'm working on had an issue where a dialog
window's action buttons would be outside the visible area and people had to
scroll all the way down. One guy they hired part-time spent several days
trying to figure it out. I came in and added a few lines of CSS and it was
fixed. The bug had been open for three years. The CSS in question:

    
    
        .dijitDialogPaneActionBar {
          position: sticky;
          bottom: 0px;
        }

~~~
thinkingemote
Another Picasso anecdote: someone saw his doodles and said "pfft, I could do
that!" He replied "So why haven't you?"

------
kmclean
> I know that reporting errors can be hard, and I'm grateful for anyone who
> does. I want to show appreciation for error reports by trying to do as much
> as possible with the information provided before asking for more details.

This might be coming from a noble place but sounds a little like shooting
yourself in the foot. Bugs that can be reliably reproduced are the easiest to
fix, and I've found the quickest way to get to a set of reliable reproduction
steps is just to ask exactly what the user was doing when the problem
happened. They don't always remember, but often do. Sometimes they even
remember the time, which can be really useful for digging through logs, which
otherwise are too voluminous to be relevant.

Maybe it's a cultural difference. But maybe we could "show our appreciation"
for the bug report by just saying so ("Thank you so much for taking the time
to report this issue. Users like you play a big role in helping us improve our
software"), instead of soldiering on in the dark for 2 days.

------
jedberg
It’s not just management that feels this way. A lot of junior engineers feel
the same way. It’s what leads to bloat because they assume “it can’t be right”
if it’s just a small change.

It takes a while for a lot of junior engineers to realize small elegant
solutions are better, and requires good mentorship and code review to get
there.

------
RandomInteger4
Because I procrastinated due to the overwhelming complexity overloading my
mind with the myriad scenarios resulting from those two necessary lines and my
lack of experience with this scenario depriving me of the intuition necessary
to prune the aforementioned tree of mental complexity in an efficient manner.

~~~
Piskvorrr
Because I have spent time thinking, not merely typing. (The error "programmers
are just overpaid typists" is widespread)

~~~
Jtsummers
My first boss and my boss two positions ago both thought that way. It was
incredibly frustrating. Along with: If only you programmers would stop putting
in bugs we'd ship perfect software every time. (When most of the "bugs" were
specification errors and not program logic errors.)

~~~
neatze
Where does program specification ends and where does program logic starts ?

~~~
Jtsummers
Program logic error:

    
    
      // return the maximum value from an array
      return array.min();
    

Specification error:

    
    
      Only users with role X can access this content.
      [where X should've been Y]
    

In the former case, a test should catch it (because the code isn't doing what
we believe, per spec, it should be doing). In the latter case, only validation
(confirming with customers) can catch it. Any test that is run against the
code will be based on the spec which tells us to do the wrong thing.

Though we usually didn't run into the latter case, ours were mostly embedded
systems. So the problem was more like: You implemented this against Industry
Standard 1234-A, but we're implementing against Industry Standard 1234-B which
says that message Foo word 15 now has a range of 1-20, not 1-19, and 20 means
"cease operations", and 18 has been changed from "cease operations" to "halt
and catch fire".

So one system was developed per one spec, and another per a slightly different
spec. The other common scenario was that the specs weren't created from thin
air, but rather based on a preexisting system. And the authors of the spec
misinterpreted what the preexisting system did and gave an incorrect
specification for a behavior. When testing against the old system (or with the
old system as these were mostly communication systems) you'd see a difference
in behavior or failure to communicate. But since tests were never truly
comprehensive, many of these errors could make it out into the world.

~~~
neatze
What happens in case where specification is:

[User inputs X1, system displays Y]

On system crash user input was X2.

Is this specification or program logic error ?

~~~
Jtsummers
I generally consider system stability an assumed part of the specification.
Your system should handle most input errors from users more gracefully than a
crash. Specifications are never as detailed as the program. So a description
of what it should accept implies what it shouldn't. The questions for the
programmer when faced with invalid input are:

1\. Should it crash? (almost always no)

2\. Should it process the garbage input as though it were valid? (pushing the
input validation problem further down and potentially causing issues in random
locations of the program)

3\. Should it reject the input and request a different input? (probably)

Once you get to 3 you've got a number of ways to re-prompt the user or
indicate that the input is invalid in a way that won't crash the program. You
_may_ need to go back to the customer to figure out their preferred
resolution. But crashing is almost certainly not what they want and a sign of
a program error (not specification error).

I _would_ classify it as a specification error if they told us X1 would work,
and then supplied X2 in a way that was close enough to pass most validation,
but not close enough to work correctly.

Like, "The data format is a series of messages. Each message consists of up to
512 16-bit words. Word 0 specifies the length of the message, including
itself." and then it turns out that word 0 specifies the length _excluding_
itself causing us to not grab enough data in the first message, and then
random amounts of data after that.

~~~
neatze
If I understand correctly, specification describes "what/when" and program
logic describes only "how".

------
not2b
I recall a story about someone at a government contractor who did a major
refactoring and removed thousands of lines of code from a project, increasing
its performance, only to be told by management that they'd signed a contract
that said the company got paid by lines of code delivered, and his improvement
would cost them tens of thousands of dollars, so revert the whole thing.

~~~
pintxo
As long as we are counting LOC before compiling, that can be solved easily:

    
    
        if (false) {
          /* original code stays here, as we are payed by LOC */
        } else {
          /* write your new code here */
        }

~~~
ZoomZoomZoom
Realistically, it would take some compile time conditionals in a bunch of
places to get rid of the dependencies. The best part, you'll get paid for all
those #ifdefs, whens and #[cfg()]s! You can even split longer functions to be
able to wrap each one of them in those conditionals! Where do I sign up?

------
glouwbug
What if a single line change, given it took 2 weeks, fixed 40% of your crash
rates? That fix alone is worth millions, almost 100x - 1000x the engineer's
hourly salary in down time.

~~~
arendtio
A manager would certainly argue the other way around: The person who created
the bug costs the company a lot of money. Fixing that single line was just
necessary because someone didn't do his work in the first place. So fixing
that line is something you should do off-the-clock.

This is just one of the reasons why I appreciate it when managers have at
least some coding experience.

~~~
cgrealy
To that manager: that bug wasn’t the creation of a single developer. It went
through code review. It had unit tests. A QA verified its initial
implementation and a Product Owner signed off on the feature as done.

If it wasn’t caught before prod, it’s either such an edge case as to be almost
impossible to catch OR (more likely) it’s representative of a systemic failure
within the organisation.

------
notsag-hn
The only mistake of the procedure is that if you don't have enough info you
should ask for help before. This is very common and I have done that so many
times to understand it's a waste of time. The only exception IMO is when you
really need to understand certain parts of the codebase at a very low level so
spending time solving things by yourself it's well worth as an exercise and
helps a lot. If it's a part of the codebase you're not likely to be working on
any time soon, just don't do it. Talk to whom reported the bug and also talk
to the last person that worked on that piece of code (git blame is your friend
here)

------
kabdib
One 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.

------
TallGuyShort
I would add: "Because we keep punting on our tech debt, and our infrastructure
is so bad that after I spent 2 minutes writing the code, it took 2 days to get
it tested, committed and deployed and deal with the fallout"

------
addicted44
If the reporter hasn't provided enough information to recreate the issue (it's
obviously not a major deal breaking issue otherwise it would be obvious and
easy to recreate) and they are internal to the company, tell them to provide
more information before moving forward.

The author's approach is good for external bug reports, but they don't clarify
that's indeed the case here.

I have to strongly appreciate the author for finding the root cause and
tackling that instead of the symptom.

So often, especially in front end coding, you will see an exception being
thrown because of a null value being passed in, and the "fix" checked in by
the developer basically returns the default value if null is passed in, when
they should be investigating and fixing why a null was passed into the
function in the first place.

If your function has a contract that forbids nulls from You resolve the
immediate bug, but this almost certainly leads to multiple bugs being created
in the future (or worse, something that is quietly wrong, because 1 row in a
100 row table is missing and no one noticed) until the root issue is resolved.

------
Piskvorrr
Reminds me of that time a PHB decided to measure efficiency by kLOC. All the
pull requests in the following week had a net negative line count.

~~~
andi999
They PHB should put extra bonuses on kLOC, like 1k$ per 1kLOC, and watch the
codebase increase exponentially and since documentation is better than code,
double the amount for line of comments.

~~~
Piskvorrr
That's a literal Dilbert strip, 1998-ish, IIRC.

~~~
thaumasiotes
[https://dilbert.com/strip/1995-11-13](https://dilbert.com/strip/1995-11-13)

~~~
Piskvorrr
Ah, that's the one. I have misremembered it slightly...

------
BurningFrog
Conclusions:

1\. Picking a good manager is very important!

2\. Communicating with your manager is very important!

~~~
Lammy
1\. Being in a position where you have the privilege of being able to pick a
good manager is important :)

~~~
williamdclt
I remember hearing somewhere that the reason n.1 people leave their job was
their manager. Don't know if that's true but the idea's there. So it makes
sense that your manager should be a major decision criteria when you pick a
job (being able to actually pick a job is also a privilege, but it's fairly
common in SWE)

~~~
Lammy
Many companies have a team-selection process that starts after (and is
separate from) the actual hiring, e.g. you might not know who the available
managers are or if there even are any 'good' ones.

------
lavametender
+2 lines? That's rookie numbers!
[https://www.folklore.org/StoryView.py?story=Negative_2000_Li...](https://www.folklore.org/StoryView.py?story=Negative_2000_Lines_Of_Code.txt)

~~~
nucleardog
My personal best was -112,000 on a legacy project.

The code base was full of commented out code (the best case scenario as you
know immediately it can be deleted), methods which had been deprecated and
replaced with ‘myMethod2()’ and eventually ‘myMethod3()’ with all of them
still in the class (and for extra fun, it wasn’t always the case that all
references had been updated to the newest method), and thousand line blocks of
code which static analysis helped me pick up were actually not possible to
ever actually execute, etc.

Basically a static analyzer with an analysis mode for finding dead code just
flagged pretty much the entire codebase.

And in the process I split a totally unrelated project which had been grown
inside that codebase like a tumour into its own codebase.

Needless to say two weeks of my time invested really pepped up development
velocity for that team.

------
ilyas121
One time I spent 3-4 months working on a project that amounted to adding 11
lines of code to a config file on kubernetes. Tbh, a lot of it was bad
communication, but it was also because I wrote and rewrote so much of the same
code.

------
slaymaker1907
I’d rather write 2000 lines in two days since if I’ve only written 2 lines,
figuring out those 2 lines must have been miserable.

~~~
talaketu
I know this behavior.

------
caseymarquis
Let's not forget meetings. Advising on sales. Talking with customers about new
features. Helping out tech support and services. Traveling to customer sites
to review specialized requirements.

Or the real reason it takes 2 days is that the code base is a big ball of
unbuttered spaghetti with no tests.

I was lucky enough to be able to rewrite a couple of products from scratch
with the benefit of hindsight. When the code is loosely coupled and well
organized, it's rare for any of the reasons listed in the article to stall
development. When the code base evolved unpredictably over a couple decades,
the article is spot on.

------
m4rtink
Two lines ? Bah, a one line fix took me 5 weeks once!

(issue deep in the storage stack with exotic hardware only available at a
customer with all debugging going ping-pong over an issue tracker between me
and a customer engineer)

------
jerzyt
This is a great write-up. This is real life. And then you get a corporate dude
berate everyone and ask: what are you doing to make sure that it never happens
again? And I always want to respond that "I can guarantee that the same thing
won't happen again, but something very similar will happen, if you won't
assign sufficient resources to fix the real problem, instead of putting on a
band-aid. And you won't even know the difference."

I think the OP covers this case very well.

------
mro_name
E = m c² is just three letters and a bit of gutter, how long could that
possibly take to figure out?

~~~
hackerman123469
Thanks, gonna use that argument in the future

------
mastazi
I agree with the general sentiment of the article, but the following is a big
mistake IMHO:

> Some developers would have immediately gone back to the person reporting the
> problem and required more information before investigating. I try and do as
> much as I can with the information provided.

Some developers have a hard time with interpersonal communication but you
can't isolate yourself if you're working in an org. That mindset will
inevitably make you less effective (I learned that the hard way).

------
dspillett
_> You've only added two lines – why did that take two days?_

If this is hard for them to understand, the confused look when you reveal a
change was a net removal of lines/statements must be amusing!

 _> Because the issue was reported with a vague description of how to recreate
it_

This is something my current management fully understands, but I wish we could
get through to our clients. Short of being actively rude about bad requests
I've run out of ideas over the years. Luckily these days we are big enough
that I usually have a bit of a shield (provided first line support people and
BAs who I trust) between me and direct client contact.

I'm quick to put tickets on hold as "needs more information", and been around
long enough that I've developed the confidence to respond to "this is urgent,
there is an SLA" with "and that service level agreement covers a minimum level
of reporting from you before even an urgent matter can be progressed" or more
facetiously "then it is urgent that you furnish me with the information
requested", but while they _accept_ it each time they never _learn_ to give
better details up-front next time - we still get reports of "an error" or
something "not working" or, even worse, the open-ended question "is there a
problem with...?".

Obviously this can't be applied to truly urgent issues, but they are usually
massive problems that we are already aware of and working on before the client
contacts us because, for instance, we've had an alert that something is down
(sometimes we tell the client about an issue and resolution ETA before they
notice, which they seem pleasantly surprised by and thankful of).

~~~
C4stor
Decent logging of all changes and error happening on the platform I work on
usually lead me to pretty much the following dialog :

" \- I have a problem, the platform is broken" " \- Sure, do you have any
rough idea when that happened " (I discovered that weirdly, people are very
good to report a bug a day or even more after it actually happened) " \-
Around [some hours range]" (Get the logs for this time and this user) " \- Ok,
I see every information I need in the logs, it will be fixed soon"

And that's pretty much it. Oftentimes, I don't even need the time bit, just
finding the user history in the logs is enough.

I'm always puzzled at engineers rambling about "users never learn how to do a
correct bug report", but it seems like they themselves never actively learned
that and integrated it in their everyday life.

Since users indeed never learn, stop expecting them to !

~~~
dspillett
_> Since users indeed never learn, stop expecting them to !_

I don't expect them to. That doesn't mean I can't be irritated that they
don't!

We have various logs and audits too, that can usually be used to work out what
has happened. Sometimes alerts based on those logs mean we are already fixing
the issue before any user reports it. Even with full audits and other logs, it
is usually still quicker to locate and diagnose a problem if given what useful
information we know the user has access to (the standard set: approximate time
(at least the date if not today), what were you asking it to do, what did it
do instead, any error messages they were displayed).

If the user is give a message with a code that explicitly says "report this
number when you report the issue" and they don't bother (they just say "I got
an error") and that information would save me time, you bet your arse I'm
pushing the issue back onto the queue and getting on with some interesting
dev/infrastructure work until a better report arrives, or looking at another
issue where there _is_ decent information.

Want to be at the head of my TODO list? Then make at least a minute amount of
effort to help me help you.

It particularly bothers me when clients who negotiate a discount because they
won't need first-line support as they are "big enough to have a department
that triages that sort of thing", still send through terrible reports because
their idea of triage is just hitting the forward button whenever an email
comes in. I've got better things to be getting on with than providing free
outsourced work for a bad IT department!

I'm not very customer facing these days, since we have grown to the point
where I have a bit of a shield provided by our support/PS/BA teams, which is
good for both my irritation levels and the clients!

------
not2b
Too bad about the low-contrast gray on white text. It is a source of
eyestrain.

~~~
tempodox
Agreed, came here to say the same:

[https://contrastrebellion.com](https://contrastrebellion.com)

------
femiagbabiaka
[https://speakerdeck.com/jallspaw/findings-from-the-field-
dev...](https://speakerdeck.com/jallspaw/findings-from-the-field-devops-
enterprise-london-2020?slide=6)

this reminded me quite a bit of this deck -- in particular, a focus on a
shallow metric (in this case LoC) as a proxy for measuring complexity.

------
dllthomas
One of my favorite contributions involved two commits: one that added 5 lines,
another a bit later that removed a different 5 lines. This was after more than
a week of building tiny models to understand how the system might behave.
Thankfully I was on a team that appreciated it, although the reduced load on
on-call quickly drove the point home :)

------
zabzonk
Nobody should manage programmers who is not themselves a very experienced
programmer. Otherwise, you are in Dilbert Country.

~~~
msclrhd
The tricky part of this is that not all programmers make good managers, or
want to be promoted into management. They are different skill sets. That said,
having a basic understanding of the difficulties and things that take time
(learning new technology, investigating/debugging an issue, etc.) would be a
good thing to have as a manager. Also, being able to assist where possible --
asking if the developer needs someone to help out, finding people with the
relevant skills to mentor the developer (or finding suitable
courses/training/books), etc.

~~~
twodave
I mean, is it really this hard? This is not a good/bad manager problem to me,
this is an organizational culture kind of problem. As a manager I'd expect my
three top priorities to be ensuring enough devs are on the team, communicating
priorities effectively, and unblocking the devs on the team as needed.

------
Slartie
"Because I had to spend a lot of time to compile this long list of things that
I also did while fixing the problem which are essential for a good solution
but aren't immediately visible from the two lines I actually added so I would
have something in hand to rebut this stupid question of yours!"

------
whotheffknows
Because product managers struggle to comprehensively understand value add and
have instead replaced stating business goals and value add with bullying based
micro managing tactics like counting lines of code and conflating other such
arbitrary metrics related to code with having a 1:1 ratio of accomplishing the
goal and do not respect the thought of troubleshooting, architecture design
(unless you take another two days to turn it into a diagram presuming it needs
to be consumed by some other party) and finding an elegant way to implement
code to accomplish the goal as work because they can't see it, and they can't
understand it because they are too busy collecting visual days to prove they
are properly micromanaging you to take the time to learn the challenges
inherent to the architecture and challenge at hand.

Does that help?

------
White_Wolf
That sort of question is ussualy asked by a someone that either has no clue
how programming works or are just from the sales team. I do admit I left one
software company because of a manager like that that. Fixing bugs is
painful(to say the least) if you don't know the code properly. Even worse when
you have to "hit the ground running" and take over a project because the main
guy for it left "due to personal circumstances" or "difference in oppinion".
Ever since then: \- "If you think it can be done faster please go ahead." \-
"It will take as long as it takes, not a minute more" \- "if you really want a
time estimate: it will take me 4* <time I think it will>"

------
entha_saava
At what point we, as an industry, failed to mandate a level of technical
education for being a manager? Almost always the non technical people who
can't think beyond quarterly profits and their resumes are the biggest problem
of this industry.

~~~
arethuza
What industry requires a relevant 'practitioner' education for being a
manager?

~~~
WrtCdEvrydy
Aircraft carrier commanding officer must be a pilot...

~~~
arethuza
Well, I guess the whole concept of "officers" in militaries kind of fits?

------
graton
A good commit message can also help to explain why the two lines of code took
so long.

------
tdrp
We had a non-tech lead at some point (although his title was something like
development manager) and he would praise my coworker for how many check-ins he
did. Except that coworker would do things like:

1- Copy-paste an entire class into a new class and change a single constant in
it, because he was too lazy to do inheritance.

2- "Solve" multiple bugs a day that he had introduced himself the day before.

3- Loudly complain about other people's frameworks/codes.

He was the super confident type even though he was wrong more often than not.
But paired with a non-tech lead with his own impostor syndrome, it was a
recipe for disaster.

~~~
throwaway_dcnt
That word (imposter syndrome) does not mean what you think it does :)

------
lmilcin
Hindsight is 20/20.

It takes more work to produce succinct code and it can take surprising amount
of effort and care to land at a simple solution to a complex problem.

My solution is to try to involve other people in my "process". This helps me
transfer some knowledge of the decision process, helps debug ideas early on
and hopefully is useful mentoring for the team.

I can do this because I am senior engineer / tech lead at my org. For other
engineers I highly recommend pair programming and constantly rotate developer
pairs so that everybody can get some appreciation of everybody else.

------
augustk
With unit tests included it would probably be more than two lines.

~~~
cgrealy
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.

------
bpyne
So much good in this short piece. He sounds like someone I want on my team.

Users who work with IT often tend to give better descriptions and test cases.
Quite often I need more information though. He's right that you try not to
bother the reporting user. Sometimes there's no other way.

Reproducing a bug is often the most time-consuming part of a bug fix. It's
doubly difficult when you have a shared test environment and the bug leads you
into a shared data set. For instance, we have a scheduling table that's used
by many applications. I can't change the data, even on test, because it can
easily mess up other teams. So I have to make a copy of it to my schema, alter
data, and point the code to the altered copy.

"If some code is throwing an error, you could just wrap it in a try..catch
statement and suppress the error."

Yes, these developers exist. I worked with several over my career. They are
frustrating because they leave damage for other people to fix, often at the
worst time.

"Finding the exact cause of a problem, and looking at all the ways to get
there can provide valuable insights."

Yes a thousand times. Bug fixes are opportunities to learn more about a system
and, often, the user area for whom we wrote the software.

"I want a fix that isn't likely to cause confusion or other problems in the
future."

A good fix takes into account the overarching software design and fits it if
possible.

"I don't want a bug to be found in the future and for me to have to come back
to this code when I've mentally moved on. Context switching is expensive and
frustrating."

Writing software is building an abstract machine in your mind. These machines
get complicated. Even when you're fixing a system written by someone else, you
need time to "load" the machine into your mind.

The only time I don't like fixing bugs is when I'm against a deadline on
writing/modifying another system. The context switching is a deadline killer.
But, it happens. Nowadays I let the project manager know that I'm switching to
a bug fix, give an estimate of how long I'll be away from his/her project, and
my best guess on whether or not it'll cause a deadline slip.

Great post.

------
thayne
Only two days? I've spent two weeks on a single line bug fix before (although
I wrote quite a few more lines of unit tests to make sure it continued to
work).

------
kentlyons
One of my favorite personal commits was removing about 5000 lines of dead code
tightly woven into many other parts of the overall codebase.

------
laci37
This reminded me of this commit from my GSoC internship:
[https://github.com/lihaoyi/Ammonite/pull/93/commits/a5e30eff...](https://github.com/lihaoyi/Ammonite/pull/93/commits/a5e30eff4daf1082d080e95b9e099d4248f4f0f2)

This single change took more than a week of debugging.

------
shultays
I remember removing a single line taking me about a whole day. Was working on
an embedded c++ project (a tv) and for some reason it was randomly stucking in
an infinite loop. Debugging tools were minimal and it took me a while to
figure out it was stucking in some kind of mutex and all I did was removing
one mutex lock because it wasn't necessary.

------
Beldin
This reminds me of the story about an older engineer called in to fix a
computer problem. Previous efforts by the local IT staff had failed. In two
clicks, the problem was fixed. He charged $100 for it.

Outraged at having to pay $100 for two clicks the customer demanded an
itemised bill. The engineer wrote:

\- 2 clicks: $0.05 / click

\- knowing where to click: $999.90

------
alex_duf
I wrote a whirl article about a single line of code, I hope the mentality
starts to change.

[https://www.theguardian.com/info/2019/dec/02/faster-
postgres...](https://www.theguardian.com/info/2019/dec/02/faster-postgresql-
connection-recovery)

------
mongol
There is an annoying tendency that business people get the credit for coming
up with the ideas that bring in the value, and the IT people get the blame for
the defects and the problems that costs the business money. It is not like
that everywhere, but in companies where it is, it is unhealthy to work as the
IT staff.

------
kps
For a previous job long ago, I spent several months off and on working on an
obscure and difficult-to-reproduce bug, without success. A year after I was
laid off, a customer encounter a clear reproducing case, and I came back for a
day to work on it. The fix was _one character_ : < vs <=

------
arendtio
Actually this is one of the upsides of web development: Since every line
contributes to the file size of your software and therefore to the loading
time there is a motivation for keeping the code base small.

Sadly, there are many projects out there which obviously failed to reach this
target at some point.

~~~
aequitas
This can also go suprisingly wrong when management decides code size is the
performance metric needed to improve the site and hires a "performance
engineer" who abolishes all structure and abstraction in the code, making it
near-impossible to debug and maintain. But at least it runs fast.

~~~
arendtio
True, the quest to reach a small file size can also lead to various down-
sides. Cryptic architectures and weird code are just two popular symptoms.

------
cel1ne
This is not an IT specific problem.

For most jobs they don't do themselves people tend to understand the time it
takes.

------
electrondood
Had a PM ask why we were taking so long to build a future-proof platform when
this other team over here built an emergency project in 3 weeks.

Had to explain that that project was held together with duct tape, not one bit
of it was reusable, and even the engineers who build it were saying it was
shit.

~~~
jerzyt
I would've loved to be a fly on the wall in that meeting.

------
lowbloodsugar
Bill:

    
    
      Adding two lines:               $     1.
    
      Knowing which two lines to add: $10,000.
    

[https://www.snopes.com/fact-check/know-where-
man/](https://www.snopes.com/fact-check/know-where-man/)

------
icedchai
The real reasons: depressed due to the current world situation, browsing
reddit, HN, youtube, doing housework, checking stock portfolio, chatting with
friends. In between all these distractions, one does manage to get some work
done, at least 2 or 3 days a week.

------
bmcahren
If you work somewhere you're defending yourself from this question repeatedly,
just move on at your earliest convenience. They don't value quality developers
and you'll eventually turn into the low-quality developer they've always
wanted.

------
ngcc_hk
Trying to fix a very minor bug of a game of solitude of c heard from this
site. It is somewhere it must be missng a range check causing a core dump (or
whatever the name linux/macOS gave to the MVS thing). The problem is where is
it. 2 days now.

------
ChicagoDave
I can’t like this post enough. We are not accountable by lines of code.
Delivering healthy, maintainable software requires thought, experience, and
thorough testing. This is why companies have taken so long accepting the idea
of unit testing.

------
thysultan
>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.

~~~
eben-ezer
Not necessarily, not all testing means automated tests written in code. Manual
testing can be more effective in the short run sometimes

------
Beltiras
I love the bughunt. I hate greenfields. I procrastinate when I have to write a
project someone else has to maintain. I feel the pressure to perform.
Squishing bugs is fun. That was someone else who done the foulup.

------
Consultant32452
I spent a month figuring out a single line of configuration. That really hurt.

------
nojvek
I personally do value velocity not in number of lines, but in terms of
unblocking users and other team members.

So:

1) user wants X done. Focus on that. Help the user X done. First iteration you
have something crappy, doesn’t look great, too simple. That’s okay. Did it get
X done. Cool. If you shipped some pretty UI but users don’t actually use it
since it doesn’t solve the problem. That’s not productivity.

2) now that there are users using the tool, watch them use it. Ask questions,
look at th me dashboard. Optimize their flow to do X. Make the UI delightful.
We know with good certainty that this is a decent solution. Make it fast. Add
tests. Harden it up so someone else doesn’t break it accidentally.

So if someone added two lines of using some existing node module that solves
the user’s problem, those are very productive two lines.

------
celticninja
The fix is a refactor of a refactor of a refactor of the actual fix.

------
pjettter
I once reduced the amount of code for a client by ~75% and added usability and
fault-tolerance. I wasn't even half done and they thought it was good enough.
LoC is no measure.

------
ak39
Because coding is like the art and science of distillation. Cheers.

------
k__
Nobody I ever worked with cared for LoC.

They had a shitty bug. It took me a month to find and fix in the code. Wrote
about 5 LoC. Nobody asked how I fixed it, they just were happy that I did.

------
abraae
Most of the article is good, but this is weak:

> If some code is throwing an error, you could just wrap it in a try..catch
> statement and suppress the error. No error, no problem. Right? Sorry, for
> me, making the problem invisible isn't the same as fixing it. "Swallowing"
> an error can easily lead to other unexpected side-effects. I don't want to
> have to deal with them at a point in the future.

I actually did work with someone else who did this sort of thing, however it
is certainly not the normal in my experience, not for anyone who takes any
pride in their work.

Including this one really devalues the "it took so long because I'm so
professional" message IMO.

------
ablanco
It's really sad that people (managers) still thinks of code this way. Luckily
this has never happened to me, but if it did I think it would be a great sign
to change jobs.

------
doonesbury
Symptom v Root cause. Bad spec/no spec. Known issues in manufacturing since
pre-75. Software gotta get with the program...

------
bananaface
I sympathize with this, but taking two days to add two lines of code _is_
unproductive. Sorry, that's just not a lot of output. Two-day bugs happen, but
they should be rare. The real question is: is this rare, or is it typical for
this developer?

IMO the real problem is trying to evaluate an employee's productivity on the
scale of two days. There isn't enough context to understand the situation.

~~~
Cthulhu_
You CANNOT make any statements about whether or not a code change is
productive / unproductive if you do not know the context. It doesn't work like
that. Take any random commit on
[https://github.com/torvalds/linux/commits/master;](https://github.com/torvalds/linux/commits/master;)
most change just a handful of lines but I can guarantee that each of them
represents a significant time investment in analyzing, documenting, discussing
and testing the code change in question.

I mean I get where you're coming from, if your job is basic data wrangling
(webapp -> rest API -> back-end -> database and vice-versa) then you don't
need to put too much thought into it and just need the output. But that's only
one part of software development.

~~~
bananaface
I don't think we disagree. One line per day _can_ be a reasonable rate of
change. But usually it isn't. Usually that's too slow, and it's indicative of
an unproductive developer.

Everyone in the thread is defending the OP because the issue is relatable.
"He's productive, his manager doesn't understand!" Ok, maybe. But also maybe
his productivity is way below what he's being paid for. We don't know, we
don't have enough context to judge.

------
RocketSyntax
The hardest and most time consuming work is the architecture/design. The code
should be the easy part.

------
CodeWriter23
Dude, you could have just said “because I take my job seriously and executed
with complete diligence”.

------
m3kw9
Cuz trying to understand someone’s code, testing, debugging and finally apply
the fix, and test again.

------
reactor
Programming is like playing chess, the move only takes about seconds, but what
to move takes time.

------
goatinaboat
The response to a manager who says this is, you don’t do anything at all, why
are you even here?

------
pocw
MAKING CHALK MARK ON GENERATOR $1. KNOWING WHERE TO MAKE MARK $9,999. -Charles
Proteus Steinmetz

------
pauljurczak
You've only written a few letters. How long does it take to write: "e = mc^2"?

------
mrwh
"Because the text was so light it was difficult to read"

Snark aside, it's quite a good list.

------
jmartrican
Because i wrote failing unit/integration tests before implementing the
solution.

------
k3liutZu
I once spent a week just to add a ";" in the right place to fix a bug.

------
irrational
I just spent 3 days figuring out that I needed to remove a single line.

------
shoes_for_thee
It's beside the point, but grey-on-white fonts give me a headache.

------
csours
Because looking at this code feels like walking on broken glass.

------
pibsd
Mmh there should be more than two added lines if he wrote tests, no? I know
some bugs are difficult to track, reproduce, and fix. But whenever I can I
write as much as automated tests to check that the bug has really been
removed.

------
jrochkind1
Hey, sometimes it takes two days to REMOVE 2 lines of code!

------
29athrowaway
Because the code is architected like a Jenga tower.

------
wilmoore
anxiety === lack of documentation + lack of frequent communication + general
desire to be _done_ as soon as possible

------
cesaref
2 lines of code? Where's the test cases?

------
cmollis
this happened to me.. except it was one line: free(ptr); / __here it is --- >
*/ ptr = 0x00;

a classic.

------
jiveturkey
you think adding code takes a long time? try removing code!

------
known
Doesn't stand good to ask a doctor

------
pibsd
There should be more than two lines of codes added anyway: whenever I can I
add as much as automated tests as needed to check that the bug has really been
removed.

