in the short run. In the long run, productivity gains benefit* all of us (in a functional market economy).
*material benefit. In terms of spirit and purpose, the older I get the more I think maybe the Amish are on to something. Work gives our lives purpose, and the closer the work is to our core needs, the better it feels. Labor saving so that most of us are just entertaining each other on social networks may lead to a worse society (but hey, our material needs are met!)
> Try to get as narrow as possible, even to implementation details.
I think this is a great way to tell if someone knows their craft but it could also select for people with 1) really good memory 2) really good bs. I have made lots of technical decisions that I stand by but I have a hard time remembering what I made for breakfast. I kind of have to have the code in front of me to remember those kinds of details.
Yeah definitely. I have terrible memory and would probably do badly at this even though I'm a very competent programmer (and modest!). And similarly I have interviewed some people who could talk the talk but literally couldn't write a for loop.
I think we also need to shift our vocabulary around "leetcode interviews" because there are two very different things that that word is used for, and I think one is fine and the other is not, but because we use the same word for both people end up talking past each other. Basically there is:
1. Fizzbuzz-level (and a little bit higher) programming problems where there's no real puzzle solving, it's just checking that you can literally code at all.
2. Hard puzzle-style algorithmic leetcode questions. The stuff on leetcode.com. For some reason like 80% of this is dynamic programming questions.
I think fizzbuzz level questions are fine and necessary (yeah I wouldn't have believed it either but there's no way I'm hiring someone who can't write a simple for loop).
At the other end hard leetcode questions are not very good - they are often so hard (in an interview context) that they just select for people who have seen them before (e.g. if you grind the top 100 leetcode.com questions), or have had a lot of recent practice (especially of dynamic programming, which is crazy because I've never used dynamic programming once in my life despite doing a very algorithm-heavy job for a few years).
Even worse they often are selected because the interviewer read the solution, thought "ah yes that solution looks easy" and then it makes them feel good about knowing the solution - they don't even realise how hard it actually is.
So, hard leet-code questions should be avoided, but that doesn't mean you should have no whiteboard coding questions.
If you've made technical decisions that carry some decision making that isn't obvious by reading the code for a small amount of time, that deserved a comment probably.
> If you were given the ratchet and then someone wanted to charge you every time you use it you would also be pissed.
People gotta eat. If someone's making valuable tools and giving them away, they still need to get paid somehow. If people aren't voluntarily tipping them enough, then something's gotta give.
There have been too many stories of open source developers basically burning themselves out for years, then it comes out that they're barely scraping by and can't take it anymore.
The problem then is that you're making a valuable tool and giving it away and then wandering around hat in hand. That's not going to work for anyone. Also, taking away things that you've already given people for free so that they have to pay you to get them back is not going to engender any goodwill.
Unfortunately, the minio devs seem to have fallen into the common trap: make a great OSS project that works and that everyone likes, give it away for free, not know how to make money from it, and then start making user-hostile moves that piss off your users to try to make them customers - and who, surprisingly, do not want to be customers now that you've pissed them off.
It starts to feel more like a protection racket. You've got some great features here, would be a shame if something happened to them. Oh no, your docker containers! Oh, that's a tragedy what happened there, but you know, accidents happen.
> The problem then is that you're making a valuable tool and giving it away and then wandering around hat in hand. That's not going to work for anyone.
That is textbook open source idealism: you give to the community, the community gives back. The problem is a lot of people are moochers, even very rich people who have money coming out of their ears.
> It starts to feel more like a protection racket. You've got some great features here, would be a shame if something happened to them. Oh no, your docker containers! Oh, that's a tragedy what happened there, but you know, accidents happen.
Come on, don't be so uncharitable. It's nothing like a protection racket, which is pure, planned exploitation. This is open source idealism coming into contact with capitalist reality.
I know this is anathema around here, but this is why I have always liked grant-funded open source work. Whether government or private, someone at a policy level decides that something is important, and pays for development, leading to a new public good.
The development cost is based on the complexity of the work. It doesn't require a royalty payment in order to deploy more copies or to run them at higher loads. The software already exists. Separately, normal economic decisions can be made around support of deployments, e.g. whether to use in-house labor, hire consultants, or subscribe to some service contract. Sometimes, but not always, the users are another grant-funded project.
This model isn't a lottery ticket for the developers, nor the capital class. But the developers get paid a good wage for the time they spend on a product. I've done it for the majority of the last 30 years, almost like being a conscientious objector to the VC marketing complex.
Unfortunately, there are societal forces working hard against open source public goods. I think regulatory-capture is turning the whole security space into a compliance moat for heavily capitalized players. And the higher education cost spiral keeps increasing the overhead for universities, where a lot of these open source developer jobs used to be found. These are overlapping, but I'd say not the same thing. The overhead in academia is more than just compliance burden.
And, the whole fad-chasing and hustle aspect of contemporary IT is an inflationary process, eroding the value of previously developed open source products. Over my career, it seems that production-ready code is getting an ever-shorter service life. More maintenance and redevelopment work is needed or else users abandon it for the Next Big Thing. It's been quite a ride for me, following the whole wave of GNU, MIT, BSD, Linux, Python, and scientific computing tools since the early 90s...
if people are giving away wrenches and not getting paid for that, they will quickly run out of wrenches, and they will learn. giving away something free does not inherently give them the right to charge for use of the wrench.
giving a wrench to someone where you charge based on usage should be something that is agreed upon up front, not at some point later, after a rug is pulled out from under the customer.
> giving a wrench to someone where you charge based on usage should be something that is agreed upon up front, not at some point later, after a rug is pulled out from under the customer.
You're mixing up non-capitalist kindness and reciprocity relations with market relations. They're different things. Downloading open source code doesn't make you anyone's "customer."
The thing that happens first with these "open-source gone closed stories" is the community (or one particularly big mooch) failed to reciprocate the developer's efforts or was otherwise undercutting them. Then the developer responded.
And of course, the predictable response from some parts of the community is "how dare you not let me mooch off your efforts forever. I am entitled!1! Protection racket! Rug pull!"
Conflating physical products and open source software doesn't usually make sense. The open source model is more like someone making a valuable tool for their own use and then agreeing to let other people copy the design and make their own version of it. Monetisation can come from various sources - you may be paid to make the tool in the first place or you may perform a job where that tool helps you (or whoever is paying you).
> People gotta eat. If someone's making valuable tools and giving them away, they still need to get paid somehow. If people aren't voluntarily tipping them enough, then something's gotta give.
No one is saying people can't charge for their work though.
That just looks like 'writer over-educated in grammar above and beyond fluency, to the point they know how to use semicolons properly'. AI writer detection is just a new manifestation of superstition's origins as spurious pattern matching.
Well, as a foreign English speaker I have to thank you for calling me over-educated in grammar above and beyond fluency in a language that is not my own. But aside from that I can tell you that those sentences are either written by AI, and in the minuscule possibility that they weren't, the author must have been intentionally writing to sound like AI for the sake of being post-ironic. The second I saw the first sentence I knew it was AI and came straight to the comments to look for the thread of someone complaining so I could pile on.
PS: For what it's worth, I still think the article was moderately interesting, even if lazily and poorly written by delegating the task to an AI.
reply