Hacker Newsnew | past | comments | ask | show | jobs | submit | more oreally's commentslogin

I'd like to present a different perspective, abeit slightly radical.

I believe that there's a place for a time-efficient, minimal human approval, risk-reward system for a society in which jobs have been gatekept to ever-higher requirements and are even harder to sustain due to pressures of the people gatekeeping you out and around you once you've gotten in (ie. the bureaucracies of your co-workers and your boss's temper tantrums).

If you've ever talked to creative-passion professionals(ie. media-content, artists), clients don't really respect them and abuse their passion, plus the people around them put a lot of pressure on them. In addition, polishing their work takes up a lot of time. So it's highly probable that they would be stuck in this loop if they didn't do something.

You could say 'oh, they can upskill themselves' or whatever. However that carries significant risk and still binds the individual to people's approvals and their hidden/overboard requirements. All the while, time and mental health is being sapped from them. I knew a programmer in gamedev who pivoted to robotics. It was all math heavy stuff and consumed him and his mental health to the point of his relationships suffering.

Point is skills-pivoting is hard to execute, and gets riskier by the day (think ai and jobs). However, say there's a system that is easy to execute, but the rewards are variant. But if that individual is able to figure out a plan to generate positive expectancy, that's a great alternative to the system of 'get a job and another job and hope you tick the requirements'. It's like a business in which you fail until you don't.

Of course, the keyword is being able to turn whatever you're doing into *positive expectancy*. Like a business with a new offering/venture, everything new looks like a gamble because you don't know the information, the theories and the outcome. Do you want really want to kill off these new businesses?


I think what you're saying is that society would benefit from a kind of lottery system that made it easy for people to earn a sizable amount of money randomly, without any sort of gatekeeping?

I agree with the premise, however, in actuality gambling systems are almost all designed to just extract money from people. Not function as a wealth redistribution system.


it's not really lottery, that system has to involve growing a 'skill' such that one could possibly get 'good' and 'rewarded' at it, and that 'skill' doesn't need human approval, which will make it a true alternative to getting jobs. bonus points if one can scale it up.

Take daytrading for example, of the 99% who fail are they all gamblers or are they just tolerating enough failures until they get a positive expectancy?

> however, in actuality gambling systems are almost all designed to just extract money from people. Not function as a wealth redistribution system.

Yea what I'm talking about isn't exactly a gambling system which will try to screw you over the instant you get some momentum of out a positive expectancy system.


Maybe playing sports is the closest?


Doesn’t the House very effectively gatekeep sharps from the table?


yea what i'm talking about excludes the house banning people from playing their game.


If stocks did not have positive expected return no one would invest. What you're talking about is daytrading where there's a large failure rate so much so people call it gambling because of the nature of how swingy and illogical it can be.

Besides that, there's also the perspective that options help stabilize the market via hedging.


Then why do people gamble? Negative expected return, they still do it.

I am also not sure what you are saying. The return on the average stock is negative, it is a empirical fact.


poor?

If I use RAII I'd need to have a struct/class and a destructor.

If I use defer I'd just need the keyword defer and the free() code. It's a lot more lean, efficient, understandable to write out.

And with regards to code-execution timing, defer frees me from such a burden compared to if-free.


> If I use defer I'd just need the keyword defer and the free() code.

Yeah, and not accidentally forgetting to call it. That's the big part. And before "True Scotsman will always free/close/defer!" - No, no they won't.

Unless the compiler screams at them, or its enforced via syntax constructs, it will always slip through the cracks.


Well I'd have to pay all the friction of writing up a new type, and in some cases the type gets cubersome. Doubly so if your codebase requires extra some friction like 1 header for each type.

Also get over it. We got post-processor things like static analyzers, etc, and whatever AI code reminders/fixers that are coming up next. I'd prefer those over muddying up the code base.


> Also get over it. We got post-processor things like static analyzers, etc, and whatever AI code reminders/fixers that are coming up next.

Sure. But unless it's part of compiler, someone will not run it, or will run out of resources (no net or no tokens).

Defaults matter a ton.


Ironically it's original use was in political* parlance.

From wiki it's "information sent out to the media in order to observe the reaction of an audience. It is used by companies sending out press releases to judge customer reaction, and by politicians who deliberately leak information on a policy change."

Yup I have no doubt that there's a Rust 'evangelist' group somewhere aiming for inorganic growth of the language.


> Yup I have no doubt that there's a Rust 'evangelist' group somewhere aiming for inorganic growth of the language.

So anything using Rust now must be the ‘evangelists’ work right?


Except now these software engineers have to code switch between languages.

Could you software engineers stop making things harder for yourselves and playing this meaningless flex of a status game, and you know, focus on something tangible, meaningful, instead of adding more bureaucracy?


I'm guessing you aren't a software engineer based on this comment, but the difference between programming languages is tangible and meaningful. It isn't like human languages where they're mostly basically the same and achieve the same thing.

And code switching between languages is not hard at all.


It's hilarious that you can assume such a thing just by a couple of words on the internet. Or maybe I'm not a 'software engineer' by your standards because unlike your closed group of SWEs I'm a lot less focused on resume padding and keeping my codebase sane and not exploding in complexity.

I should specify - it's hard in that it's troublesome to have to code switch and do a bunch of recall before working on the thing.

Say you've not worked on this secondary language for a long time, which absolutely happens, and have spend hours of effort to recall it. This takes time that you need not spend on, it's how your memory works.


I didn’t make the assumption but it sounded like a reasonable assumption based on the pronouns you used. You said “could you software engineers stop making things harder for yourselves.” A reasonable interpretation of this is that you aren’t a software engineer.

Reinforced softly by the rest of your comment not being technically sound. Adding a second language that is meaningfully different in its strengths and weaknesses isn’t “bureaucracy”. Bureaucracy is more like “sign a CLA before you can contribute”.


Okay then how about another interpretation: I'm a software engineer questioning the boarder group of SWEs on what they're trying. (Somehow I have to show you another interpretation I can't believe how tunneled people can be).

Also bureaucracy is added friction, usually done by humans. It can be found everywhere where you're working with humans, from leetcode interviews and code styles and practices. It's not just a bunch of signed papers.

Sure you can add the second language if adds value, but let's not pretend that the added friction isn't there. If you could solve your problems without the friction of second language it would be better.


> I should specify - it's hard in that it's troublesome to have to code switch and do a bunch of recall before working on the thing.

You don't sound like you have any experience working on software projects. I can tell you it's not hard to switch between programming languages. If anything, the difficulty level is placed on onboarding onto projects you are not familiar with, but the programming language in use is far from being a relevant factor if you already are familiar with it.


you're completely missing the point.

Even if it's 'not hard' your brain has to compensate for switching to another realm/space and that takes energy and time especially if you haven't used that particular space for a long time.

This is backed by science. Go read up on short-term working memory and crystallized memory.

All this will add up the maintenance costs, so it had better be a good trade off.


Dude you said "Could you software engineers stop..."

In normal English that means you aren't a software engineer.


printing should definitely be the tool of last resort.

No one can argue how many keystrokes and brain cycles it saves using a debugger vs going through the task printing every variable.


Being 'Multicultural' means keeping the peace between cultures. As much as the government loves to tout that they are a 'melting pot' where innovation happens, there isn't much going on there that is particularly attributed to being multicultural. Generally in companies you're either in the chinese culture or the western one.

I think it also speaks to the fact that without forced integration people will naturally converge to whatever is familiar to them, eventually forming enclaves.


But that is what's happening in Singapore.


Yea and that's why restrictions should be put in place, even at the cost of freedoms.


It starts when companies decide they have a right to time outside the employee's official hours and that they shouldn't have to properly reflect it in their employees' salaries, nor in their employment guarantees.

And furthermore, as an employee end of the day it's your right to have to be look out for yourself. You probably don't realize that because you're infected with startupitis where everyone has to be all in to succeed.


I do realize that employees have to look out for themselves (because companies, including startups, will usually take, take take from the employee, and then throw away the carcass, if they can).

However, employees work in a company with other people, so we'd like to know what we can and can't trust from each other.

If a colleague engages in criminal fraud, do they have a rigorous philosophy about when and when not to do that? How do they behave towards the team? Is defrauding the company OK, over something they think they company shouldn't demand anyway, but they will still be honest and responsible towards their teammates? That would be very good to know.

If so many people weren't so anxious to downvote things that don't suit their kneejerk reactions, we could discuss this.


A response to your comment could fill a book.

In short: it's complicated. Nobody minds about the technically "criminal fraud" when somebody brings home a couple dollars' worth of office supplies for private use. Everybody agrees that embezzling a million dollars should send you to jail. Meanwhile, something like grabbing a second lunch from the free company cafeteria and taking it home to eat as dinner will result in a lot of disagreement as to how bad that really is. But it also probably doesn't have a whole lot to do with whether you can trust that person's code reviews, because people are multifaceted and use different moral standards in different areas.

> so we'd like to know what we can and can't trust from each other.

Alas, we can't know. There are the things that are obviously fine, the things that are obviously not, and a GIGANTIC gray area in the middle which nobody is going to agree on, and companies will try to make policies that will always go too far in some parts and employees will always evade some of the policies they think are bad or unimportant.

And I think that when a company has a bad policy of overreaching in trying to claim ownership over things you do on your own time, and employees respond by falsely claiming that something they made predated their employment, that it's a fascinating example of that gray area.


> If a colleague engages in criminal fraud, do they have a rigorous philosophy about when and when not to do that? How do they behave towards the team? Is defrauding the company OK, over something they think they company shouldn't demand anyway, but they will still be honest and responsible towards their teammates? That would be very good to know.

I think the question you're really asking is whether or not they can be trusted down the line so that the system 'works'.

So here's the thing: You can never have a 100% guaranteed trust that someone is going to be doing as the company wills and wishes them to be, even if you have a written contract, and even if you shove a bunch of extra rules in it.

When it comes down to it, people will always have to look out for their best interests eventually, and having extra unneeded rules will push them to think transactionally, system and morals be damned. So the solution would be to treat them well enough to not have them think about it in the first place.


Yikes. I'm a fraudster now.

How do you feel about torrenting?


Classic case of:

New features: yes

Talking to users and fixing actual problems: lolno, I CBF


It's just the palate of the mass consumer who has such busy lives that they don't have the time to think about what other games can offer them.

And even if a "new and interesting concept" turns up, it's is too bothersome to learn for them. That's why once they find the fun in one thing, they tend to stick to it and be blind to others.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: