Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Failed Commodification of Technical Work

ludic.mataroa.blog

Post reply on HN
Print view View original

191–200 of 210 posts

Re: The Failed Commodification of Technical Work

#191

Post by skydhash »

JackMorgan wrote: post #163
manvillej wrote: post #154

I think the problem is that the outcomes of technical work is not equivalent to a product with a more static value. Simply put, software is not the same as a burger. Software development to me is a financial investment strategy. Some risky investments, some safe bonds, some good debt to invest, some bad credit card debt that will be cleared later. To me, these are the same as a risky overhaul of a critical system add…

I agree whole-heartedly! I am sometimes called upon to audit codebases for acquisitions. I've spent enough time in the strategic accounting world to realize that we almost have no concrete units of measurement to talk about software. Lines of code is as meaningful as the count of boards in a house. In a house, we can at least get total square feet, number of legally defined bedrooms and bathrooms, lot size, etc. In s…

A recent post was talking about software as an expression of an idea. If you take something simple like a text editor, which purpose is to edit text, you can go and express this simple idea however you like. The final result will be different according to the person/people who shaped it. And that is why you have things ranging from nano, vim,... to sublime and vs code. To go from an idea to a product, there are just too many variables in play, and most of them depends on people.

> I would love to see a standardized metric for accounting for assets and liabilities.

I'd say that is easy. Just compare what the business wants/needs to what is inside the codebase. The diff percentage is a nice basis for the above. But that would require a very detailed study of both the company processes and the codebase itself.

I think that's why most of us feel the need to build our own tool. Because the ideas represented by the software we are using are not what we would have come with. And thus, we're building extensions and plugins.

Re: The Failed Commodification of Technical Work

#192

Post by ludicity »

edent wrote: post #3

I think - and it's only a think - that the author has ignored that a large part of what used to be called technical work is now commodified. I remember when a mail merge literally meant printing out lots of address labels and then manually sticking them onto a letter & envelope. Word 2.0 (?) solved that problem for the 1990s and MailChimp has commodified it for the 21st century. Double-entry book-keeping was technica…

This is a fair critique, and I'm giving it some thought now. I'll need to stew on it a little bit. Maybe the fundamental issue is that many of these products are designed to, as one of the other commenters noted, appear to purchasers that don't work in the field as simply appliances one purchases and then the problem is solved.

The issue is that a lot of the stuff out there doesn't actually solve the problem - it just appears to because other people buy it, and then lie about the implementation being successful to get promoted. Things like mail merge -are- like kettles, they're solved problems, and the only way to solve them is to try things.

The broader issue is that my employer purchased Workday because they believed it's like a kettle, but it can't actually fix the fact that our org structure is so horrendous that it can't be modeled.

