6 ms·

> At scale, even your bugs have users. First place I worked right out of college had a big training seminar for new hires. One day we were told the story of ho

• jacquesm 10mo ago
  For close to a decade my business revolved around a common bug in both Microsoft and Netscape, the dominant browsers of the day. With every release we were thinking 'this time they'll fix it' and that would have caused us some serious headaches. But they never did!
  • Donald 10mo ago
    I was curious what the commenter's business was, and found this post about HTTP protocol latency: https://jacquesmattheij.com/the-several-million-dollar-bug/ https://jacquesmattheij.com/the-several-million-dollar-bug/
    • Lammy 10mo ago
      What a cool guy https://jacquesmattheij.com/domains-for-sale/ https://jacquesmattheij.com/domains-for-sale/
      • usefulposter 10mo ago
        >FREEDRUPALWEBSITEHOSTING.COM Yeah that's not gonna work nowadays. >DOWNLOADWEBCAM.COM Is that like Download More RAM? >BROWSEHN.COM Hey, I'm browsing that place right now! >MUZICBRAINZ.COM This sounds 100% legit no virus softpedia guaranteed.
• hbs18 10mo ago
  So what is the correct solution to that specific problem then, adjust loading time per customer?
  • damethos 10mo ago
    Probably just let them vent until they adjust their habits and just chat with their co-workers, without the need to use this as an excuse. Then, they can enjoy the fast loading times :)
    • wahnfrieden 10mo ago
      Why would the boss accept that? They automated the work to eliminate employee downtime. If the employees were upset to lose their chatting time then presumably they lack the agency to choose chatting over work duties when they’re unblocked. The only way to help them in that situation is to organize them
      • Gigachad 10mo ago
        Because the 10 minutes of chatting has value too. Which is why corporations make you spend so much time on team building exercises and axe throwing.
        • rswail 10mo ago
          No, that's HR justifying its existence. Plus that's for higher stature service based roles, not warehouse logistics. It's also mostly bullshit. Teams work because they have the right combination of skills, both personal and technical, high EQ and IQ, leadership and ownership. Whether or not you fall backwards into a team's arms or have to participate in childish games is not relevant.
          • Gigachad 10mo ago
            For most people, liking and being friends with the people you work with is a huge factor in how much you like the job and are willing to stay. Most of the times I’ve left a job it’s been triggered by the people I liked talking to leaving and the remaining team members being dull and anti social.
• alex1138 10mo ago
  https://xkcd.com/1172/ https://xkcd.com/1172/
  • thelastgallon 10mo ago
    Hyrum's Law: https://www.hyrumslaw.com/ https://www.hyrumslaw.com/
• kyrra 10mo ago
  This was well talked about in Hyrums Law, which came from a Googler as well. https://www.hyrumslaw.com/ https://www.hyrumslaw.com/ > With a sufficient number of users of an API, it does not matter what you promise in the contract: all observable behaviors of your system will be depended on by somebody.
  • mjevans 10mo ago
    I believe it. I also believe an off the shelf example of how to use the library correctly will save everyone a lot of pain later.
    • shermantanktop 10mo ago
      I always strongly suggest sample code to people designing new APIs. Can be a very revealing exercise.
