You've only added two lines – why did that take two days? - <AUTHOR> https://www.mrlacey.com/2020/07/youve-only-added-two-lines-why-did-that.html <comment><USER2> 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.

<comment><USER3> Early in my career, I learned a simple 'demo day' rule: never demo things that aren't end-to-end _done._

When you do, it can easily confuse folks who aren't deeply involved in your project ("haven't I seen this already?") and can hurt team morale because they never get a "shipped it" moment that feels good.

More to the point: enforcing this rule incentivizes teams to build things in small, shippable components. Nobody wants to be left out of demo day multiple weeks in a row.

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

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

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

<comment><USER4> > Not everything can be broken down into chunks of work that fit into a single > sprint.

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

<comment><USER5> How much brownfield work have you done?

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

<comment><USER4> > How much brownfield work have you done?

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

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

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

</comment></comment></comment></comment></comment></comment><comment><USER6> 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."

<comment><USER7> 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)

<comment><USER8> > LOC is a decent measure, but features are our targets

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

<comment><USER9> 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.

</comment></comment></comment></comment><comment><USER10> 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?

<comment><USER11> > How often do you actually receive quality bug reports at work?

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

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

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

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

</comment></comment></comment><comment><USER13> 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.

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

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

<comment><USER15> What an absurd response from your manager.

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

I hope you find better pastures.

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

</comment></comment></comment></comment><comment><USER17> "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

<comment><USER18> 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.

<comment><USER19> > 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.

<comment><USER20> "In our case, we're letting good enough be the enemy of barely tolerable."

</comment></comment></comment></comment><comment><USER21> 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

<comment><USER22> 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.

</comment></comment><comment><USER23> 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.

<comment><USER24> 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.

<comment><USER25> 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.

<comment><USER26> That's a very broad generalization.

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

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

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

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

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

</comment></comment></comment></comment><comment><USER27> 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.

<comment><USER28> 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.)

<comment><USER29> 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.

</comment></comment></comment><comment><USER30> "I'm sorry for the long letter, but I didn't have the time to write a shorter one."

</comment><comment><USER31> Because I had to explore all the things that wouldn't work before finding the two lines that did.

<comment><USER27> This summarizes the argument pretty well and should suffice as a tl;dr.

</comment></comment><comment><USER32> 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!

<comment><USER33> Nice! I had something similar. It took over a week and the fix was to _remove_ one line of code.

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

<comment><USER35> I smirked reading your linked text. Commonsense required though.

</comment></comment><comment><USER36> 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/)

</comment><comment><USER37> 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.

<comment><USER38> 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)

<comment><USER37> Some fun folklore involving Bill Atkinson at Apple - logging "-2000" lines of code written.

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

</comment></comment></comment><comment><USER39> 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. :-)

</comment><comment><USER40> 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.

<comment><USER41> Deleting code is giving your future self a gift of not having to maintain that code anymore.

<comment><USER42> Yes, I like to say it as "A line of code deleted is a line of code debugged."

</comment></comment></comment><comment><USER43> 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.

<comment><USER44> Seriously, Albert? You spent 7 years and "E = mc2" is all you produced? We need to talk.

<comment><USER45> Michelin Star: 1kg food

2 Stars: 2kg food

3 Stars: 3kg food

"Well KFC can do it..."

</comment></comment></comment><comment><USER46> > 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.

<comment><USER47> 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.

</comment></comment><comment><USER48> 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?

<comment><USER49> > 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".

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

</comment><comment><USER51> 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.

<comment><USER52> 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;
        }

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

</comment></comment></comment><comment><USER54> > 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.

</comment><comment><USER55> 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.

</comment><comment><USER56> 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.

<comment><USER20> Because I have spent time thinking, not merely typing. (The error "programmers are just overpaid typists" is widespread)

<comment><USER57> 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.)

<comment><USER58> Where does program specification ends and where does program logic starts ?

<comment><USER57> 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.

<comment><USER58> What happens in case where specification is:

[User inputs X1, system displays Y]

On system crash user input was X2.

Is this specification or program logic error ?

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

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

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

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

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

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

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

<comment><USER58> If I understand correctly, specification describes "what/when" and program logic describes only "how".

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER59> 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.

<comment><USER60> 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 */
        }

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

</comment></comment></comment><comment><USER62> 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.

<comment><USER63> 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.

<comment><USER64> 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.

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

</comment><comment><USER65> 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.

</comment><comment><USER66> 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"

</comment><comment><USER67> 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.

</comment><comment><USER20> 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.

<comment><USER68> 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.

<comment><USER20> That's a literal Dilbert strip, 1998-ish, IIRC.

