4 ms·
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, th
by wxd2351 3y ago
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.
- tonnydourado 3y ago> 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.
- TeMPOraL 3y agoProgramming 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.
- fwungy 3y agoIt's a series of simple tasks interrupted by two week diversions.
- SoftTalker 3y agoWow. This may explain why I don’t really like programming anymore. After doing it for years the solutions often seem immediately obvious. It’s the modern programming process (the “self-inflicted bullshit”) that sucks.
- vegetablepotpie 3y agoYou 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.
- didibus 3y agoI think this is great insight. It reflects why I often feel like I'm having to be the product and program manager as well. Even though I'm not, so often ideas on what could be improved, what could be done better, how to do things better can only come from the programmers, because the people whose title is manager are too removed from the actual management of the machines that are the ones executing the process that yields actual outcomes.
- ludicity 3y agoAuthor 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!