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).
[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.
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.
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.
> 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. [...]
Well, I don't know what to say aside from we would need a lot of work to have it 'both ways'.
By that I mean, if we expect everyone to charge their cars during the day, especially 'peak hours' in a given industrial area, there's a chance that the line and/or station capacity would have to be increased. A large part of the allure of 'night charging' is that it avoids requiring major grid upgrades, and also possibly opens up better uses around certain energy sources quirks. Nuclear, water power, geothermal, all three to some extent have 'consistent load' properties where either it takes time to adjust power output, or power output can be consistent both day and night with minimal incremental cost, vs the need to install additional capacity for extra day load.
> 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.
Speaking of incentive structures, one of my former employers installed EV chargers in all of the bottom floors of our parking garage while explicitly not allowing non-EVs to park in those spaces. I was left parking my hybrid on the roof in a desert climate where my car would continually get covered with pollen.
Naturally, I did what they were trying to incentivize: I looked at EVs. I quickly discovered that the cheaper models have limited usecases; for instance, the road trips I go on would now be out of the picture. The more expensive ones are much more functional but come at a high price that I've never personally spent on a car.
There's also the fact that I didn't have anywhere to charge it except public spaces where I'd have to awkwardly wait for hours because I lived in an apartment. In order to get a 240v plug in my garage I would need to pay for it myself.
These policies, as they invade the workforce, need to be looked at from a lens that doesn't end up doing harm in the end.
> Speaking of incentive structures, one of my former employers installed EV chargers in all of the bottom floors of our parking garage while explicitly not allowing non-EVs to park in those spaces.
Sounds like it worked out great for them — people who could afford living in single detached houses (generally the richer ones, and therefore generally the management) now get reserved parking out of the pollen. The people who are inconvenienced (i.e. you) weren't the people involved in the decision anyway.
Buy a small EV for everyday trips and rent another car for road trips. Nobody in our car culture, where people drive F150s just in case they need them; nobody is going to do that, but environmentally it'd be much preferable to everybody getting a big Tesla weighing several tons.
Financially it works out for a couple of road trips a year, not so much if you're doing it a couple of times a month.
Seems that commercial power costs less than residential. Sometimes the difference is negligible but other times it's significant. I know residential lines cost much more to maintain because of the distances but that doesn't apply to residential apartments buildings in cities and I believe there's a seperate charge for that.
I rent an office very near my house. The PG&E rate for peak time at the office is over 20c cheaper than at my house. Not very fair to residental usage.
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.
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.
I have it set as a "super" modifier, i.e. cmd + ctrl + option + shift, perfect as then you can use it as a modifier for shortcuts as no programs use that a default keyboard shortcut
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.)
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...)
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.
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.
The GDPR is already technology neutral. You're thinking of the cookie law, which is different (but often confused with the GDPR). Or perhaps you've been hoodwinked by people who are using annoying consent pop-ups to pretend to adhere to the GDPR (they don't).
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.
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.