• TacticalCoder 10mo ago
  Craziest I got was users complaining their laptops were getting too hot / too noisey because I correctly parallelized a task and it became too efficient. They liked the speed but hated the fans going on at full speed and the CPU (and hence the whole laptop) getting really warn (talking circa 2010). So I had to artificially slow down processing a bit as to not make the fans go brrrrr and CPU go too hot.
  • matvore 10mo ago
    If the fan was turning on where it wasn't before, it seems like cooling was once happening through natural dissipation, but after your fix it needed fans to cool faster. So the fix saved time but burnt extra electricity (and the peacefulness of a quiet room.) This is pretty easy to understand IMO. About 70% of the time I hear machine's fans speed up I silently wish the processing would have just been slower. This is especially true for very short bursts of activity.
    • AlotOfReading 10mo ago
      Obviously the proper solution is to adjust your system thermal management / power targets, but you can force programs to slow down yourself by changing the scheduling policy: chrt -i 0 <cmd>
      • matvore 10mo ago
        > Obviously the proper solution is to adjust your system thermal management / power targets, My point is that I understand the users' complaint and request for a revert, not that I can't address this for my own machines. The proper solution for non-technical people is to ask the expert to fix it, which may include undoing the change if they were never interested in the process finishing faster anyway. I did solve this problem once upon a time by running the process in a cgroup with limited CPU, though I later rewrote my dwm config and lost the command, without caring enough to maintain the fix.
        • AlotOfReading 10mo ago
• johannes1234321 10mo ago
  That is https://xkcd.com/1172/ https://xkcd.com/1172/
• kqr 10mo ago
  Lehman talked about the developer-software-user triad. Each of the three have a different understanding of the problem to be solved. Developers misunderstand what the users want, and then aren't able to accurately implement their own misunderstanding either. Users, in turn, don't understand what the software is capable of, nor what developers can do. > Good intentions, hopes of correctness, wishful thinking, even managerial edict cannot change the semantics of the code as written or its effect when executed. Nor can they after the fact affect the relationship between the desires, needs, and requirements of users and the program […] implementation; nor between any of these and operational circumstances – the real world. https://entropicthoughts.com/laws-of-software-evolution https://entropicthoughts.com/laws-of-software-evolution
• embedding-shape 10mo ago
  > Your job isn’t to complete tickets that fulfill a list of asks from your product manager. Your job is to build software that solves users problems. Very important with this, is that not every work place sees your job as that, and you might get hired for the former while you believe it to be the latter. Navigating what is actually expected of you is probably good to try to figure out during the interview, or worst case scenario, on the first day as a new hire.
  • anymouse123456 10mo ago
    This is huge advice for people who want to climb a given career ladder. The overwhelming majority of organizations will say they want you focused on real user problems, but actually want you to make your boss (and their boss) look good. This usually looks more like clearing tasks from a list than creating new goals. At Google there are both kinds of teams.
• Aurornis 10mo ago
  > The load time improvements had destroyed their company culture. Instead of everyone coming into the office, turning on their computers, and spending the next 10min chatting and drinking coffee One of my early tasks as a junior engineer involved some automation work in a warehouse. It got assigned to me, the junior, because it involved a lot of time working in the warehouse instead of at a comfortable desk. I assumed I’d be welcomed and appreciated for helping make their work more efficient, but the reality was not that simple. The more efficient I made the technical part of the job, the more time they had to spend doing the manual labor part of the job to keep up. So the more I reduced cycle times, the less time they had to sit around and chat. Mind you, the original process was extremely slow and non-parallel so they had a lot of time to wait. The job was still very easy. I spent weeks doing it myself to test and optimize and to this day it’s the easiest manual labor job I’ve ever worked. Yet I as the anti-hero for ruining the good thing they had going.
  • wiether 10mo ago
    > So the more I reduced cycle times, the less time they had to sit around and chat. Couldn't help but imagining Darryl getting mad at you. Thanks for the story!
  • vkou 10mo ago
    > The more efficient I made the technical part of the job, the more time they had to spend doing the manual labor part of the job to keep up. So the more I reduced cycle times, the less time they had to sit around and chat. The faster the LLM spits out garbage code, the more time I get to spend reviewing slop and dealing with it gaslighting me, and the less time I get to spend on doing the parts of the job I actually enjoy.
  • vbezhenar 10mo ago
    One of my work involved automating some process which was very manual and tedious, took a lot of time and there was dedicated employee for that process. After I did the project, it turned out that this job wasn't necessary anymore and that employee was fired. I felt uneasy about the whole situation.
