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

81–90 of 210 posts

Re: The Failed Commodification of Technical Work

#81

Post by tonnydourado »

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…

> Programming isn't work, it's meta work

This is either profoundly insightful of absolute bollocks, but I don't think I'll be able to tell which before the next 5 years.

Re: The Failed Commodification of Technical Work

#82

Post by dsr_ »

throwaway9191aa wrote: post #62
eterm wrote: post #59

Earlier quoted context omitted.

There's more difference between 2 points and 3 points than between 5 points and 8. If you're looking to fill an arbitrary bucket, relative size matters most.

Our team had so many planning poker sessions where we spent 12 people * 2 dev hours trying to figure out whether stories were a 2 or a 3, management finally said it is always a 3. We were literally spending more aggregate time trying to decide effort, than the actual effort it took to complete these tasks. 2 and 3 are equal. 5 and 8 are equal. The question is simply "Is this a couple days, the whole week, or the whol…

The only reasonable estimates, ever:

+ That's trivial, it will be ready for testing before lunch.

+ I know how to do that, should be ready tomorrow/next day.

+ I can see how to do that but there are lots of other constraints - at least a week, might be more.

+ It's a big project, needs more planning and specification before it becomes a series of estimable tasks. Let's do that.

+ That breaks other things we care about. We need to prioritize and be ready for rework.

If you want, you can call these small, medium and large.

Re: The Failed Commodification of Technical Work

#83

Post by vegetablepotpie »

banku_brougham wrote: post #31

Consider the Business Intelligence/Analyst roles. The industry is trying to replace people who write SQL with people who can use Tableau or similar. "Just connect to whatever datastore you have and non technical people can drag and drop." Its got some problems: 1. They forget you need to hire many more (lower paid) people, because your output now linearly scales. Human hands have to turn the crank because its all UI-…

For business ”leaders”, #1 is a feature, not a bug. Linear scaling of output to costs is something that can be modeled in spreadsheets, can be passed on and billed to a customer. Everyone in a business hierarchy feels comfortable with those types of dynamics. Whereas having a dedicated specialist who can produce 1000x output with little effort, but is not entirely sure if that will take a day or a week makes everyone uncertain and puts leaders on edge. This is a hard sell if everyone wants comfortable mediocrity.

#2 ironically means more specialists, different specialists though, but more of them to maintain all the logic.

At the end of the day it will work out as being a jobs program and will end up being more expensive, but also distribute proportionate value to the politically influential fiefdoms, and that will make it successful.

Re: The Failed Commodification of Technical Work

#84

Post by epups »

I don't find this argument very compelling. Technical work has been commodified to a great extent, even in bleeding edge applications. Does anybody have any doubt that OpenAI has timetables with clear action items that need to happen so they can release their next model?

The counter-example of a software to abstract SQL queries is weird. This is exactly what we have been doing with other levels of abstraction, happily so. Why write Python instead of just using a compiled language? Because it's easier, and allows you to hire different types of people and focus on higher order problems. Maybe that's offensive if you are a world-class programmer like the author seems to think he is.

Re: The Failed Commodification of Technical Work

#85

Post by marcosdumay »

bryanrasmussen wrote: post #74
happymellon wrote: post #44

Earlier quoted context omitted.

All of those things have value if they are allowed to provide value. None provide value if management do not allow it to have value. > t-shirt sizes The whole point of planning poker is for people to guesstimate how much they think a task will take, and the poi t of doing it in a group is to allow the team to discuss the things they may not have thought about. > 2 hour sprint reviews I would agree that 2 hours is vas…

>The whole point of... there are many things that in theory have a particular point but that when put in practice most often do not have any point at all - in such cases opinion seems to divide between those who complain that the people who put things in practice do so incorrectly and those who feel that if the practice when implemented tends to be wrong then it is the fault of the theory itself. I personally hold wi…

About sprint reviews in particular (not retrospective), do have a point in theory? I have never found anybody that can point to any.

AFAIK, everybody that do it is cargo-culting.

