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

101–110 of 210 posts

Re: The Failed Commodification of Technical Work

#101

Post by Pet_Ant »

ebiester wrote: post #66
Pet_Ant wrote: post #48

Earlier quoted context omitted.

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

The Scrum guide does not capture the culture and ecosystem of scrum that has developed around it. It’s like Node without NPM.

That’s my point.

Keep the guide, ditch the ecosystem.

You don’t have to use Rails, Boost, Spring, or Scrum-XP-Rational-Waterfall. Sometimes back to the basics of the tool is needed, but don’t throw out the baby with the bath water.

Re: The Failed Commodification of Technical Work

#102

Post by TeMPOraL »

tonnydourado wrote: post #81
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.

Programming is 5% of painstaking work to break down a problem into hyper-detailed description that leaves no space for ambiguity (that's the "meta work"), and 95% of dealing with self-inflicted bullshit like build systems, package managers, platforms, service architectures, devops, devsecops, secdevops, and all the procedural nonsense necessary to give people paying us a modicum of control over delivery.

Re: The Failed Commodification of Technical Work

#103

Post by x86x87 »

epups wrote: post #84

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, happil…

Yes, yes. In case of OpenAI: not only clear action but all the research and the disciveries needed are planned at least a few years ahead. They know exactly when AGI is going to be here!!!

Re: The Failed Commodification of Technical Work

#104

Post by underlipton »

x86x87 wrote: post #94
underlipton wrote: post #61

Earlier quoted context omitted.

>There's still no better training for programming than the equivalent of master/journeyman/apprentice. This is inseparable from the fact that programming is still a domain dominated by white males from upper middle-class families (and immigrants from countries with functional, non-boondoggle professional training and/or demoscene). DEI as a rainbow-wash goes away when organic mentorship of black kids and young women…

I'm not following what your point is. Would there be a way to make everyone expendable faster is it wasn't just white entitled dudes?

>I'm not following what your point is.

I'm not sure how I could be clearer.

>Would there be a way to make everyone expendable faster is it wasn't just white entitled dudes?

You might want to check this for errors.

Re: The Failed Commodification of Technical Work

#105

Post by vegetablepotpie »

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…

You hit on the fundamental assumption of calling IT a factory, and why that’s invalid.

IT is not a factory, it builds factories.

I believe a lot of developer/management conflict stems from a lack of terms for what we call manager. A McDonald’s manager supervises employees to ensure they’re following a process that produces a product. Failure to adhere to the process is obvious, the process is assumed to be valid as a given, and failure to produce the outcome is obvious.

Whereas a programmer is employed to develop processes that a machine will follow. A manager over this employee may have a process for the programmer to follow, it may be obvious whether this programmer is following the process, but it is uncertain if the process is valid and will connect specific actions to prescribed outcomes and the outcomes themselves may be non-obvious.

But we call both people in these roles “managers”, despite them being very different.

Programmer, in this machines analogy, is a different type of manager. One that presides over machines, and not people. But these machines are turned loose on the world, left to their own devices and not watched over by the programmer.

Re: The Failed Commodification of Technical Work

#106

Post by TeMPOraL »

banku_brougham wrote: post #24
marcus_holmes wrote: post #22

I think every engineering manager has either worked for or interviewed with a company that believes this stuff. Software dev is still at the craftsman[0] level. It might move out of that, eventually. But not yet, and probably not in the next 20 years or so. We haven't solved some intrinsic problems around defining a problem completely, precisely and succinctly without having to write code[1]. And getting five enginee…

Chat always writes me something that includes perfecttly_suited_package_that_doesnt_exist(my_inputs)

Ironically, that's one of the common practices in programming - writing calls to nonexistent functions that you implement later.

Re: The Failed Commodification of Technical Work

#107

Post by pbourke »

> You can pay people to churn out bad self-help all day, but none of those are going to be worth a damn without allowing the human element to flourish. But you still need a factory which can print the things, and as clinical as a mass bookbinding operations sounds, I really believe that you're only going to get a beautiful binding when that factory is run by people who have the connection to the work necessary to exercise taste.

Operation, innovation and maintenance. Pick any 3.

Better if done by the same team or teams that are very close to each other.

Ideally, all done to varying degrees by each person on the team because that’s where inspiration for improvement comes from.

We can split the 3 functions up into 3 groups, with 3 sets of management hierarchy. Often the result is mediocre and the people are unhappy (especially those stuck on the maintenance team - thankless but crucial work, that).

We can try to make teams responsible for all 3 functions, but often hire managers who overfit on one of them (coincidentally the one that leads to better rewards next quarter). It’s hard to champion operational excellence, diligent maintenance and hammock time in a single culture.

No wonder it’s hard.

Re: The Failed Commodification of Technical Work

#109

Post by dustingetz »

borlanco wrote: post #96
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…

> Programming is still a craft, not engineering, or manufacturing. Programming can be engineering if you know how to do it. Engineering is, in a nutshell, a set of principles you learn and apply, and never deviate from , in work and life . Engineers always deliver the highest quality. Craftspersons do not know these engineering principles, or they disregard them. They invariably deliver faster than engineers, and the…

what are the engineering principles of software? does team A agree with team B what they are? is there alignment between academia and industry? Electrical engineering has Maxwells Laws and math. What is the math of software? Do teams A and B agree?

Re: The Failed Commodification of Technical Work

#110

Post by steveBK123 »

lr4444lr wrote: post #87
steveBK123 wrote: post #9

Earlier quoted context omitted.

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.

The hardest part is not implementing the specifications as described (maybe AI will do this soon, doubt).

The hardest part is taking various competing requests in plain English (often in their second language) from non-technical people, having an interactive conversation to tease out actual needs, and converting that into a specification (if even only in your head) to then implement.

When we have an AI that can understand French Quants, let me know.

Post reply on HN