saidajigumi

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.

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.

“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.

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.

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/

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.)

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.

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.

The XMLRPC Search endpoint remains disabled due to ongoing request volume. As of this update, there has been no reduction in inbound traffic to the endpoint from abusive IPs and we are unable to re-enable the endpoint, as it would immediately cause PyPI service to degrade again.

This is an ongoing attack on PyPi's search backends since around December 14 from the status logs. For context, this has entirely disabled 'pip search'.

[1] https://ballotpedia.org/Laws_governing_the_initiative_proces...

[1] https://www.anandtech.com/show/16226/apple-silicon-m1-a14-de...

Room-elephant number two: motive. The reported facts naively summarize as "oops, ex-employee blew up some stuff in prod, caused problems". <meme>But whyyyyy??</meme> There's no indication of specifics, and seeming denials of some obvious guesses: attempts at hacking (e.g. data exfiltration for profit, which are denied), ransomware, revenge, or anything else that would explain this behavior.

Further confounding everything is the bit where the new employer's response to these revelations is apparently "shrug".

To be honest, the worst regular example I encounter, in either direction, is Markdown source with no hard line breaks. Markdown fully supports them, and trying to read paragraphs in whatever-hundred character lines is a painful exercise. Such irony, since part of the beauty of Markdown is dual readability in both source and rendered forms.

Part of the challenge is/was the line of thinking "surely if we can solve Hard Problem X, we'll have intelligence!" This turned out to be entirely wrongheaded, since a vast litany of Hard Problems X turned out to have plain old algorithmic solutions.

[1] I keep hoping this shows up online somewhere. It was shot using a machine room as the set, where mid-century modern furniture had been brought in for guest and host!

[1] https://addons.mozilla.org/en-US/firefox/addon/zoom-tab-clos...

Apple, of all companies, is not a monolith. There are parts of the company who've been just killing it from a software perspective (Swift, SwiftUI, XCode preview for SwiftUI, etc.) Where they've had severe issues has effectively been quality management across the broader OS.

Also, I'll be very interested to watch what happens over the next couple of major release cycles. I think Apple got a major wake-up call with the shitstorm that was the iOS 13 / Catalina release cycle. I'm hoping that they'll be putting in place an outright culture shift to fix that long-term, vs. a one-off "Snow Leopard" tech debt paydown release.

This. Under society-wide crisis, it's madness that the economic impact is supposed to just stop at landlords, moneylenders, etc. There are instances where individual organizations are trying to do the right thing, but the only humane thing to do is spread the impact (and recovery measures) across everyone.

Put another way, there are a lot of tmux users who take advantage of it for its terminal pane management features on a local environment rather than the classic remote-session stability use case ala screen. In that light, some kinds of integration make a ton of sense.

These days, it vaguely annoys me that I can't just navigate between OS (macOS, here) windows by keyboard just as seamlessly. I haven't quite gotten around to solving the problem with Hammerspoon[3] yet.

[1]: https://github.com/christoomey/vim-tmux-navigator

[2a]: https://github.com/jwhitley/dotfiles/blob/master/.tmux.conf#...

[2b]: https://github.com/jwhitley/tilde-local/blob/master/local/bi...

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

Thus the challenge is separating market feedback reactions (aka fear and bidding robots) from real-world valuation adjustments (aka mere delayed demand vs. destruction of long-term value).

This struggle is very real to me. There's always the tension between the day job, Just Plain Life (tm), and various passion projects. Sometimes I have the energy to just push on all fronts, but I've learned that's a limited resource. Pacing that in a sustainable way took a long time to learn, and sometimes means that I just need to aggressively back-burner things before burnout hits.

Best wishes to the author for a good period of rest!

"The chances your DSL is going to be good is very low." – Nonsense? Yes, API design can be hard. But DSL design at the scale of embedded, ergonomic DSLs is most commonly exactly the same scale as API design. Moreover, there are plentiful examples to draw from these days, especially around builder-type APIs as illustrated in the article. We have quite a suite of well-established patterns to draw from, and they're just not that hard to apply well.

Notably, "language design" doesn't come into it. Almost all proper "language design" decisions for these kind of DSLs are made by the host language – that's why embedded DSLs are so appealing in the first place. There are exceptions when the "language" is really a language (e.g. embedding a Prolog in Haskell or whatever), but most of the DSL examples in the wild end up simply being nice ways to construct rich data structures for consumption/interpretation by some utility library.

[1] https://stratechery.com/

If modern advertising 1) did not vacuum up personal data in extremely invasive ways, 2) didn't distort the entire business models of the largest tech companies against the interests of the overwhelming majority of their users, and 3) wasn't a broad attack vector on that same user population (dark patterns, outright malware delivery, just plain terrible UX everywhere, etc.)... then there'd probably be very little complaint about advertising, relatively speaking.

Put another way: no one gripes about the existence of Craigslist. Thought experiment: what if the targeted advertising model was illegal, both enforceable and enforced with teeth. How much of what's detrimental about modern advertising would simply vanish, like a bad memory?

Clang is designed as an API from its inception, allowing it to be reused by source analysis tools, refactoring, IDEs (etc) as well as for code generation. GCC is built as a monolithic static compiler, which makes it extremely difficult to use as an API and integrate into other tools. Further, its historic design and current policy makes it difficult to decouple the front-end from the rest of the compiler.

via https://clang.llvm.org/comparison.html, with more points for/against each option at that page.

git filter-branch is perfect for this kind of wholesale revision. filter-branch is essential for tasks like: open-sourcing repos that need some kind of cleanup, massaging repos generated by a VCS migration tool, etc. For example, years ago I participated in the move of a large CVS repo to git; there was significant filter-branch post-processing required to create an acceptable baseline)