Live data from Hacker News

Don't Be Frupid

selix.net

71–80 of 134 posts

Re: Don't Be Frupid

#71
post #31

Earlier quoted context omitted.

The meta rn are thin clients with ssh

I have switched to that for my personal machine too, and it's honestly pretty good. Still working out some kinks but overall I think it's a good idea. I am on an m3 air though, which is not necessarily a weak machine and can still hold it's own in no-network areas for light work.

my requirements is "any macbook with apple silicon (M1/2/3/4/etc) with at least 16GB of RAM (and 256GB of ssd)". I'm still rocking an M1 16GB for my personal stuff since 2022. No complaints.

Re: Don't Be Frupid

#72

I feel like I could sum up this article as "give engineers everything they want, they're expensive!" TBH, I hate articles like this, not because I disagree with the general thesis, but because they present things in a way that is so one-sided that it is either ignorant or willfully blind to the other side of the equation. Yes, I wholeheartedly agree that cost cutting or being stingy with resources can be counterprodu…

[deleted]

Re: Don't Be Frupid

#73
post #49
post #3

> Conference Austerity > Conferences get nuked because someone upstairs sees them as a “nice to have.” The irony? That conference could’ve been where your engineers learned about a new technique that would’ve saved you a million bucks in infrastructure costs. Instead, they’re stuck reinventing the wheel – badly. I agree with the thesis in general but this point is not resonating strongly with me. Conferences are expe…

I agree that conferences like re:Invent are a waste of time and money on the HN crowd, who are anyway self-motivated continuous learner types. But the vast majority of large company payrolls are stacked with 9-5 types who clock in, clock out, go home to spend time on anything not related to their job. These types don't read HN, don't watch engineering YouTube, don't read r/programming, don't read Slashdot, etc. If a…

Having a healthy work life balance doesn't preclude self study. As a matter of fact, instead of losing a few family days for the privilege to clink with some tech bros, I rather prefer watching the recordings on fast forward past the useless banter and lame jokes until I get to the meat of the presentation - if any.

Re: Don't Be Frupid

#74
I used to work for a small consultancy which had a fantastic policy on this: there was a company credit card, and you could buy anything on it up to £100 with no advance approval - provided you made sure to send a reconciliation entry with a project code in before the end of the month, so it could be billed to the customer.

This was incredibly timesaving for all those cases where you need a cable or a USB stick or a book or some parts off Digikey or a small software license. Because having a meeting about whether or not something is necessary would easily have consumed more than £100 of time.

It helped that it was a small office of less than ten people and everyone could physically see everyone else's desk.

Re: Don't Be Frupid

#75
Another sure sign of this is custom internal tooling for things that are not business specific like time tracking and report generation.

A company I worked at had an IT budget of 5000 euro for 120 people (90% SWE). The logic was: if we buy a commercial solution for time tracking our IT budget will double. Instead super senior engineer Y is maintaining his "free" in-house solution with half the feature set.

All of these problems are about not taking the cost of expensive engineering time and energy into account in a rational way.

Re: Don't Be Frupid

#77

I feel like I could sum up this article as "give engineers everything they want, they're expensive!" TBH, I hate articles like this, not because I disagree with the general thesis, but because they present things in a way that is so one-sided that it is either ignorant or willfully blind to the other side of the equation. Yes, I wholeheartedly agree that cost cutting or being stingy with resources can be counterprodu…

I spent a lot of time making ends meet in tight development budgets, deciding what can and cannot be done within our limited means.

Cuts are sometimes absolutely necessary, but you must never let yourself get distracted by symbolism. And managers often fail at that.

Re: Don't Be Frupid

#78
Why do enterprises give developers shitty laptops? Why does it take a month to onbaord a new dev? Why does it take weeks to get a new dev tool installed that requires admin access? To get a firewall request reviewed? To get your team access to a fresh public cloud account for a new project?

The answer to all these questions is that things that are measurable will always be prioritised over things that are not easily measured. And the more mature the enterprise, the more the measurable has been squeezed to the detriment of the immeasurable.

IT hardware spend it very easily measured, but the time wasted and morale hit you get working on a shitty laptop is very hard to measure.

Anything that is measurable, you just turn a knob and announce 10% savings: well done you! enjoy your promotion -- the intangible negative externalities of your recklessness will rarely be considered or even known by the person whose job it is to review your performance.

Re: Don't Be Frupid

#79

Earlier quoted context omitted.

I have switched to that for my personal machine too, and it's honestly pretty good. Still working out some kinks but overall I think it's a good idea. I am on an m3 air though, which is not necessarily a weak machine and can still hold it's own in no-network areas for light work.

my requirements is "any macbook with apple silicon (M1/2/3/4/etc) with at least 16GB of RAM (and 256GB of ssd)". I'm still rocking an M1 16GB for my personal stuff since 2022. No complaints.

Do you often trim the fat so to speak with that amount of space on your work machine? I had a 1TB on the previous one, and ended up using more than half of that with just projects.

Re: Don't Be Frupid

#80
post #29

Was nodding along until "...consolidating databases into a single underpowered behemoth...". Nothing worse than race conditions and stale data between multiple disparate datastores. I'd rather have one database and more ram for as long as possible, tyvm. Some of the latest nights I've had debugging were at companies with mission critical data spread across multiple databases. I know it's orthogonal to the point, but…

This is basically the story of my career. It is very hard to argue for DB monoliths, and very common in a distributed microservice architecture for effectively doing joins across a network (with associated N+1 problems).
Post reply on HN