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

As a worker, you can exercise your voice... by getting another job. That is your vote.

The power of your vote is proportional to the value you bring.

A while back I threatened to quit because I had a team dynamic that was untenable. I made a management change mandatory.

I got a new boss. The old boss was later terminated.


No, this is called exit and it assume that monetary reasons are the only important thing in an economy. That is false, workers should be allowed to exercise their voice about bad management and change bad management. If you want to leave that is fine but thinking that every worker wants the same thing as you is extremely foolish.

Congrats as a single individual doing something, LMK when it amounts to real material change like obtaining a pension, or securing more PTO, or getting better health insurance.


You can also exercise your voice by... talking. That might mean trying to convince leadership, it might mean trying to coordinate a bunch of people who agree with you but don't want to act on their own, or, who knows, it might mean something else. But there are quite a lot of things you can do that are short of threatening to quit or simply leaving.

(And sometimes just leaving really is the best step!)


I would argue that’s an asymmetric game. If your boss’s boss or higher already dislikes your boss, then convincing leadership would be easy. But bad bosses don’t become the big bad boss by winning over their subordinates. They spend more time with their own boss than you do, your boss is likely going to have a better relationship with their own boss than you do, simply by proximity. Assuming they aren’t just a flat asshole of course.

A vote would in turn provide a mechanism to prevent such abuse. The boss works for the people not for their boss. Likewise the boss is no longer bound to the whims of their own boss. Their boss is the people below them. A group they will inevitably rejoin with new found appreciation for the troubles of management.


It just gets you in the bad books of the management for pointing out faults.

You are talking about what is.

Shimman is talking about what could be.

Responding to "hey, we could make our workplaces better by making it possible to elect our bosses rather than having them imposed on us as absolute dictators within the workplace" with "but you can already choose your boss—all you have to do is abandon all your coworkers, your salary, your routine, and likely your home and geographical region to go pick a different unaccountable absolute dictator" just shows that you aren't even having the same conversation that shimman is having.

And the worst part is you don't even seem to recognize it.

You got yourself into an extremely lucky position one time, and now that's made you think that's a viable solution for everyone who has problems with their bosses—and that anyone who thinks otherwise is just "not bringing value".

The only possible way to make our workplaces systemically better is by collective action. Unions. Workplace democracy. Stronger labor protections.

Everything else is just crab-bucket mentality.


>by getting another job.

Depends on the job market, sadly. No way in hell people are doing this unless they already have "fuck you money" or are truly the best in their field (which usually comes with "fuck you money"). Otherwise, people who can't t afford to take 6-12 months off a job can't really do that.


Dotenv is definitely something that should not exist.

Direnv is the right way to go if you want a tool for this. Otherwise dotenv's implementation in bash is essentially `set -a; source .env`. Look ma, no custom parser!

Seems really silly to have a library do what two lines of shell can reasonably accomplish.


Interestingly, using source would have the same "bug" as TFA mentions.

Though the obvious fix is to use single quotes in the .env file.


That's not what the agent suggested. The user asked for a fix, and I guess the AI blindly complied.


That shell snippet will expand shell variables in double-quote strings. And apparently the entire reason for this fork is to not do that.

Which is dumb. The canonical spec for .env should just be "whatever POSIX sh does."


Agree, not expanding is dumb.

One of the major benefits of a shell-based approach is your env vars could be generated from the output of a command.

Which can be trivially used to populate secrets from whatever your secret store of choice is.

Now we've also cleanly solved secret distribution for developers with one less dependency!


> If your goal is to take over the market quick, as many here would like, maintainability is a very low priority aspect of your code base.

It's low priority in the sense that people in charge tend not to value it.

That's different from saying it is not impactful, or wouldn't lead to a good business outcome, if the software were built better.

Software that needs to be babysat is an ongoing opportunity cost.


> The alternative is not to invite people who have no experience to build bridges or perform surgeries.

You state this so confidently, like every person who walks through the door to interview will be 100% honest about their level of experience.

