Readit News logoReadit News
saidajigumi commented on A hundred UK companies sign up for four-day week with no loss of pay   theguardian.com/business/... · Posted by u/nigerian1981
saidajigumi · 3 years ago
Having worked at a company that did a four-day week, I'll chime in that it was both amazing and eye opening. I say that as someone who had read Tom DeMarco's now-classic book Slack[1] long ago, after a lot of up-close and personal with the antipatterns described therein. Intellectually, I expected something(??) good but the reality was even more suprising. With a four-day work week, I was able to complete (solo!) a production website application upgrade (Rails 2.x to 4.5) in a very reasonable timeline, and less than I'd heard competent teams failing the same task elsewhere. This wasn't because of any "10x developer" nonsense - it was clearly because I had a /three-day weekend/ every week and came in on Monday clear headed and ready to HIT IT, BABY.

Let me be clear: I later realized that this project would have been a soul-draining death march at many other places I'd worked in my career. Exhausted just a few weeks in, with management hounding the team for schedule estimates that can't possibly exist because management failed to fund maintenance for years.[2] (There were actually rational reasons for this, in this case. tl;dr the project got renewed interest and investment due to a new business case.)

To those who lament on this topic about "devs (in country X) just aren't motivated these days" or whatever, let me suggest something. If you have poor clarity of purpose, poor giving-a-fsck about humans, or a number of other culture failings then yes, you may encounter problems. Your solution is still not to tie your knowledge workers to their desks. You need to fix the root causes of your underlying productivity debt, not pave over them with an overwork-butts-in-seats mentality which just makes things worse in the long run (<--- read DeMarco).

[1]: https://www.amazon.com/Slack-Getting-Burnout-Busywork-Effici...

[2]: Pro tip: "evergreen" ecosystems, especially young and rapidly changing ones like early-mid Ruby/Rails and a lot of current npm/JS-based stuff, often have a wickedly non-linear cost curve if/when maintenance and dependency updates fall off. Some of the most expensive I've encountered of this ilk is when /test infrastructure/ incurred a lot of past churn that wasn't tracked, but suddenly (cough) needs to be updated.

saidajigumi commented on RootMyTV is a user-friendly exploit for rooting/jailbreaking LG webOS smart TVs   github.com/RootMyTV/RootM... · Posted by u/thunderbong
anonymousab · 3 years ago
There were a few TV models a couple of years ago that would stop working after enough time without a network connection. When they reconnect, they're clearly going to download a new cache of ads and transmit their existing tracking data.

It's easy to assume that they'll eventually require an unabridged connection to their own servers for updates, and they will simply send all ad data through the same routes such that you can't block one without blocking the other.

This is too lucrative for manufacturers to pass up. The added complexity also ads more points of failure and drives faster industry-wide consumer upgrade cycles. This is not something that will be fixed in the market alone.

saidajigumi · 3 years ago
There were a few TV models a couple of years ago that would stop working after enough time without a network connection. When they reconnect, they're clearly going to download a new cache of ads and transmit their existing tracking data.

Not quite as bad as that, but since I took my Sony TV offline it regularly reboots itself (when "off") and sometimes needs a "hard" start via the physical power button as the remote on has become unresponsive. I strongly suspect that it's just badly coded, going mad trying to connect to resources that don't exist, filling logs, etc. then failing over.

I so want tracked advertising in all of its forms to be outlawed.

saidajigumi commented on Charging cars at home at night is not the way to go: study   news.stanford.edu/press/v... · Posted by u/hhs
alexb_ · 3 years ago
>We're doing it wrong, according to a new Stanford study

Wrong according to what metric? Cost? Raw efficiency? A lot of people are more than willing to give up efficiency so that they don't have to actually worry about finding a station during the day. To say that something is just outright "wrong" based on their personal preference of priorities comes off as unhelpful to me.

The solution is simple. Make electricity cheaper when it's more available, and people will use it. You don't need any complex "AI" like people in this thread are saying, you just use natural market forces and the problem fixes itself. Too much energy being used at night - price increases. It's not complicated, and it's what we're doing already. People don't need a Stanford study to convince them to get their energy for cheaper.

saidajigumi · 3 years ago
This is precisely what the linked article says. From the section "Charging Incentives":

“And it’s not just California and Western states. All states may need to rethink electricity pricing structures as their EV charging needs increase and their grid changes,” added Powell, who recently took a postdoctoral research position at ETH Zurich.

The article also includes other interesting and more nuanced policy details than just "change pricing structure", such as:

