Live data from Hacker News

The Failed Commodification of Technical Work

ludic.mataroa.blog

71–80 of 210 posts

Re: The Failed Commodification of Technical Work

#71
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…

[flagged]

Re: The Failed Commodification of Technical Work

#72
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…

[flagged]

Re: The Failed Commodification of Technical Work

#73

Earlier quoted context omitted.

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.

Oh so you say “I had a burger” and it estimates what kind of calories that would entail?

Re: The Failed Commodification of Technical Work

#74
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…

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 with the latter view.

Re: The Failed Commodification of Technical Work

#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 write the same set of instructions more than once, you're basically doing it wrong. So it's hard to know how long things will take, because you're always doing something new. You never do something more than once.

Re: The Failed Commodification of Technical Work

#76
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…

None of what you're saying is an absolute truth. It applies in many environments, and in many others there is definitely space for commodification and MBA-style management gimmicks. It all depends on scale, technical complexity & maturity of the product, centrality of the software in question to the core product, etc.

Re: The Failed Commodification of Technical Work

#77
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?

I'm not sure what the parent post meant exactly, but I do agree there is tons of grunt work -- I've seen big name SV companies where large parts of their work flow include parts like "and then just every hour you need to do something in a slow UI that can't be automated" to keep vital systems working. I would say that's really grunt work, and there are even persons in such companies where their only task is doing such grunt work. Truly I've been told by clients I work with they have entire double-digit sized teams where the members only responsibility is to reboot VMs that breach specific resource thresholds -- easily automated and even built into most hypervisors, but for whatever reason these tech giants opted for a human to do it -- the only semi-reasonable explanation I got from one client was that their infrastructure team got outsourced and they laid off the only people who knew how to use the automation tooling. It's a dumb reason for sure, but at least I can understand why they opted for the manual grunt work.

Similarly, keep in mind a lot of this grunt work is just to satisfy some reporting requirement from somewhere -- some person(s) in the company want to see at least X% of uptime or Y LOC every day, so you get people trying to write a lot of yak shaving code that basically does nothing except satisfy the metrics or ensure that uptime % always looks good (i.e., they don't fix the cause of the downtime entirely, they just get the endpoint that is checked to determine update working well enough so it reports to the monitoring system and they leave it at that)

Re: The Failed Commodification of Technical Work

#78

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…

The theory of identifying something as being shit and then removing it is a bad thing?

Re: The Failed Commodification of Technical Work

#79
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…

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.

Re: The Failed Commodification of Technical Work

#80

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.

How is it helpful to the entire team for everyone to pay attention if adding a feature is 3 or 12 points? It's the one thing that wastes so much money and time. In the end it's 3 points. Thank you everyone for wasting $5,000
Post reply on HN