Have you ever interviewed? Nobody _wants_ a software engineer on their team who is awful.

Sometimes they slip through the cracks for a variety of reasons.


Cold call job interviews are primarily for people early in their career to get established in the field. You don’t hire someone that way to lead the Golden Gate Bridge.

How do you think companies hire for key roles like CEOs?


It's not science, but also a lot of stuff that purports to be science is not. "Science" is subject to many of the same forces that politics is.

Using your personal experiences and the personal experiences of people you trust as an anchor is a good thing. It keeps you from falling for propaganda. Note that this DOES NOT mean studies conflicting with your personal experience are all wrong.

The tricky part here is understanding the limit of what your own experience can tell you.


> It's not science, but also a lot of stuff that purports to be science is not. "Science" is subject to many of the same forces that politics is.

I am glad that people are finally waking up to this.


> Moving quickly, even if you break things, has a clear advantage over being perfectionistic, waiting to get feedback, building things that are not needed.

The entire point of slowing down is so you don't do this. Understand the problem well first, so you don't waste time building something that was never viable in the first place.

The author isn't advocating for perfect. You have to understand the problem well enough to know what all of the critical assumptions are. Some assumptions will derail an entire project if you get them wrong. Others will be a minor inconvenience, at worst.

In software, having a solid handle on future architecture means you can speak to how unanticipated new features fit in. You know what parts you can skip for now, and have it not be a big deal.

I've started to wonder if many of the people obsessed with speed lack capability. If you can't build something well, you can try building something poor quickly. This certainly applies to my current employer.


Author here. This is the correct interpretation of what I was getting at.


I think the answer to your question is the simple and unfortunate one: groupthink.

So many businesses are pushing AI hard. People with varying levels of job (in)security want to be seen as "leading the charge" into a post-AI era.

LLMs can do some really impressive things, don't get me wrong. But I regularly find massive blunders in the code it produces.

And that actually makes sense if you understand how LLMs operate and the quality of software on GitHub.


I'm not a physicist but I've always seen physics as a bit hand-wavy myself.

Dark matter is a great example.

Our understanding of gravitation didn't cleanly apply at ultra-large scales so we had to add a massive fudge factor.

You can't "go faster" than the speed of light, but space in between things can expand faster than the speed of light.

It seems like things that are "settled" regularly get an "ope, but except for this special case..." treatment.


There is no handwaving involved. The layman explanations of these phenomena are not that good. The quantitative derivations that leads to those results are totally fine, but hard to follow without deep knowledge of the subject.

Physics education sometimes aligns with historical evolution of the theories, mostly because that builds intuition and because the mathematical founsations of the improved theories need to be taught first. That leads to the "but in this case..." moments, but you need to realize that what you get taught as a "fix" is practically always a careful evolution that also reproduces all predictions from the less complete earlier theory.


Squash merging PRs makes your commit log is far less useful.

The PR reviewer isn't the only person who will ever review your code, you know.


I felt similarly. But I'm also usually the only person Tim Pope'ing my commits.

If you police atomic feature branch PRs instead of atomic feature branch commits, though, things actually work out OK.

(By the way, the even more compelling next step to your argument is: pull requests aren't artifacts! I've worked on projects that have emigrated from GitHub, and was left with just the commit log)


Interesting idea but this seems woefully inadequate for password management.

The first thing that came to mind for me: how do you change a single site's password? The article doesn't say. It only mentions that changing the master password would require changing all passwords. That also seems like a complete non-starter.

There is an array of useful functionality that modern password managers provide, too: password sharing, saving select file content securely, password history, storage of security questions and answers, storing username (when you use something atypical for anonymity).

I can't help but feel like this idea is a dud. It's neat in an academic sense but it can't seriously compete with what already exists.


> To update the passwords without changing pwd, the user can set a ctr on the client and increment it to change the associated rwd for a specific account.

https://dl.acm.org/doi/epdf/10.1145/3412841.3442131


Good to know. That seems like it comes with its own set of issues.


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

Search: