9rx

And this is the ultimate downfall of a suit. When jeans and t-shirts start to show wear then they transition from street clothes to work clothes and continue to live a useful life. As for suits, well, having a tie dangling around machinery isn't the best combo. Not even during peak suit did people wear them in the field.

Much more likely is that software engineering goes the way of the elevator operator. Advancements in technology saw the number of elevator operators explode, to the point that we've all become one!

Unfortunately for those wishing to make a living as an elevator operator, due to the properties of supply and demand, us all joining the ranks of elevator operator means that supply is effectively unlimited and thus price cratered to effectively zero. This is the real risk to software engineers, at least those who are in it for the money.

The cure for high prices is high prices.

Given what you said about Go, presumably that is Solod (https://solod.dev)

Actions speak louder than words.

Except in this case it's a gas station that only exists for the benefit of its owners and there isn't any food for sale. The owners have graciously said you could still use the microwave if you'd like, though.

Exactly. Representatives are merely messengers, so they can only represent the consumers when sharing the message of the consumers to the extent that the consumers have already recognized. Furthermore, representatives are only consumers themselves, so even if you imagine them not as representatives but dictators who step up and act for the people based on how they believe the people want to be overseen rather than from working with citizens they still have all the same blind spots.

> Great! Where can I find me one of those?

Where consumers don't like protecting the market incumbents. But, make no mistake, consumers love nothing more than protecting market incumbents. It gives them something to complain about when idly chatting with each other. Great? Something tells me you wouldn't find it great at all.

In a democracy, consumers and the government are the exact same thing. Since they ostensibly do not understand all of the potential ways in which they can be screwed over, how is calling themselves government going to magically change that? Maybe you are imagining a dictatorship instead, where the government is only a subset of all consumers, but even then the dictators are still just feeble consumers themselves remaining within the subset of all consumers. Being a dictator doesn't make you omniscient; still only human like all the others.

Government exists to clean up the outliers who are not behaving in line with the wishes of the consumers, but that cleanup can only occur when their undesirable behaviour is out there for all to plainly see. You cannot enforce what you don't recognize.

> consumers will have to choose between e.g privacy violation or environmental destruction, or privacy violation of some degree vs another degree.

Temporarily, perhaps, but in a functioning market one of those consumers feeling underserved will rise up to offer what's missing, eventually satisfying consumers again. However, ironically, consumers often consider that undesirable behaviour and use government to block that rising from occurring. For some reason consumers prefer to protect the market incumbents even when they claim to not like what the incumbents are doing.

Not really. No sign of a phone. Just a computer — same as what all other servers run on.

"My server runs on a computer with a form factor that is atypical for server workloads" gets a little closer to the heart of the article, but even then it seems the real meat of it is about Android, not the hardware (although that is mentioned too).

How about "My server runs on Android"?

Has coding ever meant anything else? This is just semantics, but I don't think a product person talking to customers to find out what they need has ever considered their work to be coding, even if the fruits of their discovery eventually ends up as code.

> Code was always the medium

Exactly. If you discovered that what the customer really needed was a wooden cabinet you'd build that instead. You wouldn't give them code and expect it to hold their belongings. Code has never entered the picture until you have something that is well-specified.

What is that supposed to mean? Yes, LLMs are often considered to be non-deterministic because, in practice, they rely on systems with unstable floating point rounding. Likewise, compilers are often considered non-deterministic because, in practice, they often rely on systems with unstable thread execution order. Of course, those are both just implementation details. You can, albeit at the cost of things like performance, remove the hidden inputs. Computers are fundamentally deterministic! Anything that runs on computers must also be deterministic.

If you were to run a compiler or LLM on a Turing machine, they would both be 100% perfectly deterministic. We only see them as being non-deterministic because, in the real world, we run them on hardware that plays tricks with computation by introducing inputs via hidden side channels. But, again, those are implementation details. Compilers and LLMs are not defined by any particular implementation.

- A product manager (PM) guides a product from its initial idea to its final launch and beyond. They define the product vision, set the strategic roadmap, and work with engineering, design, marketing, and sales teams to build features that meet customer needs and support business goals.

- A service manager oversees a company's service department, leading staff, handling complex client complaints, and ensuring efficient daily operations. They act as the main link between customers and the business, tracking performance goals and managing budgets to keep service standards high.

But, unfortunately, we can't use those definitions because both of them are about managing people. "They [...] work with engineering, design, marketing, and sales teams to", "leading staff". Exactly what you are trying to say this type of management isn't.

What other branch is there? You are either delegating or doing all the work yourself. Those who delegate become seen as managers, as that delegation requires managing the people (or, possibly things, depending on how you see that) that the work was delegated to. Those who receive the delegation and carry out their task individually are those considered to not be managers, but rather individual contributors.

> However, never would I say that when coding, I'm "managing the computer".

Why would you say anything while coding? I guess if you had some kind of voice-to-text system you might say something, but it wouldn't be "whee, I'm a manager now!!!!" — it'd be specific instructions directed at the computer so that it knows what task you are delegating to it.

> A compiler is a tool, not an unpredictable process I need to manage.

A compiler can be predictable if you perfectly describe the task you want it to carry out. However, that rarely happens in practice. Communicating your intent is always the hard part.

Which isn't much different than people. There are exceptions, but generally if you clearly define what you want them to do, they will execute it perfectly. Management of humans is all about coming back to make sure that what you described was correct and made sense to the receiving party. Which is the same thing you have to do with compilers.

I doubt anyone would, and that is why we even talked about the time when programmers weren't managers. Again, there really was a time in early computing where humans mechanically transcribed human-level descriptions into machine code. This is the origin of the term "coder". That was the job — encoding one representation into another. Unless you are trying to draw a distinction between programmers and coders? Most seem to consider them to be one and the same. But it wasn't long before we figured out how to make the computer the coder, so humans only had to worry about management of the coders.

> That, to me, is over-generalising what management is

The key difference in traditional use is that management is expected to manage people. As I mentioned before, I'd totally buy into you holding that same position. Except the idea of "everyone will be managers" hinges on the idea that they will manage computers, same as programmers have already been doing for decades. So that position doesn't work here. You cannot maintain that management is only management if it is people being managed, but then accept that in the future we will all be managers...

Straight up, there is no future where everyone will be managers of people. If everyone is the manager, what people would there be left to manage? It is impossible. Everyone becoming the manager is only possible if you include other things like computers. Which is fine, but we already manage computers. There is nothing new on that front. Computers were built to be managed. They are useless otherwise. Programming, for instance, is already always management (where you include computers as something able to be managed), even if there was a brief moment in time where it was more than that.

How so?

> Still, the bulk of the work is in the details.

The bulk of the work is in describing the details of what you want to see happen to another entity, which is what managers do. Someone else, or something else (like a compiler), will carry out the actual work to see your idea become a reality. Are you under the impression that managers don't do anything or something?

> We can play semantics on what it means to be a manager but the jobs as they were are going away

Are they? It is becoming easier to pass a lot more information off to the worker bees, so conceivably you should be able to do more management now, but the general act of describing what you want to the worker bees to do and seeing them carry out the task is no different. The telephone also increased the capacity of a manager being able to relay information, so while there is still evolution happening, what we're seeing in increasing the information density isn't unprecedented.

And, sure, maybe that will go away eventually. It is conceivable that AI can become the manager too, going off and coming up with its own ideas, plans, and delegating it all without any human intervention. But at that point you won't be a manager. Manager would be the very job on the chopping block.

If you want to say that managing a computer isn't managing I'd accept that stance in general, but the whole basis behind the idea of "everyone will become managers" is entirely premised on the idea of everyone managing computers, so that angle doesn't work within the context of this discussion. You cannot make that claim here.

So, what is this magical not-a-manager but also at risk of AI taking it away career? Are you sure it actually exists?

Does this stem from you believing that there is value in making logical errors, or is your angle more towards believing that nobody should waste their time interacting with someone who makes logical errors?

What alternative is there? Obviously very few of the ideas in the book were conceived of by Uncle Bob himself, but his editorial opinion is what chose which ideas to include. If that weren't the case, his name wouldn't be on the book.

That may seem out of place in the world you live in, but Go was created in a world where Python, Ruby, and Javascript were the languages all the cool kids were using. Go was intended to be the language for C++ programmers who had to use C++ for performance reasons but wished they could use Python instead.

Insanity, perhaps, but Go was designed to solve a problem for the world it lived in. You don't get to choose your circumstances. For those living in paradise, they can use the languages designed for their world.

The earlier quote might be slightly overblown as some of those complaints, suggestions, and feedback can be iterated on more quickly thanks to AI. However, I think you will find that the overall premise is sound: The feedback loop is where you will spend the vast majority of your time and no coding agent can speed that up. Code was never the real bottleneck. A full-day coding session now being a 15 minute coding session helps, every so slightly, but when you still need to spend weeks talking to the users to figure out what needs to be done in that day/15 minutes, shaving off a handful of hours relative to weeks remains but a drop in the bucket. The marginal improvement is barely worth recognizing.

The natural consequence of a "bullshit job" economy.

Especially within a company more powerful than the individuals. The project was done, at least feature-wise, but then Google set it free to become a community-driven project, which opened the freedom to do new things again: https://go.dev/blog/go2-here-we-come

I also learned that that said station is owned by the same company as a station in my hometown, which is as bland, boring, and repetitive as radio gets. Still has me wondering what that market has that my local market doesn't. Perhaps the true death of radio is hinged on urbanization coupled with limited channel space? Maybe a channel like that can survive there because the small overall audience doesn't invite someone else trying to encroach on the available frequency? Whereas, as you noticed, where frequency space is at a premium someone else with formulaic programming in hand will soon come to buy out anyone who tries anything interesting.

The most likely reason for why people are drawn to want to read about Rust for much the same reason. Note again that they are spending their time wanting to read about it, which is different than using it. Rust solved a real problem for a niche set of users. Now everyone who has problems with their existing technology stacks are trying to read all they can to try and convince themselves that Rust will also solve their problems. The heart lusts after Rust on the promise that it will solve all problems, but the mind knows it won't solve all problems. Attention lies at the intersection of those competing interests.

Rust is a big deal, but that isn't a big deal. MongoDB was also a big deal. Look at where it is at now. The good news for would-be language designers is that there is a strong signal in the market begging for a solution to their problems. The only question is whether you can deliver before the incumbents catch up (see: modern Postgres).