Another issue with electricity pricing design is charging commercial and industrial customers big fees based on their peak electricity use. This can disincentivize employers from installing chargers, especially once half or more of their employees have EVs. [...]

So yes, there are weird red herrings in this thread from people who want a technology first and a solution second (or never) and/or who don't understand design of incentive structures. But this work doesn't appear suffer from those problems.

saidajigumi commented on Supply chain attacks and backdoored dependencies   kerkour.com/supply-chain-... · Posted by u/sylvain_kerkour
swatcoder · 3 years ago
When I’m feeling the most cranky and pessimistic, I feel like we’re a long ways from escaping this vulnerability.

It seems to me that we hit an enormous growth phase in the last 10 years and invited upon ourselves an Eternal September of Bootcampers and other very green developers who can’t be trusted to do more than glue components together.

Convenient, centralized package managers make these folk way more effective at delivering products in the near term, but there are too few experienced leads around to point out the maintenance and security concerns that play out long-term when you’ve committed yourself to continuously folding in unreviewed code from 1000 unpaid contributors you never vetted and who know nothing about you.

After years of “screaming into the void” (as another commenter put it), I’ve accepted that this is reality and that there are reasons for it: it produces valuable work quickly, and remediates labor pressure by lowing the barrier to entry.

But I can’t shake that we’ve loaded ourselves on a train whose track runs right over a cliff and that the correction, if it happens before we fall off that cliff, will be very expensive and jarring.

saidajigumi · 3 years ago
To a large extent, I think this is the nigh-inevitable outcome of the corporate world's entire take on open source. Open source has been a hugely successful way of distributing code cost centers, which is how we got here. Yet as many have noted, there's no social or economic model for supporting that work much less paying down its tech debt. Beyond a few Major Frameworks with substantial corporate backing, it's pretty grim.

As an aside, I'm not about to blame folks who came up through bootcamps. I've known too many outstanding devs from those backgrounds, and it's clearly enabled many solid devs to enter the field who would otherwise have been excluded. (I've also met a lot of folks with CS degrees who could give fck all about critical code infrastructure concerns.)

Likewise, for decades we've been striving to build languages, platforms, and tools that support powerful abstraction and code reuse. Somewhat amazingly to me, we've realized some of those goals. So I think the problem also isn't devs working at "glue code" level – at some point we

must* work at higher abstractions to get useful work done. Reinventing the wheel (or $datastructure) gets old. Again, I'd return to noting that the foundations are rotten, and the age-old bugbear of complexity management has only gotten worse.

saidajigumi commented on Tell HN: Have just discovered that I can use any key as Ctrl on my keyboard\    · Posted by u/pfortuny
saidajigumi · 3 years ago
As a software rather than keyboard hack, I've been using and loving the following setup on macOS: * Remap Caps Lock to Ctrl * Then use Hammerspoon[1] to map Ctrl(hold) / Esc (momentary press)

This essentially puts both Ctrl and Esc in a comfortable position on the home row, probably my favorite "ergo hack" ever.

[1] http://www.hammerspoon.org/

saidajigumi commented on The PARA Method: A Universal System for Organizing Digital Information   fortelabs.co/blog/para/... · Posted by u/lorenzfx
jknecht · 3 years ago
A deadline is not the defining factor of a project; a clear definition of "done" is the defining factor. I have dozens of projects that have no specific deadline, but I know for sure when they will be done, because I will have achieved what I intended to do.
saidajigumi · 3 years ago
Agreed. Thiago's introductory PARA writings do seem to imply a strict deadline, but like the parent, I use a concrete definition of completion ("completability") as the defining characteristic of a project. If I can't do this, then it's a major red flag and there's some deeper problem and the thing either isn't a project (e.g. it's an "Area" - something you to want to maintain a standard on over time) or it's not well defined enough yet and there's prior work needed.

Case study: Frederico Vittici of MacStories recently wrote about revising his own system to eliminate deadline times from his system as unnecessary overhead that he'd picked up long ago. It was a case of an item from "someone else's system" which was adding stress for no benefit.