(Incidentally, this year is the first year that I've realized that a sufficiently bad org structure, in a large company, tech debt of a sort. You end up doing all sorts of crazy things just to work out who works for who, and what can this user see in this database, etc.)

Re: The Failed Commodification of Technical Work

#193

Post by ludicity »

simonbarker87 wrote: post #18

I agree that the full commodification of technical work is a bad idea and will, hopefully, continue to fail. However, having read the Phoenix Project twice and hating most of Scrum, I disagree that’s what the Phoenix Project is advocating for. My main takeaways from the PP are: 1. Have clear systems in place to carry out and manage your repeatable work, automate where possible 2. Minimise the time work is in progress…

I actually totally agree with all of this, and these are the positive takeaways from the Phoenix Project. It was actually a valuable read despite my ribbing re: prose. There are many things people do wrong with known work/repeatable steps that can't be rightfully laid at the feet of Phoenix Project-type thinking.

But the one that can is that I think it ignores is that I rarely do known work with repeatable steps, because I'm programming: whenever this happens, it's because we've made tactical errors in stakeholder management and now I don't have time to automate them - but it has been a long time since my last reading, so it is possible that I've forgotten some sections that make substantial concessions in this area.

A thoughtful, sensible reading definitely leads to your last paragraph even if the writers don't explicitly call it out, but I simply know for a fact that most of the managers I meet don't understand the difference between producing widgets and designing systems.

Re: The Failed Commodification of Technical Work

#194

Post by ludicity »

wxd2351 wrote: post #75

In the McDonalds analogy, developers are not the teenagers working at the machines, we're the engineers that designed the machines. In the McDonalds analogy, the computer is the teenager. Programming isn't work, it's meta work, you come up with a list of instructions once, and then the computer does the work 24/7 indefinitely. Meanwhile you go on to write another set of instructions for something else. If you ever wr…

Author here - nothing really to say other than that I think this is bang on the money, and I've used the word meta-work to describe it too (when done correctly).

However this doesn't mean this notion isn't possible absolute bollocks, as another commenter suggested, just that someone else will join me in embarrassment if I realize this is silly in a few years... which is better than being embarrassed alone!

Re: The Failed Commodification of Technical Work

#195

Post by ludicity »

kelseyfrog wrote: post #132
mattgreenrocks wrote: post #8

I think he’s right. The tech industry has been trying to commodify devs for a long time (COBOL, Java). But there’s a sort of essential quality that reasserts itself no matter what you abstract. Despite the seemingly simple requirements paired with high level frameworks, a lot of our software still doesn’t even work well. As the author notes. The only real fix is talented devs that care. You can make a career out of t…

Devs even try to commodify devs! I cannot count the number of times that developers have gotten outright giddy when an opportunity for self-commodification comes up usually under the guise of self-taylorization. > I would adore it if the doctors and nurses in my life didn't constantly lament the stream of indignities that their single-neuron administrators heap upon them with each new proprietary system. It's funny -…

Author here. I have some famous-ish (within medical circles) family members, and it's interesting. On one hand, they have a lot of leeway and status, and at least the hotshots in my family are clearly treated as the medical equivalent of professional athletes, with a real craftperson's mindset.

On the other hand, I was actually talking about the EMR systems, etc, which are repeatedly purchased at exorbitant prices by vendors that churn out nearly useless products, and insist the staff spend ages doing data entry. I have some pretty horrendous stories in this space, which is why it's my go-to example in most of my posts.

Re: The Failed Commodification of Technical Work

#196

Post by ludicity »

rawgabbit wrote: post #162

What the author failed to mention is that the software industry itself is also responsible for this state of affairs. I am talking about the consultants and the salesmen of enterprise software. In many cases, they convince CEOs that they simply need to sign a contract and all their problems will be solved. They don't care to explain the high rate of failure of software implementations or how much manpower is needed o…

Thank you for taking the time to write this. "CEOs think they are buying an appliance" sums it all up perfectly. I hold them accountable because they're paid so much that they should know better, but you're right that a lot of people try very hard to mislead them, and sometimes they're even incentivized to be misled. If you build in-house to suit your data models and workflow, there is a chance you won't ever get the thing deployed, then you look bad.

You can always sign up for Salesforce, and it might be bad, but it's running so you can hide the details of the badness from the board. This is why when I wrote another post on saving 500K for my company, the two-slide presentation I was asked to write went through a lead, a director, and a lower-level C-suite member before being allowed to reach the top of the pyramid.

Re: The Failed Commodification of Technical Work

#197

Post by ludicity »

082349872349872 wrote: post #148

Judging both by the office->cubicle->open plan progression, and by https://www.workatastartup.com/jobs/62929 there's been some degree of commodification. The low end of that salary range is less (inflation adjusted) than offers (that had options on top) which I was getting last century just out of school, and the high end is less than I was making as a "software engineer" with two years experience.

I can't remember if I saw this in Slack or Peopleware (either way, very evidence-light books), but they made the great point that there's basically no good data on open plans being better than offices. It's just that you can measure the cost of floor space and it makes manager lives easier. Programmers benefit from thinking, managers benefit from being able to ask people for updates on a whim and lowering costs in the short-term, and guess who decides on the seating arrangements?

I have some other hot takes on how, despite I believe Peopleware being a Bill Gates favourite and my executives drooling at the thought of being as wealthy as him, they don't actually read or do anything of the things he recommends when it doesn't result in an immediate superficial victory.

Re: The Failed Commodification of Technical Work

#198

Post by ludicity »

arthurofbabylon wrote: post #143

The key decisions of a manager entail when and where to collapse complexity into simplicity (and inversely expand a simple system into something more complex). So you can pick out a foolish manager by their unwillingness to work with complexity in areas core to their business/craft/discipline, and you can find bad ass collaborators by examining what sorts of complexity they're enthusiastic about. (Note: I'm using the…

I was already going to write that this is a beautifully written comment, and then the high praise at the end sealed the deal! Thank you! I must confess that I am still in the reactionary phase of having watched Simple Made Easy two years ago, and am relentlessly trying to remove complexity, but your comment made me think about whether I've gone too far the other way. Complexity is frustrating because it is frequently the result of bad choices (at least where I work), but the ability to handle it probably is a fair marker for excellence.

"Make it simpler" isn't an option sometimes, and I still instinctively flinch away from those instances.

Oh, and the description of "empathy" as really being the willingness to engage with a kind of complexity is a very beautiful parallel between the worlds of software engineering and being a decent human being. I really love that.

Re: The Failed Commodification of Technical Work

#199

Post by ludicity »

vsskanth wrote: post #57

There's an entire spectrum of options here from complete outsourcing (banks and gov) all the way to writing everything yourself (Google). I've lately found a middle ground that seems to work well - licensing source code or libraries instead of entire closed web solutions. It enables a small team of good engineers to be really productive and ship something to production rather quickly. You pay for maintenance and bugf…

I read something great to this effect recently, but I can't remember where. The gist of it is that adding people increases overhead, so the absolute smartest play is to keep the tiniest team physically possible and give them an absurd amount of leverage - which frequently takes the form of licensing the things that you really -can- commodify well.

The fundamentals of data engineering (https://www.oreilly.com/library/view/fundamentals-of-data/97...) is adamant on this. If you're a new data engineering team, just buy things that download the data you need, because fetching data from APIs is (usually) pretty simple to do with automated tooling. Then your team can focus on the part that we haven't nailed, like making sane models.

Re: The Failed Commodification of Technical Work

#200

Post by ludicity »

bane wrote: post #123

I get what this post is saying, and I feel it too, deep in my bones. But technical work, especially in software, is being commoditized. If you view commoditization as a process, the end point of it is "free" (as in beer). I've been in tech long enough to remember when you had to carve literally every line of code out of the firmament of the heavens to get anything done. Today the bulk of technical work is plumbing to…

I had a great chat with a reader yesterday, where I became very concerned that we aren't incentivizing young people (like myself!) to pick up the "carve code out of firmament" skills. We just rely on certain personality types getting into it, whereas we fling prestige and money at surgeons. Meanwhile, where I am, they'll only fling money at me if I memorize details about the Snowflake billing model and API - not very useful to society if we need to innovate!

You're right though. As someone near the top pointed out - some things actually do get commoditized, like mail merges. That actually works and is probably never going away. Maybe the real issue is that a lot of these products aren't innovative at all, have no shot at being the next mail merge, and our leaders largely don't understand how to tell the difference.

Post reply on HN