27 pointsby iancmceacherna day ago4 comments
  • proc0a day ago
    > Well, first you’d need every worker in the factory—I mean, the tech company—to be a predictable, consistent cog in that machine. Then you’d need to be able to measure their performance.

    That's part of the problem from what I've noticed. Engineers performance is not measured against the application of computer science as much as how much they add value to the business in the short term... since in the long term there is strong indication that good engineering always adds value (i.e. by reducing bugs, making software more performant, more reliable, etc).

    I have no sources but I think it's easy to see that bad software costs companies a ton of money and it also makes or breaks a lot of startups, and one symptom of this is how engineers get yearly reviews that are based on soft skills, how many other people you manage, or how good of a job you did communicating the project status and planning.

    It seems to me the business side of companies takes over the entire culture of the company and everyone needs to think in terms of customer needs and whatever makes profit... but ironically this may be leading to poor engineering practices that are hard for engineers to deal with because they have different kinds of priorities and a different kind of mindset.

    • xg1518 hours ago
      > That's part of the problem from what I've noticed. Engineers performance is not measured against the application of computer science as much as how much they add value to the business in the short term... since in the long term there is strong indication that good engineering always adds value (i.e. by reducing bugs, making software more performant, more reliable, etc).

      My suspicion is, this is because from a business perspective, improving the quality of software is only one way to secure revenue, out of several, with others potentially being cheaper.

      A business person might ask an engineer "so we have this technical debt that you request time to fix. What happens if we don't fix it?"

      The engineer might answer: "well, the software will perform worse"

      Business person: "...and?"

      Engineer: "This will make the experience worse for the end users."

      Business person: "...and?"

      Engineer: "They might leave?"

      Business person: "They can't leave, the software was purchased by their managers, not them. They have no agency about this."

      Engineer: "Ok, but they might complain to management and the company might not renew the contract...?"

      Business person: "Lol, the company just completed a 6 month, $500.000 data migration and rollout to integrate our software with their existing systems. Like hell they'd throw this away because a few case workers are unhappy."

      Engineer: "...oookay... but they might complain on social media and give our software a bad reputation?"

      Business person: "Yeah, I'll let Marketing handle that. Request denied!"

      • proc016 hours ago
        Sure, you're just outlining the details of why software companies are ok with bad software. There's nothing inherently wrong with that, but it does mean we get more bad software and bad user experiences as consumers.

        Everyone is free to build bad software, but I believe that it only happens because the true value of good software is really hard to measure (since it involves comparing against something you are not going to build).

    • re-thca day ago
      > It seems to me the business side of companies takes over the entire culture of the company and everyone needs to think in terms of customer needs and whatever makes profit

      Yet a lot of times engineers do help make profit, e.g. optimize the application or infrastructure often savings thousands to millions of $$$. It doesn't earn them a good pass at review though.

      • proc0a day ago
        Yes that would be a shame. I think usually those changes do get recognized but perhaps for the wrong reasons. While it's fine to recognize how much profit the business is making, the engineering role should be recognized for how well the system is implemented and working. It's a subtle but important difference. I have seen so many teams with talented engineers yet they produce brittle code that breaks all the time and is hard to develop, and I suspect it's because they're constantly thinking about how their changes will add business value instead of how well the system is being engineered (which should indirectly add that value anyway).
  • danjla day ago
    Developers are either forced to track their time, or their time is tracked for then by the company for a very practical, but stupid reason: taxes. There are R&D tax credits, at least in the US, that require a breakdown of developer time. There are consulting companies that spend their time preparing these reports for startups and larger companies. It's serious and stupid. At least in many cases, these reports are not used to micromanage, they exist to get free money.
  • stego-techa day ago
    Been feeling this for a while now; honestly, my passion for technology in general and how I can use it to improve the lives of others is what keeps me in the IT sector, because it sure as heck ain't business cycles or Agile/Scrum Zealotry.

    > And there is no such thing as long-term sustainable success without human ingenuity.

    This is what I try to get at when I say I'm a long-termer. Companies need people who stick around for decade after decade, who retain that historical knowledge and pass it on to others. Frustratingly, companies have chosen to throw those workers out in favor of consultants, MSPs, contractors, outsourcing, offshoring, and whatever else reduces costs and bumps their bonuses for the current quarter. He gets to that in literally the next paragraph:

    > How many times do we need to see margins and profits crater and management fire everyone before we realize that a flywheel spins for only so long before it needs to be refined or replaced?

    > Who can do that? The problem-solvers, the fixers, the innovators, the outside-the-boxers—and we can’t measure their output with charts and graphs, let alone monitor progress with AI and cameras or keystroke-monitoring software.

    Companies inevitably face a life-threatening event (LTE) at some point in their existence. In the tech world, it could be a cyberattack, or outdated and unsupported infrastructure, or a vendor acting in bad faith to acquire a competitive advantage or even acquire you rather than compete. However, companies can really only respond in one of two ways:

    1) If they kept institutional knowledge on hand, treated their workers with respect, retained top talent and rejected the MBA Cost Cutting Playbook, then they'll likely weather it just fine with moderate consequences. There will be pain, but they will overcome it and be in a better competitive position as a result.

    2) If they outsourced, offshored, and laid off their tenured staff, they run a much higher risk of failure. Fixing Problem A might cause cascading issues with Problems B and C, for instance, because nobody knew how those systems interacted. A vendor audit might blindside you because the person who knew why you had Product X installed was let go years back, and couldn't tell you to yank it when it wasn't needed anymore or the license changed. Companies that do survive often end up spending far more money hiring permanent local talent on short notice than they would have if they'd just kept a tenured employee happy in the first place.

    And what's the end goal of all of these short-sighted decisions?

    Not to improve the business, and not to improve the products. It's only to improve the bonus value to leadership, and reinforce this misguided (and disgusting) notion that humans are cogs to be micromanaged down to the second, machines meant for repeatable tasks, and thieves who are out to steal every penny you have given the opportunity, rather than the living, vibrant, unique creatures they are.

    And besides, this is already coming back to bite them in the ass by virtue of Goodhart's Law:

    > When a measure becomes a target, it ceases to be a good measure.

    The second you place a KPI on an "organic" task (that is, a task that isn't constantly repetitive based on specific instructions, a la assembly line work), it becomes something to be gamed by those out for themselves, and loathed by those who were already doing good work in the first place. That is the literal second your company begins bleeding its best, its brightest, and its most loyal.

  • anarticle21 hours ago
    Bad time to be big, good time to eat their lunch.

    I have found that companies are reacting to the fact that they are very sick, no less than three people I know work at companies suffering from deep meetingitis of 80% of the day taken up with calls/checkins/meetings because they don't know how to work remotely well. They cruft up all the free time that would be for deep knowledge work with metawork, checking in that the work is being done or the right work or xyz to avoid making a mistake. This creates both drag on doing things, but also makes employees who are eager to do things crazy.

    The core element, I think, is a large tranche of people who should not be remote workers are still remote workers, and should either leave or rto. I don't think everyone is built for remote, even after covid. I say this as a 15y remote worker. I don't say this because I don't believe remote work should exist, I just think many people don't have the skills to handle it in an effective way. Could even be that most companies don't have the right setup even today, in terms of communication/expectation/accountability. If your place works well, congrats, there are many that do not.