31 ms·

You've only added two lines – why did that take two days?

• ChicagoDave 6y ago
  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.
• slaymaker1907 6y ago
  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 6y ago
    I know this behavior.
• Beltiras 6y ago
  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.
• doonesbury 6y ago
  Symptom v Root cause. Bad spec/no spec. Known issues in manufacturing since pre-75. Software gotta get with the program...
• TallGuyShort 6y ago
  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"
• ww520 6y ago
  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.
  • bedobi 6y ago
    slow clap you've pointed out something very true and very problematic that I've never even really noticed
  • giovannibajo1 6y ago
    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 6y ago
      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.
• pocw 6y ago
  MAKING CHALK MARK ON GENERATOR $1. KNOWING WHERE TO MAKE MARK $9,999. -Charles Proteus Steinmetz
• mongol 6y ago
  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.
• RocketSyntax 6y ago
  The hardest and most time consuming work is the architecture/design. The code should be the easy part.
• shultays 6y ago
  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.
• phreack 6y ago
  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/
• thysultan 6y ago
  >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 6y ago
    Not necessarily, not all testing means automated tests written in code. Manual testing can be more effective in the short run sometimes
• snidane 6y ago
  "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 6y ago
    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 6y ago
      > 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.
      • 6y ago
• kabdib 6y ago
  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.
• kps 6y ago
  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 <=
• jerzyt 6y ago
  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.
• 29athrowaway 6y ago
  Because the code is architected like a Jenga tower.
• electrondood 6y ago
  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 6y ago
    I would've loved to be a fly on the wall in that meeting.
• Consultant32452 6y ago
  I spent a month figuring out a single line of configuration. That really hurt.
• thayne 6y ago
  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).
• lowbloodsugar 6y ago
  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/
• pibsd 6y ago
  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.
• pibsd 6y ago
  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.
• cel1ne 6y ago
  This is not an IT specific problem. For most jobs they don't do themselves people tend to understand the time it takes.
• caseymarquis 6y ago
  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.
• abraae 6y ago
  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.
• reactor 6y ago
  Programming is like playing chess, the move only takes about seconds, but what to move takes time.
• m4rtink 6y ago
  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)
• cesaref 6y ago
  2 lines of code? Where's the test cases?
• nojvek 6y ago
  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.
• deleted 6y ago
  [deleted]
• ngcc_hk 6y ago
  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.
• mro_name 6y ago
  E = m c² is just three letters and a bit of gutter, how long could that possibly take to figure out?
  • hackerman123469 6y ago
    Thanks, gonna use that argument in the future
• abalashov 6y ago
  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. :-)
• irrational 6y ago
  I just spent 3 days figuring out that I needed to remove a single line.
• sriku 6y ago
  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 6y ago
    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 6y ago
      Some fun folklore involving Bill Atkinson at Apple - logging "-2000" lines of code written. https://www.folklore.org/StoryView.py?story=Negative_2000_Lines_Of_Code.txt https://www.folklore.org/StoryView.py?story=Negative_2000_Li...
• elnygren 6y ago
  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?
  • raducu 6y ago
    "I try and do as much as I can with the information provided." I know I'm guilty of this one, and I've stayed away from high paced jobs and appreciate jobs where people are ok with my reluctance to bother a lot of people even if that means it takes me longer to figure things out on my own. This also means I build a much deeper understaning of the systems I work with, or at least I like to think so, and some people have confirmed that about me, indirectly, by praises of my insights.
    • corin_ 6y ago
      Their praise is obviously great for knowing how you're doing, but it doesn't confirm the reason for your good insights. Plenty of people manage to be good at what they do without doing 100% the best way possible, so maybe you'd be even better if you changed your approach! Of course I know nothing about you so I'm not trying to give advice, just replying about the "confirmed" being a potential cognitive bias.
• lavametender 6y ago
  +2 lines? That's rookie numbers! https://www.folklore.org/StoryView.py?story=Negative_2000_Lines_Of_Code.txt https://www.folklore.org/StoryView.py?story=Negative_2000_Li...
  • nucleardog 6y ago
    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.
• bananaface 6y ago
  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_ 6y ago
    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 6y ago
      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.
• pauljurczak 6y ago
  You've only written a few letters. How long does it take to write: "e = mc^2"?