• devsda 10mo ago
  > Your job isn’t to complete tickets that fulfill a list of asks from your product manager. Your job is to build software that solves users problems. The main benefit of understanding the purpose and real world usage of your software is that you can ask the right questions while planning and implementing the software/feature/bug-fix and that you don't make any wrong assumptions. In a situation where you have conflicting requirements or concerns regarding the change, you'll eventually be hit with "PM knows the product & customer better" or the explicit "your job is to deliver what is asked".
• taklimakan 10mo ago
  Yes nice but also very naive. Most developers do not have that level of ownership, nor know how their users interact with the software. Their job is precisely to complete tickets from the product manager. The product manager is the one who should be in charge of UX research and “build a software that solves users problems.” Sure, in abstract that is the mission of the developers too, but in any structured (and hopefully functional) team, product strategy is not what the software engineer should be concerned with.
  • jaredsohn 10mo ago
    Good software engineers are concerned with product strategy. They might not be able to decide things but they can help inform product about options because they're closer to actually building things. If you just implement product tickets you'll probably get replaced by LLMs.
    • hyperadvanced 10mo ago
      It’s crazy how fast the tables turned on SWE being barely required to do anything to SWE being required to do everything. I quite like the 2026 culture of SWE but it’s so much more demanding and competitive than it was 5 or 10 years ago
    • jeanlou 10mo ago
      You need to be a product-minded engineer.
  • cm2012 10mo ago
    I have never seen a pure ticket based / zero ownership approach ever work.
    • mangamadaiyan 10mo ago
      Tell us you've never worked in a faang without telling us.
      • 10mo ago
• lukeschaefer 10mo ago
  Absolutely - one of my favorite bug with users was an application we had made in which the loading of a filtered view was so slow, that results would come in one-at-a-time, such that clicking 'select all' would only select those ones. When this was removed, users complained until we added shift-clicking to select groups of items
• SanjayMehta 10mo ago
  I optimised out some redundant processes on a unix system and sped up boot time. But I had to release dummy processes which just printed out the same logs, as management didn't want to retrain operators or reprint the documentation. Mid 90s. All training and operations manuals were hard copy.
• qmr 10mo ago
  Please stop abusing co-opting and denigrating the title of engineer.
• ehnto 10mo ago
  I worked on some software that provided results to some calculations to general web users, not experts. The calcs were done in miliseconds. We had to introduce an artificial delay of ~30 seconds to make it seem like it was taking a while to calculate, because users were complaining that it was too fast. They either didn't believe we really did the calcs, or they thought the system must have broken so they didn't trust the results.
  • astrange 10mo ago
    This is one reason UIs have animations added, the kind that technical users like to complain about or remove. By making things feel more physically grounded they prevent users from getting lost and confused and give them more intuition about things. In your case you could show more intermediate values, graph things, etc.
    • iosguyryan 10mo ago
      I often chuckle when (our) animations may have more complex math that consume more resources than the awaited logic/call that they gate.
• brunoborges 10mo ago
  > This makes it critically important that you, the software engineer, understand the purpose and real world usage of your software. Your job isn’t to complete tickets that fulfill a list of asks from your product manager. Your job is to build software that solves users problems. You actually described the job that Product Managers _should_ be doing: "understand the purpose and real world usage of your software".
  • lanstin 10mo ago
    As a developer of new things, if you allow someone else to capture this value from you, you become fungible; additionally, for your group, having technology designed to solve problems without grounded but expansive ideas of how much is possible, limits your team's ability to the mundane rather than the customer delighting. Some product folks have internalized the possibilities but some haven't.
    • woooooo 10mo ago
      Ideally its a mix, a good PM should understand the customer/market more than the developer has time to do, and then they can have conversations with devs about how to most effectively fill needs. In reality, these PMs seem more like unicorns rather than expected table stakes, but hey.
    • starluz 10mo ago
      [dead]
  • rswail 10mo ago
    Everyone in the team should have that. Obviously at different levels of focus and completeness, but the Product Manager is supposed to be communicating in both directions and they rarely do, they just take the feature list and tick them off. Telling the customer that they can't have something or it needs to be different and having their trust that you aren't doing it just to cut corners is what good Product Managers do.
