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.
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...<p>"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."
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.<p>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.<p>ie. if you are not doing <a href="https://en.wikipedia.org/wiki/Five_whys" rel="nofollow">https://en.wikipedia.org/wiki/Five_whys</a> then you might be doing it wrong and wasting time because of it.<p>I'm referring to this:<p>> 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.<p>Which seems like being stubborn and making a mistake because of it.<p>Couple other parts also seem a bit overdoing it:<p>> 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.<p>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?
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.
"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."<p>~ Edsger Dijkstra
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.<p>This example is just one case/symptom of much larger problem.<p>Non-tech managers will only see fast progress on combination of:
- poor developer
- doing fast progress
- with shitty code
- on good quality codebase<p>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
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.<p>It always gives me a pause, and then I would double the schedule.
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.<p>Often times asking for more information can speed things up and lead to a quicker resolution.
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 <i>data</i> breakpoints implemented for C++. It took a month... and the fix was also a two-liner. Still proud of that fix 17 years later!
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.<p>[0]<a href="https://www.snopes.com/fact-check/know-where-man/" rel="nofollow">https://www.snopes.com/fact-check/know-where-man/</a>
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.<p>This could be as simple as notes logged against an issue about experiments done, etc.
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.<p>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".<p>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. :-)
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.
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.
> I don't like having to fix bugs.<p>???<p>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.
This article made a number of great points.<p>> 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.<p>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.<p>> Because I took the time to verify if there were other parts of the code that might be affected in similar ways.<p>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?
> 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.<p>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.<p>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.
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.<p>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.
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.
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.
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.
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)
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.<p>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.
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"
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.<p>The author's approach is good for external bug reports, but they don't clarify that's indeed the case here.<p>I have to strongly appreciate the author for finding the root cause and tackling that instead of the symptom.<p>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.<p>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.
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.
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.<p>Or the real reason it takes 2 days is that the code base is a big ball of unbuttered spaghetti with no tests.<p>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.
Two lines ? Bah, a one line fix took me 5 weeks once!<p>(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)
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."<p>I think the OP covers this case very well.
I agree with the general sentiment of the article, but the following is a big mistake IMHO:<p>> 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.<p>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).
<i>> You've only added two lines – why did that take two days?</i><p>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!<p><i>> Because the issue was reported with a vague description of how to recreate it</i><p>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.<p>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 <i>accept</i> it each time they never <i>learn</i> 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...?".<p>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).
<a href="https://speakerdeck.com/jallspaw/findings-from-the-field-devops-enterprise-london-2020?slide=6" rel="nofollow">https://speakerdeck.com/jallspaw/findings-from-the-field-dev...</a><p>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.
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 :)
"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!"
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.<p>Does that help?
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>"
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.
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:<p>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.<p>2- "Solve" multiple bugs a day that he had introduced himself the day before.<p>3- Loudly complain about other people's frameworks/codes.<p>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.
Hindsight is 20/20.<p>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.<p>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.<p>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.
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).
So much good in this short piece. He sounds like someone I want on my team.<p>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.<p>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.<p>"If some code is throwing an error, you could just wrap it in a try..catch statement and suppress the error."<p>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.<p>"Finding the exact cause of a problem, and looking at all the ways to get there can provide valuable insights."<p>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.<p>"I want a fix that isn't likely to cause confusion or other problems in the future."<p>A good fix takes into account the overarching software design and fits it if possible.<p>"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."<p>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.<p>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.<p>Great post.
This reminded me of this commit from my GSoC internship: <a href="https://github.com/lihaoyi/Ammonite/pull/93/commits/a5e30eff4daf1082d080e95b9e099d4248f4f0f2" rel="nofollow">https://github.com/lihaoyi/Ammonite/pull/93/commits/a5e30eff...</a><p>This single change took more than a week of debugging.
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.
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.<p>Outraged at having to pay $100 for two clicks the customer demanded an itemised bill.
The engineer wrote:<p>- 2 clicks: $0.05 / click<p>- knowing where to click: $999.90
I wrote a whirl article about a single line of code, I hope the mentality starts to change.<p><a href="https://www.theguardian.com/info/2019/dec/02/faster-postgresql-connection-recovery" rel="nofollow">https://www.theguardian.com/info/2019/dec/02/faster-postgres...</a>
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.
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 <i>one character</i>: < vs <=
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.<p>Sadly, there are many projects out there which obviously failed to reach this target at some point.
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.<p>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.
Bill:<p><pre><code> Adding two lines: $ 1.
Knowing which two lines to add: $10,000.
</code></pre>
<a href="https://www.snopes.com/fact-check/know-where-man/" rel="nofollow">https://www.snopes.com/fact-check/know-where-man/</a>
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.
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.
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.
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.
>Because I tested the change thoroughly and verified that it addressed the problem for all the different code paths that were affected.<p>Doesn't this imply that the'd be more than two lines of code unless they're not counting the tests.
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.
I personally do value velocity not in number of lines, but in terms of unblocking users and other team members.<p>So:<p>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.<p>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.<p>So if someone added two lines of using some existing node module that solves the user’s problem, those are very productive two lines.
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.
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.
Most of the article is good, but this is weak:<p>> 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.<p>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.<p>Including this one really devalues the "it took so long because I'm so professional" message IMO.
Nobody I ever worked with cared for LoC.<p>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.
I sympathize with this, but taking two days to add two lines of code <i>is</i> 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?<p>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.
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.
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.