All organizational systems are really custom-fit jobs. Look at others' systems and understand the individual techniques and how they fit together. Then apply those to your situation. This is a bit like the advice to not just take someone's complicated dotfile setup (vim, shell, etc.) and add it to your own wholesale. Instead to learn and apply piece-by-piece, understanding that sometimes several pieces must "go in together" to make everything work as intended. (this also applies 100% to every single software team's process in my entire career, btw.)

saidajigumi commented on Ask HN: What bits of fundamental knowledge are productivity multipliers?    · Posted by u/stardustpie
edelans · 3 years ago
Amen. or as Peter Drucker puts it (he is dubbed as "the founder of modern management" on Wikipedia) :

"There is nothing so useless as doing efficiently that which should not be done at all."

https://en.wikipedia.org/wiki/Peter_Drucker

saidajigumi · 3 years ago
And likewise, this theme shows up in Tom DeMarco's classic book Slack, which contrasts "efficiency" (the rate at which an organization is moveing towards some goal) vs "effectiveness" (the ability of the organization to choose and steer towards better goals). An important theme of the book is that an organization running full-tilt (maximum "efficiency") intrinsically reduces/eliminates its needed human "slack" to reflect and iterate towards the correct goals. DeMarco also digs into into the many organizational and management anti-patterns, with supporting research, that harm both effectiveness and efficiency (and just plain human well being...)
saidajigumi commented on Canon sued for disabling scanner when printers run out of ink   bleepingcomputer.com/news... · Posted by u/LordAtlas
alerighi · 4 years ago
I stopped buying inkjet printers. They are a scam, the ink costs a fortune and they are built as cheap as they can, meaning that they will break and you have to throw them away because they are impossible to repair, they are slow and when you need them they don't work because they were not used for too much time.

After having 5 broken printers in the garage I said enough, that is a useless waste, and invested some money in a mid range laser printer (only b/w, but I don't need to print in color anyway) that doesn't give me any problem, and with a toner that costs 10$ on Amazon (not original, but who cares?) I print 2000 pages. That means that in 5 years that I own it I only changed it 2 times.

I really don't see a reason for inkjet printers to exist, I hope they will disappear from the market.

saidajigumi · 4 years ago
Inkjet printers are fine, so long as you don't need or buy the terrible low-end consumer offerings. As an occasional-use around the house printer, I agree they're absolutely terrible, even without the scammy behavior of virtually every manufacturer. Just inkjet head clogging alone is enough to put anyone off. Inexpensive laser printers have been cheaper, more reliable, and much faster for a decade or more. Pay a bit more these days and you get a nice color laser printer with duplex printing. It's worth noting that even low-end lasers aren't immune to scammy behavior. Manufacturers have pulled sleazy tricks like hard page counts for the toner cartridges, so that even if the cart is still good it won't print. At least in the past, there are often embarrassingly easy workarounds (e.g. a minute to Google, then another minute with a sharpie).

That said, once you get up into the (semi-)pro photo/art printers, they're fantastic for that application. i.e. very much not an office printer. The ink per ml in the bigger cart sizes is often one or more orders of magnitude cheaper. You still need to run them enough to keep the heads nice and clean, but they also usually have decent auto-cleaning support built in to help maintain the print head so long as it's getting used periodically.

saidajigumi commented on Data protection ‘shake-up’ takes aim at cookie pop-ups   bbc.co.uk/news/technology... · Posted by u/louthy
GhostVII · 4 years ago
I don't understand why cookie popups are a website feature rather than a browser feature. Wouldn't it make far more sense to just have the browser default to disabling cookies, and show a popup if the web page wants to use them? Then it would be simple to say "accept all cookies", or "always deny cookies" rather than having a new popup on each site.
saidajigumi · 4 years ago
Because the relevant legislation was crafted by those who fundamentally do not understand how the web (or computers) work. The relevant parts of the GDPR should always have described a protocol where the browser acts as an agent on behalf of the user to declare privacy intent.
saidajigumi commented on CSS is no longer a core skill   yousuckatcss.substack.com... · Posted by u/rriepe
brailsafe · 4 years ago
Can you have the skill to come up with a good design if you have no clue how to implement it or how someone else would?
saidajigumi · 4 years ago
Can you have the skill to come up with a good design if you have no clue how to implement it or how someone else would?

This is a straw-man. Real-world designers absolutely do have a sense of implementation constraints for their target platforms, yet are usually not deep implementation domain experts. Likewise, experienced UI devs often have a sense of design, but are often not going to draft and refine a whole-cloth new design. I’ve also met a rare unicorn or two: those magic individuals who are fully capable developers and designers.

Put another way: UI design and UI development are adjacent specialties. Visually, they’d be partially overlapping regions in a Venn diagram. A UI designer or a UI dev who somehow knows nothing of their peer discipline will be hamstrung. I’ve met devs who fit this bill, not by their own design, and they’re usually radically unhappy with their work until they manage to pivot to non-UI development.

u/saidajigumi

KarmaCake day5163August 17, 2012View Original