xeiotos

I’m a big fan of the idea of UBI, but I somewhat doubt we’ll ever get there. But I’m neither convinced we need to get there in the first place, or need robots to achieve it. Post-scarcity is a different beast than UBI. Still, both might be good “pyramids”.

I’m not an economist nor well-read on the subject, so I’ll have to be hand-wavy on the specifics. But one alternative at least is to “live with less” as is sometimes said. To change consumption and our way of life so radically we just need less of everything (labour, material, …).

I concur the analogy misses this reason for teaming up in large groups completely.

All our current advances are the direct result of working in large, communicating groups, which crucially need a way to transfer knowledge across generations. The YouTube channel “How to make everything” comes to mind, where the resources, processes, machinery… required make it tricky for something as mundane as a hairdryer to be built from scratch by a single person.

However, I also agree, to some extent, with the point the author is trying to make, even though the arguments and analogies are shaky.

I don’t believe the author is arguing the pyramids would ever have gotten built if everyone did whatever the hell they want. But I also don’t believe the pyramid builders were terribly happy.

In a world where we have solved (or have made significant progress to solving) big categories of problems, it might be worthwhile to consider what our “pyramids” are. Are you working on something life-altering? Some marvel which will stand for hundreds of years? Most people probably aren’t. I know I’m not.

So I find it easy to emphasize with the feeling that it’s more “healthy” to just make whatever the hell you want (be it as a programmer, or just as a human being). After all, a lot of innovation has been a direct result of people fucking around on their own. I’d enjoy a planet where potential Einsteins would not have to work two jobs to survive, in lieu of which they would have time to think, experiment, write, …

Maybe it comes down to: - Individual freedom is ideal to invent things (someone had to be Alexander) - Some pooling of humans is necessary to actually build said things

On browser/computer use: I wish I could try them. But since OpenAI is going down the Apple path of cherry-picking random features to block in the EEA, without much explanation or timeline as to when they will be available (or even why they are blocked in the first place), I am unsure if I will be able to in this lifetime.

Unsurprising for multiple reasons. Most organizations have other bottlenecks and limiting factors than “how fast can you develop”.

Regardless, if you’re a dev who is now 2x as productive in terms of work completed per day, and quality remains stable, why should this translate to 2x the output? Most people are paid by the hour and not for outcomes.

And yes, I am suggesting that if you complete in 4 hours that which took you 8 hours in 2019, that you should consider calling it a day.

I always wonder if we didn’t get democracy totally backwards. As a Belgian, how could I have let my voice be heard that this is:

- a waste of time and resources

- not what I want

It sure is galling that government appears to be mostly an ever-growing and ever-more-costing pile of legacy rules, regulations and institutions, which through sheer complexity can be navigated only by big corporations or the mega-rich, who can lobby the monstrosity into doing whatever they want.

And meanwhile I’m paying upwards of 60% effective tax to support it all.

Respectfully disagree. It shows that the interpretation of the solution to a coding challenge is highly subjective.

How I use coding challenges when hiring is by first forming my opinion about a given approach. Did this person try to stand out? Does he/she use novel constructs? Stick to what they know? Do they “practice what they preach” on their resume/first round? Etc.

After this, discuss with a colleague to reduce bias/subjectivity. Finally, invite the candidate to discuss the solution. Ask them to review (parts of) their own code as they would a colleague’s PR. This way, the assignment becomes a tool to start a conversation.