Re: The Failed Commodification of Technical Work

#86

Post by TeMPOraL »

pif wrote: post #43
rswail wrote: post #38

Programming is still a craft, not engineering, or manufacturing. A software house should work like bespoke tailoring, or fine cabinetry, or glass blowing. There's still no better training for programming than the equivalent of master/journeyman/apprentice. Apologies for the gender specific terms, but they are specific to how tradespeople operated from medieval times. The worst thing to ever happen to the practice of…

> Apologies for the gender specific terms, It doesn't make any sense to apologize for using a language in its current form.

It comes out of an abundance of caution, necessary in these uncertain times.

Re: The Failed Commodification of Technical Work

#87

Post by lr4444lr »

steveBK123 wrote: post #9
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…

The problem is that beyond the boilerplate we aren't solving commodity problems most of the time. If you've worked in the same field long enough, you'll see that things certainly rhyme, but everyone has slightly different business requirements. At each level of the stack this grows, and so in total there's a ton of non-commodity, bespoke work to do. That's why no two products are exactly alike and we don't just have…

And that software purchasers demand changes. I would imagine we are not far from an AI being able to take over pure Waterfall development methodology.

But successful businesses aren't static, nor are their software needs. Once the AI decides on a data layer and you ask it to iterate on the code that interacts with it to meet new use cases and add features, god help you.

Re: The Failed Commodification of Technical Work

#88

Post by kuchenbecker »

danwee wrote: post #6
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…

What you say is true, but the amount of "grunt work" is not constant over the years. In fact, I think the amount of "grunt work" in teh tech industry is just growing and not shrinking; I think the following look is quite obvious: - amount of current grunt work: X - new tech Z appears that makes X be reduced to 0.1X - at the same time Z enables new ways of doing things. Some things become grunt work because they are a…

We are invening the problems of tomorrow by solving the problems of today, and people tend to be the constraint.

Managing complexity to where a fixed team can operate the software.

Re: The Failed Commodification of Technical Work

#89

Post by sgift »

tonnydourado wrote: post #79
happymellon wrote: post #44

Earlier quoted context omitted.

All of those things have value if they are allowed to provide value. None provide value if management do not allow it to have value. > t-shirt sizes The whole point of planning poker is for people to guesstimate how much they think a task will take, and the poi t of doing it in a group is to allow the team to discuss the things they may not have thought about. > 2 hour sprint reviews I would agree that 2 hours is vas…

I think you might be confusing sprint review with sprint retrospective? What you describe is the sprint retrospective, and when teams are autonomous enough to actually act on their pain points, it's easily the most useful scrum ceremony, IMHO. Sprint reviews are really kinda just a wankfest where people show nice graphs and demos for an audience that either already knows or doesn't care.

> it's easily the most useful scrum ceremony, IMHO.

Agreed. I would kill almost anything else from scrum (maybe weeklys can stay too. Sometimes they are useful), but sprint retros stay. And also agreed about the uselessness of sprint reviews. I've never been in one and thought later that I've learned anything or was useful to anyone in there. It's like going to church without being religious in villages. "The community would look with disgust at us if we weren't there on Sunday. So, we are there."

Re: The Failed Commodification of Technical Work

#90

Post by marcosdumay »

BurningFrog wrote: post #63
danwee wrote: post #6

Earlier quoted context omitted.

What you say is true, but the amount of "grunt work" is not constant over the years. In fact, I think the amount of "grunt work" in teh tech industry is just growing and not shrinking; I think the following look is quite obvious: - amount of current grunt work: X - new tech Z appears that makes X be reduced to 0.1X - at the same time Z enables new ways of doing things. Some things become grunt work because they are a…

> I think the amount of "grunt work" in the tech industry is just growing and not shrinking... Not sure, but isn't this just another way of saying that the tech industry keeps growing?

If it's the amount of grunt work to solve the same problem, it just means the ecosystem keeps getting worse.

What IMO, is quite obvious.

Post reply on HN