• entha_saava 6y ago
  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 6y ago
    What industry requires a relevant 'practitioner' education for being a manager?
    • WrtCdEvrydy 6y ago
      Aircraft carrier commanding officer must be a pilot...
      • arethuza 6y ago
        Well, I guess the whole concept of "officers" in militaries kind of fits?
• dspillett 6y ago
  > 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 6y ago
    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 !
• k3liutZu 6y ago
  I once spent a week just to add a ";" in the right place to fix a bug.
• rburhum 6y ago
  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 6y ago
    Nice! I had something similar. It took over a week and the fix was to _remove_ one line of code.
• notsag-hn 6y ago
  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)
• goatinaboat 6y ago
  The response to a manager who says this is, you don’t do anything at all, why are you even here?
• alex_duf 6y ago
  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-postgresql-connection-recovery https://www.theguardian.com/info/2019/dec/02/faster-postgres...
• White_Wolf 6y ago
  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>"
• k__ 6y ago
  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.
• bpyne 6y ago
  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.
• kmclean 6y ago
  > 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.
• laci37 6y ago
  This reminded me of this commit from my GSoC internship: https://github.com/lihaoyi/Ammonite/pull/93/commits/a5e30eff4daf1082d080e95b9e099d4248f4f0f2 https://github.com/lihaoyi/Ammonite/pull/93/commits/a5e30eff... This single change took more than a week of debugging.
• jrochkind1 6y ago
  Hey, sometimes it takes two days to REMOVE 2 lines of code!
• Beldin 6y ago
  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
• known 6y ago
  Doesn't stand good to ask a doctor
• icedchai 6y ago
  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.
• wilmoore 6y ago
  anxiety === lack of documentation + lack of frequent communication + general desire to be _done_ as soon as possible
• rmason 6y ago
  Because I had to explore all the things that wouldn't work before finding the two lines that did.
  • newshorts 6y ago
    This summarizes the argument pretty well and should suffice as a tl;dr.
• RandomInteger4 6y ago
  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 6y ago
    Because I have spent time thinking, not merely typing. (The error "programmers are just overpaid typists" is widespread)
    • Jtsummers 6y ago
      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 6y ago
        Where does program specification ends and where does program logic starts ?
        • Jtsummers 6y ago
          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.
• celticninja 6y ago
  The fix is a refactor of a refactor of a refactor of the actual fix.
• kevsim 6y ago
  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.
  • jakemal 6y ago
    I have never had anyone indicate to me that this is a problem. However, every time I spend days on a problem that ends up being a trivial number of LOC, I get a feeling of anxiety that I am going to be seen as incompetent. That's been the case my whole career even though I know it's unfounded.
  • ww520 6y ago
    Yes, it happens, quite a lot.
  • l0b0 6y ago
    So far I've worked in one place which didn't use version control in 2007, one place which had reluctantly started using version control just before I started in 2010, several places where automated tests were considered pure waste, where everybody had full access to production, where backups were untested, where one or two people held crucial knowledge which was not shared with anybody else, etc. The real world moves a hell of a lot slower than best practice.
    • musingsole 6y ago
      Devil's advocate: or best practices are rarely incentivized...because there's little to connect them with real, tangible value in an organization. Having fully linted, automatically tested code doesn't matter if the product isn't valuable and useful. And if the product is truly valuable and useful, it likely would be as well in the absence of these practices.
      • Piskvorrr 6y ago
        Fair point. I did take a week's tally of "how much developer time did we burn on hunting for backups and rogue edits", and suddenly SVN was orders of magnitude more attractive (ages ago).
• Piskvorrr 6y ago
  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 6y ago
    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 6y ago
      That's a literal Dilbert strip, 1998-ish, IIRC.
      • deleted 6y ago
        [deleted]
      • thaumasiotes 6y ago
        https://dilbert.com/strip/1995-11-13 https://dilbert.com/strip/1995-11-13
        • Piskvorrr 6y ago
          Ah, that's the one. I have misremembered it slightly...
• newshorts 6y ago
  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.
  • gitgud 6y ago
    Yeah I thought that was really bad advice, especially for incomplete bug reports. There's literally no harm in asking for more information to fix a bug, except for your ego... A 5 minute phone call or direct message can save hours of hunting and frustration trying to replicate the bug...
  • c0nsumer 6y ago
    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.)
    • newshorts 6y ago
      True, having seen this as well, the motivation driving the dev does eventually become pretty transparent.
    • bonestamp2 6y ago
      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.
    • gshulegaard 6y ago
      I too have seen the case when a developer will ask for more information in order to game the process. While this is arguably (and I would agree) a failure of the process since it incentivizes undesirable behavior, you can quickly wind up in a situation where there is a large cadre of developers who will reflexively ask for detail. In this situation you often have good "measured" performance across the engineering org, but there tends to also be a large swath of tickets which find themselves in limbo. Some of these tickets can take months to resolve when a day or two of concentrated effort could have resolved it.