• jeanlou 10mo ago
  I was told at university that every software system is a socio-technical system. Keeping a mental note of that fact has helped me throughout my career.
• WalterBright 10mo ago
  > The negative responses from clients were instant. Back when I was designing TTL circuits, the TTL specifications gave a min and max time for the delay between the inputs and the outputs. I was instructed to never rely on the min delay, as the chips kept getting faster and the older, slower replacement parts will not be available anymore. The IBM PC was frustrating to many hardware engineers, as too much software relied on timing loops and delays in the original design, which made it difficult to make the hardware go faster.
  • WalterBright 10mo ago
    On older cars, like my '72 Dodge, the system voltage varied between 12 and 18 volts. But the dash instruments needed 5 volts. This was achieved with a clever "buzzer" circuit using an electromagnet and contacts. The circuit would open when it was above 5 volts and close when it was below. This created 5V, but was a noisy 5V. Many people decided to improve this with a semiconductor voltage regulator, which would nail the output at 5V. But the instruments wouldn't work! The problem turned out to be the instruments relied on the noisy 5V to "unstick" the needles on the instruments. So the electronics guys had to add a "noise" circuit to the voltage regulator circuit. P.S. Watch an old aviation movie, where the pilot getting ready to fly would tap the instruments to unstick them.
  • mike_hearn 10mo ago
    Ah, the Turbo Button! I think by the time I got my first IBM PC the button no longer did anything, but it was still there on the case for some reason. I remember pushing it repeatedly, puzzled that nothing went faster.
    • WalterBright 10mo ago
      I have one in my car. It doesn't do anything, either.
• codingbbq 10mo ago
  Rightly said. I spent good amount of time cleaning up 15 year old codebase and removed almost 10MB of source code files which was being part of production build and it was never used. This helped reduce the build time. I thought I'd get appreciated from everyone in the team, but it was never acknowledged. In fact my PM was warried and raised an alarm for regression. Even though I was 100% confident that there would not be any regression, the QA and PM got annoyed that I touched a working software and they had to do extra work. I then posted on LinkedIn about this achievement to get my share of appreciation. :)
  • NamlchakKhandro 10mo ago
    LoL managers.
• Jean-Papoulos 10mo ago
  >Your job isn’t to complete tickets that fulfill a list of asks from your product manager. Your job is to build software that solves users problems. While I agree in spirit, when you reach a certain amount of people working on a project it's impossible. The product manager's job is to understand real user problems and communicate them efficiently to the engineering team so the engineering team can focus on engineering.
  • nightpool 10mo ago
    No. The product manager has to understand the big picture, but when you're working on a team that big, it follows that you're going to be working on a product big enough that no one person is going to be able to keep every single small detail in their mind at once either. You wouldn't expect the engineering manager to micromanage every single code decision—their job is to delegate effectively so that the right people are working on the right problems, and set up the right feedback loops so that engineers can feel the consequences of their decisions, good or bad. In the same way, you can't expect the product manager to be micromanaging every single aspect of the product experience—their job is to delegate effectively so that the right people are working on the most important problems, but there are going to be a million and one small product decisions that engineers are going to have to have the right tools to be able to make autonomously. Plus, you're never going to arrive at a good engineering design unless you understand the constraints for yourself intuitively—product development requires a collaborative back and forth with engineering, and if you silo product knowledge into a single role, then you lose the ability to push back constructively to make features simpler in places where it would be a win/win for both engineering and product. This is what OP means when they say that "The engineer who truly understands the problem often finds that the elegant solution is simpler than anyone expected".
  • kranke155 10mo ago
    If it’s impossible to understand users problems then something has gone horribly wrong.
