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

51–60 of 210 posts

Re: The Failed Commodification of Technical Work

#51

Post by simonbarker87 »

Pet_Ant wrote: post #48
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…

> hating most of Scrum I'll just say that if you look at Scrum itself there is really nothing objectionable to it. https://scrumguides.org/scrum-guide.html It's the other shit people pack on top of calling it Scrum that usually sucks ass. I've found the best way to fight back against shitty-Scrum is not to fight it, but actually feign puritanical allegiance to the actual doctrine, it's much less repulsive. I makes yo…

Very true, after being told many times “that’s not what it says in the Scrum guide, we need to do it like …” by a Scrum Master and a PO I decided to read it. I was astounded to find that the guide says very little and they were just using it as a weapon to push their own controlling desires on to the team. All the devs read it and the next time they used that line we asked them what it actually does say, they just made stuff up, clearly they had never read it either.

Re: The Failed Commodification of Technical Work

#52

Post by lysecret »

zerbinxx wrote: post #50
lysecret wrote: post #27

Well written and enjoyable read. The image of a Burgermaster 5000 operated by a Highschool kid producing burgers is one that really gets stuck in your head. I am wondering to which degree something like this might or might not come true with the advent of AI driven coding. I have built a full swift app using Ai (not writing a single line of code) but it took a lot of coding knowledge to pull it off. I wonder if this…

What was the full app?

Calorie counting using ChatGPT API. Sadly, burns too much money to publish it but I have been using it consistently for a few months.

Re: The Failed Commodification of Technical Work

#53

Post by gavinhoward »

I'm building a software business.

My bet agrees with the author: I am betting that I can spend time and brainpower designing and implementing a good solution to a problem, and people will pay enough to support me and my wife.

You can't commoditize design, and that's where my work actually is. This is also why I'm not scared of AI taking my job.

Re: The Failed Commodification of Technical Work

#54

Post by dsr_ »

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.

All living languages are in some state of flux. That's how you can tell they are still alive.

Re: The Failed Commodification of Technical Work

#55

Post by smoe »

genghisjahn wrote: post #45
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…

Planing poker is the one ceremony that I find consistently helpful. Listening to different devs discuss why they think something is 13 points or 3 points is helpful to the whole team. You could change the names of all the parts of the meeting, but having the discussion about differing opinions on complexity is so helpful.

I do like the planning poker for the same reason. I just find that people use story points overly granular. E.g. when using Fibonacci series, what is the point spending time discussing the minute difference between 1,2 and 3 points.

What I have liked in the past, is just using small, medium, large or unactionable.

Or with the right team/managment, not using estimates at all, just have people pick up the tasks they feel confident that they can get done within a given time frame after having the discussion in the group about differing opinions on complexity.

Re: The Failed Commodification of Technical Work

#56

Post by pif »

dsr_ wrote: post #54
pif wrote: post #43

Earlier quoted context omitted.

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

All living languages are in some state of flux. That's how you can tell they are still alive.

I've not stated the opposite.

Re: The Failed Commodification of Technical Work

#57

Post by vsskanth »

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 bugfixes for what you license and can still retain control of your data and interfaces.

Re: The Failed Commodification of Technical Work

#58

Post by specialist »

artyom wrote: post #40
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-…

Respectfully disagree. Meaningful answers from raw data is hard, but the hardest part was always making business people to _ask the right question_. Take as an example a typical business question: "which countries are our users from?" But do they mean the country the user declared in the registration form? Or country they're currently accessing your service from? Or the one from their payment method? Or the one where…

> ask the right question

Exactly right.

As a UI developer, I guess I had always assumed having close contact with end users and domain experts. Nothing I could articulate. It's just how things were done.

Then I served in a QA Manager role for a while. Naive me started out focusing on the QC & Test parts.

Eventually I figured out most of the value add comes from the Quality Assurance parts. Formalizing some of the stuff I used to do intuitively, like requirements gathering, sure.

But I'd say (without proof) most value (impact) came from a) asking the right questions and b) verifying the team solved the problem they had set out to solve. In other words, formalizing the team's internal feedback loops.

Alas. That was late 1990s. The Agile Manifesto cult swept aside all that silly formalism. "Too heavy!"

We now have "business analysts" backfilling QC/Test, without any training or guideance. And I haven't seen any QA style requirements gathering, analysis, and verification in probably 20 years.

As if we can use A/B tests to achieve quality.

Re: The Failed Commodification of Technical Work

#59

Post by eterm »

smoe wrote: post #55
genghisjahn wrote: post #45

Earlier quoted context omitted.

Planing poker is the one ceremony that I find consistently helpful. Listening to different devs discuss why they think something is 13 points or 3 points is helpful to the whole team. You could change the names of all the parts of the meeting, but having the discussion about differing opinions on complexity is so helpful.

I do like the planning poker for the same reason. I just find that people use story points overly granular. E.g. when using Fibonacci series, what is the point spending time discussing the minute difference between 1,2 and 3 points. What I have liked in the past, is just using small, medium, large or unactionable. Or with the right team/managment, not using estimates at all, just have people pick up the tasks they fe…

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.

Re: The Failed Commodification of Technical Work

#60

Post by a3c9 »

The way I think about it is that as programmers we build the process for the kitchen. The software is designed around commodifying the repetitive work for non-programmer domain experts.

In my experience this was building a process for data scientists (math PhDs) to train and deploy ML models, and currently chemical engineers to build and deploy process simulations.

Data scientists and chemical engineers will have to excuse my comparing their work to flipping burgers :)

Post reply on HN