• pdpi 6y ago
  “I’m sorry for the long letter, but I didn’t have the time to write a shorter one.”
• Slartie 6y ago
  "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!"
• glouwbug 6y ago
  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 6y ago
    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 6y ago
      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.
• ablanco 6y ago
  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.
• caymanjim 6y ago
  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.
  • cosmodisk 6y ago
    It's all correct: 90% takes 5 days and the rest 10% will take 3 months.
    • dwd 6y ago
      Except the UI guys chewed through 2 months in elapsed time getting the design approved and across the line and you now have to compress the 3 months you told them you would need into one to meet the delivery date management had in mind.
  • zachrose 6y ago
    I sometimes look at small mass-produced plastic items and marvel at how hard it would be to make one from scratch. If you showed me, say, a fluted plastic bottle of wite-out with a screw-on cap, I would have to assume you had a very expensive operation up and running that was already churning these out. In software we can put a few shapes on a screen in just the right context and people will believe there's an operation as sophisticated as the wite-out bottle factory behind it.
    • DougWebb 6y ago
      You could spend a few hours making a 3D print of that bottle to produce a very believable mock-up. And then use it with someone gullible to make a deal on an order to manufacture a million of them. You get your commission on the sale, toss the 3D print to your manufacturing engineer, and let them know the customer needs delivery next week.
• dev_tty01 6y ago
  -2000 lines of code. https://www.folklore.org/StoryView.py?project=Macintosh&story=Negative_2000_Lines_Of_Code.txt https://www.folklore.org/StoryView.py?project=Macintosh&stor...
  • tommyage 6y ago
    I smirked reading your linked text. Commonsense required though.
• ilyas121 6y ago
  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.
• adrianmonk 6y ago
  You've only rendered one two-word verdict -- why did that take five days of deliberation? You had twelve people working on it!
• whoisjuan 6y ago
  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 6y ago
    Seriously, Albert? You spent 7 years and "E = mc2" is all you produced? We need to talk.
    • quickthrower2 6y ago
      Michelin Star: 1kg food 2 Stars: 2kg food 3 Stars: 3kg food “Well KFC can do it...”
  • joe_the_user 6y ago
    I know the reasons for not producing code consistently. They're logical and I can even verify them. BUT I am still frustrated with myself when I don't produce significant code each day.
• arendtio 6y ago
  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 6y ago
    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 6y ago
      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.
• BurningFrog 6y ago
  Conclusions: 1. Picking a good manager is very important! 2. Communicating with your manager is very important!
  • Lammy 6y ago
    1. Being in a position where you have the privilege of being able to pick a good manager is important :)
    • williamdclt 6y ago
      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 6y ago
        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.
• zabzonk 6y ago
  Nobody should manage programmers who is not themselves a very experienced programmer. Otherwise, you are in Dilbert Country.
  • msclrhd 6y ago
    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 6y ago
      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.
• shoes_for_thee 6y ago
  It's beside the point, but grey-on-white fonts give me a headache.
• jedberg 6y ago
  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.
• not2b 6y ago
  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.
  • vikramkr 6y ago
    That's a pretty bad breakdown in communication- the manager should have communicated how the contractor was paid and the programmer should have spent their time working in line with that - whichever end that breakdown happened on that sounds like that led to an awful lot of misery and wasted time - ouch
    • thaumasiotes 6y ago
      > That's a pretty bad breakdown in communication- the manager should have communicated how the contractor was paid and the programmer should have spent their time working in line with that Seems more like a breakdown in negotiating the contract than a breakdown in communication. No customer is actually interested in having the programmer do their work in line with a compensation scheme that pays more for more lines of code.
  • pintxo 6y ago
    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 */ }
    • flingo 6y ago
      As long as this is contained to the metrics-metagame branch of the git repo, I am fine with this. Get 80k commits in, before lunch.
    • ZoomZoomZoom 6y ago
• deleted 6y ago
  [deleted]