• soleveloper 10mo ago
  This is a perfect example of a "bug" actually being a requirement. The travel industry faced a similar paradox known as the Labor Illusion: users didn't trust results that returned too quickly. Companies intentionally faked the "loading" phase because A/B tests showed that artificial latency increased conversion. The "inefficiency" was the only way to convince users the software was working hard. Millions of collective hours were spent staring at placebo progress bars until Google Flights finally leveraged their search-engine trust to shift the industry to instant results.
• rswail 10mo ago
  Worked on public transport ticketing (think rail gates and stuff) with contactless last 30 years, when guys would tell me that the software was "ready", I'd ask: > Is it "stand next to the gates at Central Station during peak time and everything works" ready? We were working on the project from a different city/country, but we managed to cycle our developers through the actual deployments so they got to see what they were building, made a hell of a difference to attitude and "polish". Plus they also got to learn "People travel on public transport to get somewhere, not to interact with the ticketing system." Meant that they understood the difference just 200ms can make to the passenger experience as well as the passenger management in the stations.
  • nickjj 10mo ago
    > "People travel on public transport to get somewhere, not to interact with the ticketing system." I really like this line because it applies to so many things we build. Public transport is an interesting one because it applies to so many things. If you need to use it but can't depend on it, it's a huge stress creator and time waster. Suddenly you need to pad times by hours to ensure you don't miss your appointment. Notice the words there, "miss appointment" and not "miss bus or train". The outcome is what matters, not the transport mechanism. Or, maybe you're traveling in a foreign country. Having every car in the metro display the line in a digital way showing the previous stops, current location and next stops in English is huge for eliminating doubt. Having the audio in multiple languages and clear is important too because maybe you're sitting down and everyone is standing in front of you so you can't see the display clearly. Having a non-digital map as a backup on the wall in case there's a hardware failure is a good idea too. Thinking "no one needs any of that waste because they can just use their phone" is the wrong mode of thinking. Maybe there's no service because you're underground or maybe that person's eSIM isn't hooked up yet or isn't working. These are real problems. The travel experience outcome in the grand scheme of things matters a lot. It could mean having a smooth trip or a questionable experience. It could be the difference between recommending the country to your friends and family or not. Suddenly it affects tourism rates at a global scale. Maybe not a lot, but it has an impact.
  • Foobar8568 10mo ago
    Thales?
• moinahmad 10mo ago
  This list really stands out because it treats engineering as more than just producing correct code. It focuses on producing clarity that others can build on. The idea that clarity matters more than cleverness isn’t about style. It’s about reducing risk when someone else has to fix or extend the code at an odd hour. That’s often the difference between technical efficiency and the contribution a team can reliably depend on.
• deleted 10mo ago
  [deleted]
• regular_trash 10mo ago
  Before I got into software development, I worked at a company doing technology-adjacent things. Nothing too fancy, but I got to improve a lot of things just by knowing a little powershell. One day, a senior developer there - a guy very fond of music - was showing me his process for converting a text file into SML. His process consisted of opening two notepads: one with an SML template block, and one with the text file to be converted. He then proceeded to convert each line into SML by copying the prefix tags and postfix tags and pasting them around each line. I wrote a powershell script in front of him to automatically do that and save an entire days worth of work, and he just stared at me. I had removed the one really mindless part of his job that he could use as an excuse to listen to a TON of music. Needless to say, he never used the script. Reflecting on this, I feel fortunate to have had this experience early on - it really helps put things into perspective - perceived improvements to anything depend entirely on the workflow of the people impacted.
  • kshacker 10mo ago
    1. I do that once in a while. There is only so much thinking you can do in a day or a week that you need some mindless activity 2. Today morning, fresh in the new year after a break -- I took a day off on the 2nd, and I last worked on December 19th, I am not able to get into the zone, and luckily a training email popped up -- spent an hour doing that. Normally my manager would have had to remind me.