<comment><USER69> [https://dilbert.com/strip/1995-11-13](https://dilbert.com/strip/1995-11-13)

<comment><USER20> Ah, that's the one. I have misremembered it slightly...

</comment></comment></comment></comment></comment><comment><USER70> Conclusions:

1\. Picking a good manager is very important!

2\. Communicating with your manager is very important!

<comment><USER71> 1\. Being in a position where you have the privilege of being able to pick a good manager is important :)

<comment><USER72> 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)

<comment><USER71> 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.

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

<comment><USER74> 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.

</comment></comment><comment><USER75> 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.

</comment><comment><USER76> 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.

<comment><USER77> I know this behavior.

</comment></comment><comment><USER78> 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.

</comment><comment><USER79> 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)

</comment><comment><USER80> 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.

</comment><comment><USER81> E = m c² is just three letters and a bit of gutter, how long could that possibly take to figure out?

<comment><USER82> Thanks, gonna use that argument in the future

</comment></comment><comment><USER83> 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).

</comment><comment><USER84> _> 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).

<comment><USER85> 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 !

<comment><USER84> _> Since users indeed never learn, stop expecting them to !_

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

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

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

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

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

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

</comment></comment></comment><comment><USER59> Too bad about the low-contrast gray on white text. It is a source of eyestrain.

<comment><USER86> Agreed, came here to say the same:

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

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

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

</comment><comment><USER88> 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 :)

</comment><comment><USER89> Nobody should manage programmers who is not themselves a very experienced programmer. Otherwise, you are in Dilbert Country.

<comment><USER90> 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.

<comment><USER91> 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.

</comment></comment></comment><comment><USER92> "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!"

</comment><comment><USER93> 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?

</comment><comment><USER94> 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>"

</comment><comment><USER95> 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.

<comment><USER96> What industry requires a relevant 'practitioner' education for being a manager?

<comment><USER97> Aircraft carrier commanding officer must be a pilot...

<comment><USER96> Well, I guess the whole concept of "officers" in militaries kind of fits?

</comment></comment></comment></comment><comment><USER98> A good commit message can also help to explain why the two lines of code took so long.

</comment><comment><USER99> 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.

<comment><USER100> That word (imposter syndrome) does not mean what you think it does :)

</comment></comment><comment><USER101> 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.

</comment><comment><USER102> With unit tests included it would probably be more than two lines.

<comment><USER64> 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.

</comment></comment><comment><USER103> 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).

</comment><comment><USER104> 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.

</comment><comment><USER105> One of my favorite personal commits was removing about 5000 lines of dead code tightly woven into many other parts of the overall codebase.

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

This single change took more than a week of debugging.

</comment><comment><USER107> 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.

</comment><comment><USER108> 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

</comment><comment><USER109> I wrote a whirl article about a single line of code, I hope the mentality starts to change.

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

</comment><comment><USER110> 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.

</comment><comment><USER111> 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 <=

</comment><comment><USER63> 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.

<comment><USER112> 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.

<comment><USER63> 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.

</comment></comment></comment><comment><USER113> This is not an IT specific problem.

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

</comment><comment><USER114> 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.

<comment><USER80> I would've loved to be a fly on the wall in that meeting.

</comment></comment><comment><USER115> 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/)

</comment><comment><USER116> 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.

</comment><comment><USER117> 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.

</comment><comment><USER118> 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.

</comment><comment><USER119> 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.

</comment><comment><USER120> >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.

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

</comment></comment><comment><USER121> 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.

</comment><comment><USER122> I spent a month figuring out a single line of configuration. That really hurt.

</comment><comment><USER123> 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.

</comment><comment><USER124> The fix is a refactor of a refactor of a refactor of the actual fix.

</comment><comment><USER125> 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.

</comment><comment><USER126> Because coding is like the art and science of distillation. Cheers.

</comment><comment><USER127> 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.

</comment><comment><USER128> 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.

</comment><comment><USER129> 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.

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

</comment><comment><USER131> 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.

<comment><USER52> 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.

<comment><USER131> 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.

</comment></comment></comment><comment><USER132> The hardest and most time consuming work is the architecture/design. The code should be the easy part.

</comment><comment><USER133> Dude, you could have just said "because I take my job seriously and executed with complete diligence".

</comment><comment><USER134> Cuz trying to understand someone's code, testing, debugging and finally apply the fix, and test again.

</comment><comment><USER135> Programming is like playing chess, the move only takes about seconds, but what to move takes time.

</comment><comment><USER136> The response to a manager who says this is, you don't do anything at all, why are you even here?

</comment><comment><USER137> MAKING CHALK MARK ON GENERATOR $1. KNOWING WHERE TO MAKE MARK $9,999. -Charles Proteus Steinmetz

</comment><comment><USER138> You've only written a few letters. How long does it take to write: "e = mc^2"?

</comment><comment><USER139> "Because the text was so light it was difficult to read"

Snark aside, it's quite a good list.

</comment><comment><USER140> Because i wrote failing unit/integration tests before implementing the solution.

</comment><comment><USER8> I once spent a week just to add a ";" in the right place to fix a bug.

</comment><comment><USER141> I just spent 3 days figuring out that I needed to remove a single line.

</comment><comment><USER142> It's beside the point, but grey-on-white fonts give me a headache.

</comment><comment><USER143> Because looking at this code feels like walking on broken glass.

</comment><comment><USER144> 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.

</comment><comment><USER145> Hey, sometimes it takes two days to REMOVE 2 lines of code!

</comment><comment><USER146> Because the code is architected like a Jenga tower.

</comment><comment><USER147> 2 lines of code? Where's the test cases?

</comment><comment><USER148> anxiety === lack of documentation + lack of frequent communication + general desire to be _done_ as soon as possible

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

a classic.

</comment><comment><USER150> you think adding code takes a long time? try removing code!

</comment><comment><USER151> Doesn't stand good to ask a doctor

</comment><comment><USER144> 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.</comment>


Creating a conference about Failures in Software - <AUTHOR> http://glyph.twistedmatrix.com/2008/07/conference-fail.html <comment><USER2> It's an old adage that you learn more from your failures than your successes. It's sort of left unsaid that learning from others failures is quite a bit easier.</comment>


Ask HN: Is Firebase Down? - <AUTHOR> I am not able to connect to firebase services. All my applications running on firebase seem to be down. Anyone else facing this problem? <comment><USER2> As of 8:06:07 AM PDT, all of my Firebase projects in us-central1 are back up.

We saw a complete silencing of our highly used Cloud Functions between 7:15 AM PDT and 7:38 AM PDT, but had reports from our users as early as 7:10 AM PDT.

My favorite part about [https://status.cloud.google.com/incident/zall/20005](https://status.cloud.google.com/incident/zall/20005) is that 7:49 AM PDT's update acknowledges that customers can't create support requests. Not like they'd do anything. Every time we've gone to GCP support, we've been unhappy with excessive back-and-forth, non-responsiveness on the part of the responsible parties, and generally extremely long durations between "we are completely down" and "everything would be fine had you not hacked around our incompetence three days ago".

Maybe this is a "grass is greener" sort of thing but I can't imagine AWS is this unreliable. This is the third major GCP outage we've had this year, and last time (not even three weeks ago!) it was three hours long.

<comment><AUTHOR> > Every time we've gone to GCP support, we've been unhappy with excessive > back-and-forth

Exactly this! I love GCP (especially firebase functions), inspite of these service disruptions. But, I can't deal with GCP support. They are unbelievably incompetent and have no understanding of the problem or solution. I feel like paying for support only to waste my time - explaining my problem to them with no hope for a solution.

</comment></comment><comment><USER3> Yes, twitter is flooded with reports of it at the moment. Google Cloud has confirmed they are having a "service disruption" but have not updated their status page yet: [https://twitter.com/googlecloud/status/1247894272629551104](https://twitter.com/googlecloud/status/1247894272629551104)

All of our Firebase projects are missing from their console, deploys fail, auth fails, getting 404s for their libraries.

Seems intermittent at the moment. But spreading.

<comment><USER4> Yeah, my projects are also missing from the console and not working.

</comment></comment><comment><USER5> Yeah all my projects are down.

Really irritating that they never update the status pages automatically, or even in a timely manor. As if customers won't notice.

<comment><USER6> >Really irritating that they never update the status pages automatically, or even in a timely manor

In my experience any real status page that matters is irrelevant as soon as the powers that be become aware of it and it becomes sort of non technical and politicized. To some extent that seems almost inevitable depending on the organization.

I worked at one place where "The guy who runs the twitter account." ran a status page. Not that he knew how to do anything (The one time I know he wanted to change the page he couldn't figure out how to do it.), but he was the only one allowed to approve / make updates. But it didn't matter as he wasn't on call, nobody was quite sure who that person was from day to day. He or she was in some marketing department and their idea of a sense of urgency was "sometime this week ... maybe".

<comment><USER7> What you need is an external status page run by someone else who is monitoring. Not sure who pays for that though, maybe they can make money through ads. What you want to know is "is it down or just me?"

<comment><USER6> Mostly what happened at that large company is customers would call their sales guy, their sales guy would call me or someone who knows and we'd tell them ;)

A few customers could call me directly too, I didn't mind that, they were good folks.

It's not a good process, but it is what naturally happens.

</comment></comment></comment></comment><comment><USER8> There is a broad Google Cloud outage since appx. 9am CST. Their status page is green but someone from Google acknowledged the issue on Twitter. The GCP slack is also abuzz with users reporting issues across many many services.

<comment><USER9> The status page has been updated now with a new incident - [https://status.cloud.google.com/incident/zall/20005](https://status.cloud.google.com/incident/zall/20005)

</comment></comment><comment><USER10> What is "Google Cloud Components", sounds like something all the other products depend on. If that's the case, a lot of other products should be marked as down in their status page, other users have confirmed a lot of products are down. This is really irritating.

<comment><USER11> I think it's IAM; since IAM underpins nearly all of GCP's managed service offerings.

</comment></comment><comment><USER12> Days ago I was concerned about the recent outages of GCP.

[https://news.ycombinator.com/item?id=22707876](https://news.ycombinator.com/item?id=22707876)

This confirms my suspicions and my concerns still persist when choosing GCP

</comment><comment><USER13> They've updated their status page now: [https://status.cloud.google.com/incident/zall/20005](https://status.cloud.google.com/incident/zall/20005)

</comment><comment><USER14> I still can log into Kubernetes clusters and SSH into Compute Engine, but can't create instances.

The status page has been updated: [https://status.cloud.google.com/](https://status.cloud.google.com/)

</comment><comment><USER15> For ~40 minutes, it was also impossible to SSH into any Compute Engine instance that uses OS Login for authentication, but it seems to have been resolved in the last few minutes.

</comment><comment> _-___________-_ My Cloud SQL instances in London are still refusing connections, and my servers can't get OAuth tokens to use other Google services.

</comment><comment><USER16> Looks like this is having some knock-on effects, G Suite email deliverability is having issues now.

</comment><comment><USER17> Our Cloud SQL primary failed over too

GKE is working as normal in west-3c

</comment><comment><USER18> Firebase seems back up for us now.

</comment><comment><USER19> yes. and they are not reflecting this on their status page.

</comment><comment><USER20> My product makes lots of revenue at this time around in Asian countries, but the Firebase is down. Hope there be proper compensation for this!!!

<comment><USER21> Typically cloud provider SLA's will compensate what you paid them, not for lost revenue.</comment></comment>


Fitbit to Be Aquired by Google - <AUTHOR> https://investor.fitbit.com/press/press-releases/press-release-details/2019/Fitbit-to-Be-Acquired-by-Google/default.aspx <comment><USER2> Comments moved to [https://news.ycombinator.com/item?id=21418232](https://news.ycombinator.com/item?id=21418232).

</comment><comment><USER3> More commentary on [https://news.ycombinator.com/item?id=21418232](https://news.ycombinator.com/item?id=21418232) (mostly) and [https://news.ycombinator.com/item?id=21418271](https://news.ycombinator.com/item?id=21418271)</comment>


Gio: Portable, Immediate Mode GUI in Go - <AUTHOR> https://git.sr.ht/~eliasnaur/gio <comment><USER2> Gio looks really neat (from the demos), I will definitely try it out as I have been looking for a nice way to build desktop app for quite some time.

Other projects that I am considering to use: [https://github.com/wailsapp/wails](https://github.com/wailsapp/wails) (looks very decent and I would be happy to use Vue.js for a UI bit) and Flutter with desktop support ([https://github.com/google/flutter-desktop- embedding](https://github.com/google/flutter-desktop-embedding), in this case it's not directly using Go but you can bind them together).

If this would mean that I can just use Go for everything - that's great but the only concern for me I guess is just the availability of examples and widgets. I don't consider myself a good UI designer so relying on libraries is important :)

<comment><USER3> For Flutter desktop support consider [https://github.com/go-flutter- desktop/go-flutter](https://github.com/go-flutter-desktop/go-flutter) : imho it works better than the official Google lib actually to compile Flutter desktop guis

<comment><USER2> Looks fantastic, thanks!

</comment></comment></comment><comment><USER4> No screenshots for a GUI library?

<comment><USER5> Watch his Gophercon talks, around minutes 4-7 show what it's capable of. Screenshots simply show native interfaces, so it isn't some kind of skin that's readily apparent from screenshots. The more interesting action happens in the code and his philosophy towards multi-platform UI.

<comment><USER4> That's a lazy excuse, sorry :) The talk is not even linked in the readme.

Display me what this awesome philosophy is capable of. I understand that this is somebody's side project, but come on, grab my attention, since we have a sea of GUI libraries out there. He must have built something amazing in it, just throw it there. It took me quite a while to find the slide deck link in the readme and I only kept looking because I couldn't believe that I can't see this thing in action.

</comment></comment></comment><comment><USER6> Basically this is the UI FX used to build [https://scatter.im](https://scatter.im)

Best way to view a preview of it: [https://youtu.be/9D6eWP4peYM?t=113](https://youtu.be/9D6eWP4peYM?t=113)

</comment><comment><USER7> A GUI library with no screenshots, no widget gallery, and no (easily found) reference?

"Hosting Gio on Sourcehut is an experiment just as Gio itself is."

Yeah, nice experiment. Now maybe try GitHub?

<comment><USER8> Why further strenghten Microsoft's monopoly on developers? With several great alternatives available today, I say steer clear and as far away from Github as possible.

<comment><USER9> This M$ = bad trope is really tired and outdated and not representative of its value to devs.

By all means encourage different hosting platforms, but maybe in a tone more relevent to the current decade.

<comment><USER8> No. After the decades of sustained bad behavior, they do not get a pass so easily. Not for several more decades at least.

Also, please quit it with the $ instead of S trope, it's really immature.

<comment><USER9> So don't use the tone.

</comment></comment></comment></comment></comment><comment><USER8> Very badly chosen name. GIO is already GLib's filesystem abstraction API: [https://developer.gnome.org/gio/](https://developer.gnome.org/gio/)

<comment><USER10> Tons of programming projects has the name of an existing project. Go itself is an illustration of that fact.

</comment></comment><comment><USER11> Is it just me or do are there a lot of developers who don't believe in the saying "One picture is worth a 1000 words"? Is it a Linux thing, something peculiar to developers in the Github era?

If you go to a forum such a the Lazarus forums, any announced projects show pics on the forum itself, or on the websites linked.

It makes me long for the bad old day so of windows when showing pics of your project was all the rage and still is.

This is not just in relation to Gio, but I see so many GUI projects on Github with nary a picture in sight.

Do their developers want those intrigued to go to the effort of setting up a development environment (if that succeeds) only to find that the project is half-baked mush of an apple pie?

</comment><comment><USER12> Love the idea not a fan of the tough to google name. I had issues googling for it a couple of times to show people Gio.

<comment><USER7> How about "Gio golang UI library"?

What exactly is hard about that (or several similar variations) -- which give me a first page full of relevant results?

Does the term have to be "Gio" or bust?

<comment><USER12> Should I really be forced to memorize word soup to find what I am looking for though? Thats just absurd to me.

<comment><USER13> To me it is more absurd that you act as if it is impossible to search for what you are looking for using more than one word.

You aren't supposed to memorize a word soup. You are supposed to search for what you are looking for based on some hints you may remember - e.g. gio gui library for golang. Even duckduckgo which isn't always the best when it comes to searching vague stuff gives gio as the third result (google shows the gio repository as the first result).

<comment><USER12> I probably typed into Google several things, and I'm not sure if the filter bubble Google has around me was screwing it up, or not getting the right word soup. Sometimes it shows up, other times it does not. Maybe Gio is finally getting enough attention.

</comment></comment></comment></comment></comment><comment><AUTHOR> It appears to support Windows, MacOS, Linux, IOS, and Android. See also this youtube video from GopherCon 2019 on this ui library:

[https://www.youtube.com/watch?v=9D6eWP4peYM&t=636s](https://www.youtube.com/watch?v=9D6eWP4peYM&t=636s)

</comment><comment><USER14> No x11 support?

<comment><USER15> It IS being worked on but in the meantime, gio apps can be run on X using [https://github.com/Hjdskes/cage](https://github.com/Hjdskes/cage) (a very simple wayland compositor)

</comment></comment><comment><USER16> This looks really interesting to me but I'm a bit lost on how exactly it'd work in practise. Are there anymore docs somewhere?

<comment><USER5> His GopherCon talks are pretty gentle tutorials. In practice, looks like your program becomes responsible for quite a bit of scaffolding that UI coders take for granted these days, in exchange for multi-platform write-once. Kind of reminds me of GUI programming back in the 80's, where your program is responsible for managing every state refresh and screen update. It's efficient, but I've seen larger teams without sufficient discipline have a challenge coping with this style. For a lot of useful problem domains however, it's really tough to beat its time to market and efficiency. Lots of startups would probably love this.

<comment><USER17> At this point electron will beat something like this on a time to market front. I suspect this framework would work better for people who want to do real-time drawing but stick with go and not setup a bunch of OpenGL boilerplate.

</comment></comment></comment><comment><USER18> On Ubuntu 19.04 I get the error message "wayland: wl_display_connect failed". Can't run the hello program to see something.

<comment><USER19> Do you use X11? Only Wayland is supported AFAICS

<comment><USER13> Until they add X11 support that makes it pretty much useless for a desktop GUI (if you care about Linux anyway).

</comment></comment></comment><comment><USER20> That'll be fun to get Google results for. I suppose we can be glad they didnt go for Go + UI, you know, GUI.

</comment><comment><USER21> First time I hear about immediate mode GUI. Here's a previous HN coversartion about it: [https://news.ycombinator.com/item?id=19744513](https://news.ycombinator.com/item?id=19744513)

</comment><comment><USER21> Off topic but...

In the web world we have benchmarks for UI libraries. Is there anything similar for the native world?

I remember a couple of years ago there was the bunny mark benchmark for 2d game engines (OpenFL, Flash, Pixi, etc).

</comment><comment><USER21> Vector shapes and text can go a long way but what about rendering images, video, or even SVG for icons and such?

</comment><comment><USER22> I wanted to try this out right away, but stumbled over the fact that I don't know how to use "go get" with Sourcehut, or even if it's supported. Of course it's probably easy to find out, but a "getting started" section wouldn't hurt. The "installation" page only describes the installation of the dependencies...

<comment><USER23> go get has nothing to do with github. Why wouldn't it work? Just use it the usual way. The readme directs you to a hello world program:

[https://git.sr.ht/~eliasnaur/gio/tree/master/example/hello/h...](https://git.sr.ht/~eliasnaur/gio/tree/master/example/hello/hello.go)

<comment><USER22> Ok, after I noticed that the URL of the git repo is at the top of the page (somehow I managed to overlook it), I tried "go get git.sr.ht/~eliasnaur/gio", only to find out that wasn't correct, because the project uses a "vanity URL", so apparently I have to use "go get gioui.org/gio" or something like that. My point was that even if it's pretty straightforward for a reasonably experienced Go developer, it doesn't hurt to mention it...

</comment></comment></comment><comment><USER24> this looks great, exactly what I need. I'll go try it out and see if it lives up to the promise :)

I guess, though, that there aren't any widget libraries for it, yet? Anyone know different?</comment>


How an entrepreneur launched a mobile chat system with 18 million users - <AUTHOR> http://mixergy.com/mxit-herman-heunis/

<comment><USER2> In the words of Dave C. "Haters gonna hate, lovers gonna love"

</comment><comment><USER3> I was hoping that this was going to be a tech-talk about scalability given the title!

</comment><comment><USER4> You can't make up your own mind?

</comment><comment><USER5> Serious question: is Mixergy considered a worthwhile site? Haven't I seen it dissed on HN before?

<comment><USER6> If there was a Pulitzer for startup interviews, I'd expect Andrew Warner to be nominated.

<comment><USER7> What I find awesome is that Andrew is able to conduct and produce these videos from Argentina!

He used to live in Santa Monica, and while SoCal startup guys like me were sad when he and his wife moved last year to Buenos Aires, I love how modern technology lets him keep up the pace of interviews just fine from another continent.

<http://twitter.com/AndrewWarner> _Location[:] Buenos Aires, Argentina_</comment></comment></comment>


SpyGlass for iOS: Powerful Navigational Instrument - <AUTHOR> http://www.macobserver.com/tmo/review/spyglass_for_ios_powerful_navigational_instrument/ <comment><USER2> I have a question for anyone out there who understands the domain: in the pre- iPhone days, how much would you have paid for the separate instruments that this app simulates? I'd have to guess at least a few hundred bucks, right? It amazes me to think that they all can be replaced by a 3.99$ app (assuming it works as advertised and whatnot.)</comment>


77,000 Images of Tapestries and Italian Monuments Join the Open Content Program - <AUTHOR> http://blogs.getty.edu/iris/77000-images-of-tapestries-and-italian-monuments-join-open-content-program/

<comment><USER2> Outstanding!

Although, at first glance, the image-by-image mode of distribution seems obstructive to widespread dissemination (as is the case with similiar publications of the same kind and magnitude[0]), the generous licensing makes more than up for it.

Nothing seems to prevent the Internet Archive from providing additional backbone, possibly outlasting this web presence[1]. (Odd, archive.org has no separate category for images.)

The thought of a comprehensive, high-resolution, Gutenberg-esque archive for Images clean boggles and delights the mind (mine at least).

[0] The BBC's image and British Pathé's video archives come to mind. HN discussion about the last publication of this nature: [https://news.ycombinator.com/item?id=7604459](https://news.ycombinator.com/item?id=7604459)

[1] [http://www.getty.edu/about/opencontent.html](http://www.getty.edu/about/opencontent.html)

<comment><USER3> > Nothing seems to prevent the Internet Archive from providing additional > backbone, possibly outlasting this web presence[1]. (Odd, archive.org has no > separate category for images.)

Working on it. Already have the first collection before the additional images were added.

</comment></comment><comment><USER4> I suppose there isn't a .torrent for all of these images ? :<

<comment><USER2> Seeing as how they seem to be going out of their way to mention Open Content and public domain in one sentence, I would venture to guess that there's nothing standing in the way of compiling a torrent archive.

Redistribution is not adressed explicitly, though (as far as I can see).

</comment></comment><comment><USER5> why not just link to the archive?

<comment><USER3> Getty Archive Source Post: [http://blogs.getty.edu/iris/77000-images-of- tapestries-and-i...](http://blogs.getty.edu/iris/77000-images-of-tapestries- and-italian-monuments-join-open-content-program/)

<comment><AUTHOR> Thanks! We changed the post url.</comment></comment></comment>


Show HN: Workfromhomejobs.me - <AUTHOR> https://workfromhomejobs.me <comment><USER2> We've landed in remote job aggregator hell where remote jobs are being aggregated from remote job aggregators.

Relevant xkcd: [https://xkcd.com/927/](https://xkcd.com/927/)

<comment><USER3> Right, we need another monthly hiring thread - "Who is aggregating jobs?"</comment></comment>


The Trillion Dollar Question Facing Every Major American City - <AUTHOR> https://www.strongtowns.org/journal/2020/8/28/trillion-dollar-question <comment><USER3> The website (and article) makes a shrill but intriguing point - <USER2> municipal finance is a ponzi scheme. I was briefly exposed to it while working on a financing project through a commercial lender. I was astounded to learn that you can actually get the local city to issue bonds in _your_ favor to fund roads, utilities etc for your _private_ project. The bonds are against future hypothetical tax revenues from that very project but guaranteed by the city. It is borrowing from the future in every sense hypothetical and hypothecated ;) Fascinating.

At some point, those land improvements - the malls, the shopping centers or housing complexes empty out and stop paying taxes. Alternatively, increases in maintenance do not match increase in taxes. Perhaps that has never happened yet in most of the growing west/southwest/midwest. When that happens you will hit a death spiral like Detroit.

</comment><comment><USER4> It seems like every time they update their website it ends up on HN and everything the discussion is the same. Unless the website actually introduces new facts or plans I wish it'd stop popping up.

<comment><USER5> There's no hint of "cars are bad" in this article, so it's not the standard StrongTowns article that gets posted to HN.

<comment><USER6> Time to move to Japan i guess.

</comment></comment></comment><comment><USER7> There's obviously a much deeper message here but gee whiz building vs maintaining a city sure feels like it has some basic parallels & similar tensions to adding to vs working on software projects. The mandate for growth is real.

</comment><comment><USER8> This makes a lot of sense to me, and so do a lot of other things on that website. I'm intrigued.

I'm also trying to see if there's anything shady here. Is Haliburton lobbying for a big infrastructure repair contract or something?

<comment><USER9> Boundless cynicism won't help you improve things. If the things you read make sense and hold up to your critical analysis and are things you think should happen, try to make them happen. If it should happen that there are others who have a financial reason for wanting to make the things that you want to happen happen, that is not a bad thing, that is a reason for them to help make the things you want to have happen happen, which is good. As the scale of the problem increases, the odds that someone somewhere is trying to find a way to have a financial incentive to solve the problem approaches unity. That doesn't mean big problems shouldn't be solved, it means that people are trying to align their interests with the interests you want to succeed. Again, that's good, if you want to see the problems solved.

<comment><USER8> I don't think it's necessarily cynicism, just a healthy skepticism of my own critical thinking abilities.

Something can be intuitive and seemingly sound and have the real world practical effect of only lining someone's pockets without actually delivering the promised improvements. I think, within reason, it's a good thing to not implicitly trust your own reasoning, and I also think it's good to get an understanding of the motives of whoever is trying to persuade you to their way of thinking.</comment></comment></comment>


Ask HN: Informal Survey re. Facebook Privacy - <AUTHOR>

Last weekend, my friends and I coded up a prototype Facebook app that needed to know (1) the gender of your friends and (2) a school or company that they are or were a part of. Using the Graph API, I was only able to get that data for 33% of my friends.
IMHO, that seems rather low given that gender + company / school really isn't something most people care about keeping private (as opposed to, say, photos). My hypothesis is that because of privacy concerns over the recent Facebook changes, a lot more users are either removing or hiding that data from FB apps. However, I'm not really sure how valid that is because (1) my friends are not a representative sample and (2) I wasn't systematically looking for this data prior to FB's changes.
So question for the FB apps developers out there: Have you noticed any drop in the quality or quantity of information you could access post-Graph-API? I'm not trying to formally prove anything here -- just seeing whether or not I'm completely off base. <comment><USER2> how can i check someone friends when I am not invited</comment>


The Web Curriculum - <AUTHOR> http://www.tbray.org/ongoing/When/200x/2009/07/14/Web-Curriculum

<comment><USER2> Great article, but compiler theory is a huge omission. I can almost hear Yegge screaming in the background.

<comment><USER3> How would you add compiler theory into the web curriculum? He includes parsing ECMAScript, so build a toy byte code machine and compile your parsed Javascript to that?

</comment></comment><comment><USER4> Excellent article. I have bookmarked it and will try and do a self-study course on these lines.</comment>


Citus 7: Transactions, Framework Integration, and Postgres 10 - <AUTHOR> https://www.citusdata.com/blog/2017/09/07/citus-7-distributed-transactions-frameworks-and-pg10/ <comment><USER2> I love the idea of citus. An abstraction on top of sharding sounds amazing. The docs are clear. Their learning material is solid and actually gave me plenty of ideas.

I was really excited about citus... until I saw the price! Hosted citus is expensive. The estimator estimated thousands of dollars per month, splitting to just two small Db machines with limited ram and CPU.

For now, just spending all that money on a huge vertically scaled rds box with lots of ram and CPU made way more sense. Hopefully native Postgres eventually ties more parallel ability to take advantage of bigger and bigger rds boxes.

If we scaled past 1 big box, I'm guessing we would just do classical sharding instead.

<comment><USER3> I think a lot of projects would probably be OK with Citus Community: [https://www.citusdata.com/product/community](https://www.citusdata.com/product/community) (as long as you don't mind being unmanaged)

</comment></comment><comment><USER4> Anybody here had experience using Citus Community version? Is it hard to maintain? I was trying to use it on my multi-tenant project but don't really know the maintenance implications.

<comment><USER5> (quick additional note)

If you're looking to use Citus Community edition for your multi-tenant project, one thing to keep in mind is how you set up replication.

Citus comes with two replication methods: streaming and statement replication. The streaming replication method is more suitable for multi-tenant apps. In the Citus Community version (if you need replication), you will need to set this up yourself.

[https://www.postgresql.org/docs/current/static/warm- standby....](https://www.postgresql.org/docs/current/static/warm-standby.html)

</comment></comment><comment><USER6> I don't have an app big enough but to necessitate the product yet but I've been following Citus' progress for a long time and I'm always impressed. Today is no exception! Can't wait to have a reason to use it.

</comment><comment><USER7> Awesome :)

Just curious, are there TPC-C numbers for this yet?

<comment><USER8> We don't have TPC-C numbers. I did run some pgbench numbers and put together a little video comparing Citus to Postgres:

[https://s3.amazonaws.com/citus-conferences/postgresopen- keyn...](https://s3.amazonaws.com/citus-conferences/postgresopen-keynote- video.mp4)

(no audio)

</comment></comment><comment><USER9> Is there a proper overview/doc page on how distributed transactions are implemented in Citus?

</comment><comment><USER10> Congrats on the release!</comment>


Would you buy more music if there was a reward to do that? - <AUTHOR>

If so what kind of rewards. If not please state you answers.<p>Also you can vote on https://www.facebook.com/vusic.co <comment><USER3> No - I'm a subscriber to two streaming music services that usually have everything I'm looking for, and when they don't my next source is Youtube. If I find something I like and want to add to my collection, I buy it - <USER2> after I've been listening to it for a while. I buy a lot of music, but it's after I've figured out that I like it and want to have it with me - the music is reward enough.

<comment><AUTHOR> Do you use those services for music discovery or you stick to what you know already and only after you search for related artists?

<comment><USER3> I'm working on building a service for music discovery actually (<http://beathound.com>) - it's not a problem that's been solved yet. I use whatever I can get my hands on.</comment></comment></comment>


Oxidize 1K: A Remote Rust Conference - <AUTHOR> https://oxidizeconf.com/oxidize-1k/ <comment><USER2> Hey all, we just announced Oxidize 1K: A remote lightning conference for Embedded Rust.

Because the situation with COVID-19 is causing issues with conferences and events around the world, we wanted to provide a chance for folks to interact from home. Oxidize 1K isn't replacing the main Oxidize Conference, but we're trying out new things, just in case!

We've also opened our CFP[0] if you'd like to submit a talk, it'll be open until 8AM CET on Monday!

Happy to answer any questions :)

[0]: [https://cfp.oxidizeconf.com/events/oxidize-1k/](https://cfp.oxidizeconf.com/events/oxidize-1k/)</comment>