• not2b 6y ago
  Too bad about the low-contrast gray on white text. It is a source of eyestrain.
  • tempodox 6y ago
    Agreed, came here to say the same: https://contrastrebellion.com https://contrastrebellion.com
  • yongjik 6y ago
    Came here to say this. Gray on white for anything other than disabled options is a sin. This website is particularly egregious.
• rubyn00bie 6y ago
  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 6y ago
    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 6y ago
      > LOC is a decent measure, but features are our targets Only if your measure of success is tied to fewer LOC.
      • greggman3 6y ago
        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.
      • el_oni 6y ago
        I'm not sure I got across what I mean. Ones target should be shipping features. If you use 10k LOC to get a feature out, or 500 lines of more concise, optimised code, what matters is the feature. If you have LOC targets to meet you are incentivised to produce the former rather than the latter. My point is that a high number of lines isn't as important as good features. Though the two can get conflated
• graton 6y ago
  A good commit message can also help to explain why the two lines of code took so long.
• addicted44 6y ago
  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.
• mrwh 6y ago
  "Because the text was so light it was difficult to read" Snark aside, it's quite a good list.
• ak39 6y ago
  Because coding is like the art and science of distillation. Cheers.
• m3kw9 6y ago
  Cuz trying to understand someone’s code, testing, debugging and finally apply the fix, and test again.
• csours 6y ago
  Because looking at this code feels like walking on broken glass.
• cmollis 6y ago
  this happened to me.. except it was one line: free(ptr); / here it is ---> */ ptr = 0x00; a classic.
• dllthomas 6y ago
  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 :)
• augustk 6y ago
  With unit tests included it would probably be more than two lines.
  • cgrealy 6y ago
    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.
• kentlyons 6y ago
  One of my favorite personal commits was removing about 5000 lines of dead code tightly woven into many other parts of the overall codebase.
• bmcahren 6y ago
  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.
• mirekrusin 6y ago
  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
  • pjgalbraith 6y ago
    This rings very true to me. Unfortunately the subtleties of development like code quality aren't well represented if you only look at cards moving on a board. In a lot of ways what you are describing is how it should work, that the tech lead works on the hard problems and big-picture problems, like abstractions and architectural issues, as well as mentoring junior devs. In my opinion any manager (especially a non-technical one) should only measure the team as a unit. This is particularly important when evaluating the performance of a tech lead. One thing I like to look for is natural lines of conflict in a situation that can arise when different individuals are working towards different goals, and question the underlying reasons why a manager may be acting the way they are. In a lot of cases you can get to a win-win situation if everyone is willing to play ball. Of course if the conflict arises from a fundamental organisational flaw, like poor management methods, or poor company culture, then it is time to move on.
  • ipnon 6y ago
    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.
• jmartrican 6y ago
  Because i wrote failing unit/integration tests before implementing the solution.
• mastazi 6y ago
  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).
• tdrp 6y ago
  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 6y ago
    That word (imposter syndrome) does not mean what you think it does :)
• CodeWriter23 6y ago
  Dude, you could have just said “because I take my job seriously and executed with complete diligence”.
• femiagbabiaka 6y ago
  https://speakerdeck.com/jallspaw/findings-from-the-field-devops-enterprise-london-2020?slide=6 https://speakerdeck.com/jallspaw/findings-from-the-field-dev... 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.
• whotheffknows 6y ago
  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?
• arnvald 6y ago
  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 6y ago
    Deleting code is giving your future self a gift of not having to maintain that code anymore.
    • Scramblejams 6y ago
      Yes, I like to say it as "A line of code deleted is a line of code debugged."
• otikik 6y ago
  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_ 6y ago
    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 6y ago
      Another Picasso anecdote: someone saw his doodles and said "pfft, I could do that!" He replied "So why haven't you?"
• rurp 6y ago
  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?
  • csharptwdec19 6y ago
    Oddly, I've worked at places where they PREFERRED minimized changes to bugs. i.e. "You made a whole new method to deal with this problem, is there a smaller fix?" Thankfully most places I've been at -prefer- a smaller fix even if it takes a little longer to figure out.
  • flukus 6y ago
    > 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".
• eikenberry 6y ago
  > 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 6y ago
    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.
• pjettter 6y ago
  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.
• deleted 6y ago
  [deleted]
• lmilcin 6y ago
  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.
• jiveturkey 6y ago
  you think adding code takes a long time? try removing code!