I checked out the repo, but didn't have high hopes when there weren't any screenshots in the README.
But these look great! You should definitely show them off. Adding them to the repo for others to see might generate the tinest bit more excitement for people stumbling on the project. :)
This is actually how we started. I was using Firebase and hit some scale problems. We decided to migrate to Postgres, and I still needed the realtime functionality.
I started naively: just with triggers/NOTIFY. There were a few tedious things about this approach (creating a trigger for every table), and one major flaw: NOTIFY has an 8000 byte payload limit. So we were getting dropped notifications.
I looked into a few other ways to do it, but nothing fit 100%. So I built it, but of course with the help of other awesome opensource libraries.
Using the logical decoding is an amazing solution, mostly because you get message replay if there is an outage. More details in the repo: https://github.com/supabase/realtime
I wish he would have shown the heavy tree example in 11:55 without the library, seems cute and all but if you don't provide a comparison it's hard to take seriously.
Stripe looks great but after actually using it the performance is terrible - the api docs and the dashboard especially. Makes me wish they had gone with a css file 95% shorter and spent that effort on making the experience faster.
Do you think that companies like G are going to be able to hire literally anyone if they start advertising all the mess that they are working around?
Why would you write this article from an engineer's standpoint with arguments that will only benefit other engineer's but for some reason is directed at companies? Why not just call it "I'm upset with the dev experience" and be honest about your intentions?
If you don't present valid arguments to benefit the company don't title it like advice. I clicked the article expecting some more hopeful arguments than "hurr durr I got baited into doing things I don't like", but I see none.
To minimize human suffering you have to donate out all your earnings and be non-profit. I don't have anything against that, but those are irrelevant to this discussion.
I think there's someone who would accept working at each of those places just fine. Even the worst ones. Her point is probably more that if a company admitted their experience up front, people who thought that way was fine would accept jobs and those that hated the idea of that experience wouldn't. Sure, companies could lie, but then people would just quit as soon as possible if they really hated the experience. I'd work at any of those companies myself if the situation was right otherwise.
> I think there's someone who would accept working at each of those places just fine. Even the worst ones.
Yes, people desparate enough to subject themselves to poorer working conditions. What's the single benefit for companies to cut themselves off from potentially good employees?
Honesty? People are going to know what is up within the first month, at minimum, so don't waste their time?
This goes along with a broad category of attempted deception that fails because the person you're attempting to deceive has, typically as a part of their job, understanding the actual state of thing you're trying to lie about. Especially egregious when it creates a safety risk, for example, but bad enough when it simply wastes time. Good example: Lying to accountants about the contents of financial statements.
How many IT people do you know that have quit after a month because of poor conditions? And how many do you know that suck it up and just stick to complaining about their job?
Engineers don't want their time wasted, but companies have no benefit in trying to prevent it as far as I can see. What kind of brand image would they portray if they started saying how bad their tech stack is?
Well, every person I know who excels at their career can say "Wait, no, this was a bait and switch" and bow out gracefully in the first couple weeks and take one of their backup offers.
I've also worked for extremely corporate companies, and a lot of the saner people backed away slowly during the interview process, but some people took a week or two at the company to register "yes it's really that bad" and bail.
Well senior engineers won't work at entry level positions, but medium skill ones might. Replace skill with working conditions and it'll be the same thing, people that have a lower tolerancy for working conditions will leave quickly, but some will stay and that's still a win for the company. Especially compared to advertising how corporate and annoying their processes are.
but she says
> This way, if it sucks, people can see it as a warning and stay far away.
which implies she thinks companies should tell potential hires you won't like working here and should run away, which I doubt many companies will listen to that advice and think "sounds good".
That said what you said would be a good thing for companies who are afraid to tell what their dev experience is like to consider.
Companies don't have to tell you whether you'd like it or not, because they really can't know. However, they should describe the environment they provide.
I thought I had worked at some stupid companies over the years, but as a general rule all of them knew, at least in a broad overview, how the employees felt about the place. Often they even knew what things people disliked, but they didn't want to change these things or somehow found themselves incapable of changing them.
So again, I don't think relying on companies to tell you the things they know their employees don't like about them when they are trying to get you on board will be seen as a winning strategy.
If companies with decent process start doing this, and a company refuses to share their process, then everyone who listened to this is better off. Now of course, the companies with shitty process did not (and maybe should not) take this advice. However, the situation improved for everyone for whom it should.
I don't understand why this essay was written. It's an interesting train of thought until you actually compare savings it proposes with real world data.
The iMessage case is particularly horrid, the article states that 45 million images sent through the service daily produce an equivalent amount of CO2 as flying 11,000 people from Paris to New York. The images are uncompressed, but had only those anti-environment programmers somehow reduce their size by 50% without significantly degrading quality iMessage would only burn 5,500 worth of passengers in jet fuel daily!
Such a big save, until you compare it with the amount of total number of daily airline passengers, which is 13 million [1]. In comparison that's 0.04%, which wouldn't even make the tiniest scratch and you're proposing to degrade a service that's daily used by 1.3 billion people.
Taking the quote from the text: "The moment we create digital products or services we become part of the problem." it seems a huge stretch the intentions of which I can only speculate on.
The whole point seems incredibly stupid, but I'd really like to be proven wrong.
There are extraordinarily few actions that can be taken by just a small group of people that have more than a vanishing impact on carbon emissions. But that doesn't mean that these actions shouldn't be taken.
Unless you provide any numbers I think most people would rather enjoy life than think how many nanograms of CO2 they’re releasing when sending an email.
Yeah, maybe the email provider should think about how many tons their equipment causes. Shoving everything on the consumer is silly. Consumers almost never have the data to make informed choices.
FYI you can configure mouse wheel (or in my case just trackpad) scrolling in tmux [1], I've had this configured for years and it's worked really well for me.
Unfortunately, that breaks scrolling in VIM, which I also use. I do use scrolling with the track pad in VIM sometimes and I care more about that than scrolling in my terminal.
Maybe I should try re-enabling it again. It's been a while. Maybe tmux or VIM fixed this.
