cjk

I found myself agreeing with much of this article, but I have to say, I used SpinRite to great effect maybe 20 years ago on a drive that had the “click of death”.

I tried all kinds of methods of recovery, and nothing worked until I tried SpinRite. I can’t speak to how it did what it did (who knows, maybe it was a total fluke), but it gave me the opportunity to scrape all of my data off of it before buying a replacement drive.

Finally. This merger ought to have been blocked from the get-go, but better late than never. Concert ticket prices and fees are completely out of control.

I really wish Flynn[1] had taken hold before Kubernetes became so popular. Deploying and managing apps was a hell of a lot less complex, and very Heroku-like.

Sadly, it's no longer being developed as of 3-4y ago.

[1]: https://github.com/flynn/flynn

I buy that maintaining a CI setup is not a trivial thing, but if speed is the only other concern, why not just...spin up faster CI runners?

De-centralizing test running also makes it difficult/impossible to e.g. collect test analytics (like Buildkite can do natively) to help gain insight into flaky tests, how code changes impact test duration, etc., and visualize those things over time, especially if developers are using non-homogenous hardware.

That, and if your tests are not being run in CI, then what enforces that tests run and pass before a deploy occurs? Losing that guarantee is not great IMO.

Call me a curmudgeon, but I am still not a fan of Tailwind.

I know a lot of newer engineers that believe it’s a perfectly acceptable alternative to learning CSS, to which I always respond: using Tailwind does not absolve you from having to learn CSS.

There are also a lot of comments in this thread claiming that the “right” way to use Tailwind is to create composite classes using its utility classes, but I have rarely seen anyone do this in practice.

Instead, the inline classes pollute the markup to the point of becoming extraordinarily difficult to read, and unless you make a concerted effort to e.g. bury as much of that garbage markup in reusable components as possible, it remains a persistent eyesore.

D'oh. I was searching for "Audrey". I guess it was silly of me to assume they'd use her English name in the article. Thanks.

I had to run the linked articles through a translator, but I didn't see any mention of Audrey Tang or claims that this was in any way an assassination attempt.

Ehhhhhh. I get the sentiment, but I think this really depends on what the "main" language is and how amenable it is to scripting.

Personally, I prefer writing shell scripts regardless of what the main language is in a given project. They're portable (more or less), and can e.g. detect missing dependencies and install them if necessary, which isn't possible with the main language if you're missing its compiler or interpreter.

This is a comically bad take.

Yeah, IMO, `go run` is a really under-appreciated part of what makes Go productive and low-friction.

That, and the ability to cross-compile without installing a cross-toolchain for the target platform. Having spent an inordinate amount of time writing build systems and compiling/distributing cross-toolchains, this is a _huge_ deal.

I only wish they’d realized it was time to start over before unleashing the cancer that is Electron upon the world.

I stopped reading when I saw the suggestion to avoid hiring people that are insecure. Some of the best software engineers I’ve ever hired lacked self-confidence and struggled with insecurity. In my experience, those folks tended to have extremely high standards for themselves, and did great work.

Conversely, some of the worst software engineers I’ve ever hired were extraordinarily adept at projecting a high level of confidence without appearing to be overconfident.

macOS has been doing memory compression for years. Basically, apps and background processes that are idle have their memory compressed, and then upon exiting idle (due to user interaction, a timer firing, etc.), the memory is decompressed. The compressed memory doesn’t touch swap.

It’s possible that Apple Silicon has some hardware acceleration for doing this in-place memory compression, but otherwise it’s pretty old news, which makes this marketing shtick even more frustrating. 8GB was borderline not enough even back when memory compression was added to macOS (maybe ~10 years ago?).

As many others have mentioned here, the backwards incentive structure is absolutely part of the problem -- i.e. businesses don't care to invest the time and money in making things efficient and performant, because the goal is to get something out the door as quickly as possible.

And, the fact that software can be continuously updated in the field makes it inherently different than other fields, which have to try to get something “right” the first time.

But I also think that we have a responsibility as engineers not to thrust technology out into the world without considering its impact, and that includes things like Electron. At its inception, I'm sure it was a hilarious and insane tech demo, but that's all it ever should have been.

The sad fact is that Electron solves a real problem, though, which is that developing per-platform native apps takes an enormous amount of effort. To me, it's a huge failing of the software world that we've not yet provided an alternative that's just as easy to deploy as Electron, if not easier, but with performance and efficiency built in from the start.

The last time I switched jobs was in October of 2020, so I haven’t experienced this personally, but I have a lot of friends in the same boat.

Lots of said friends were affected by layoffs at various tech companies over the last couple years, but I also have some junior dev friends that are finding it basically impossible to even get callbacks. Everyone seems to only want senior devs at the moment.

Super impressive level of detail (and easy to understand, at that). Cloudflare went hard on the statistics here.

You make a fair point. I’m sure there are situations where those assumptions don’t hold.

But, I think for most startups, there is _so much_ to do at any given time that, in general, no one should be left twiddling their thumbs, especially with smaller teams.

Personally, I’ve seen less and less A/V setup fiddling over the last couple years. Except when screen sharing comes into play. That’s still a nightmare for some reason.

And I do agree about the whiteboard thing, to a point. My team tends to do more long-form writing instead, and if diagramming is necessary, we use something like Monodraw.

WFH heading more towards sync than async feels like a cultural problem, perhaps partially rooted in a lack of trust if management can’t look over everyone’s shoulders. I’m sure that there are companies that are doing this, but I hope that this is not part of some wider trend.

Really tired of this horseshit narrative that a team has to be in the same physical place in order to be productive/successful.

Perhaps it’s more tempting to blame remote work than to blame one’s own leadership, or whether one has the right team.

And, async doesn’t have to be lower-bandwidth. With even a modicum of planning, engineers can be set up to pick up the next most important thing if they’re blocked waiting on a response from someone else.

This is not rocket science. Tons of successful companies have done this since long before COVID.

I emphatically, categorically disagree.

Maybe _perceived_ productivity and creativity is worse in some cases because remote workers can't physically be seen working, but that doesn't mean it's _actually_ worse.

Almost every engineer I know is able to be far more creative and productive working remotely than from an office, regardless of whether or not they need to collaborate closely with others.

In a previous life, I built and maintained a Dockerized CI pipeline (using Windows containers) for Bluetooth headphone firmware. Qualcomm only provides tools for e.g. CSR8675 platforms for Windows.

What’s worse is in some cases the source code has to be commingled with the SDK itself, so building projects can mean copying your source code and modifications over top of the installed SDK in order to produce a build. Docker’s ephemeral disks are a lifesaver in stupid situations like this.

We can disagree on the user experience-based motivation. Given the lack of any kind of public data on how those decisions are made, I can't blame you for thinking that way.

I do agree that developer experience is important, and that Apple should take developer experience more seriously than it does, and that applies across every org in the company. Case in point: the infuriatingly-opaque and mercurial nature of the App Store review process.

The problem is that, percentage-wise, developers are a minuscule portion of Apple's overall userbase. That makes the justification for fixing concerns that are (perceived as) unique to developers difficult when the culture has traditionally leaned toward prioritizing issues with a more obvious impact on the majority of users. I'm not saying this is correct or desirable, just the way things have worked historically.

Given all of that, I think “a browser full of bugs” is relative. I witnessed many instances of bugs being experienced by large numbers of users being fixed extremely quickly. It's always been a function of (obvious, measurable) impact. If a significant percentage of web apps were crashing 60 times a day, those bugs would have been fixed extraordinarily quickly.

Given my experience on the team, I genuinely don't believe that lack of investment, or even team size, has ever been the issue.

I think that all of the recent changes and increased transparency are great, but I disagree that the motivation behind those changes was any form of perceived or actual increased competition. From my perspective, this is the result of years--years!--of internal lobbying to improve transparency and increase release cadence.

Apple, on the whole, has never been interested in competing with other companies that operate in shared spaces on a feature-by-feature basis, even if it came at the expense of market share. The one and only guiding star has always been the user experience, and if there was no obvious user experience-based justification for prioritizing a feature or a bug fix, then it did not get prioritized, period.

This is, in part, why Apple engineers have always been adamant about third-party developers and users filing bugs--a higher quantity of reports makes it easier to justify addressing a particular issue to management during a given development cycle.

To this day, I don't have any reason to believe that anyone in my management chain (at closest, I was two managers down from Craig Federighi) ever considered profit when prioritizing features or bugs.

This guy's about page says:

    It is my professional mission to build a web that works for everyone.

Judging by this article, it's also his “professional mission” to present opinion as fact with no connection to reality.

I was on the Safari/WebKit team from 2012-2015, and I can say with absolute certainty that the author has no clue what he's talking about with respect to how bug tracking, feature/bug prioritization, or headcount works at Apple.

I could elaborate on all of that for an hour or more, but what I will say is this:

The _number one_ problem with the speed of Safari/WebKit releases has always been that they have traditionally been tied to the release of major OS versions. A few of us on the team referred to this as the “fundamental tension,” i.e. the tug-of-war between yearly OS releases and the much-faster pace of innovation of the web platform.

Everyone on the team was aware of this. Many of us lobbied to change this. The holdup was _absolutely not_ due to any kind of willingness to keep Safari behind in order to push people toward native apps, it was due to the seemingly-immovable internal culture of everything being tied to a yearly OS release.

The culture finally started to change with the advent of the Safari Technology Preview builds, which were explicitly meant to offer insight into the progress of new WebKit features. It seems like my former colleagues have done a great job in pushing for greater transparency and more frequent release cycles since then, and I applaud them for doing so.

I can't vouch for any of the more recent versions of CS193P, but the original incarnation on iTunes U in ~2008 was my introduction to Objective-C and C, and I found it invaluable. I remember Loren Brichter's guest lecture on the development of Tweetie being really insightful.

Personally, I'd skip Swift / SwiftUI until you have a decent understanding of the Objective-C frameworks underpinning the vast majority of the macOS/iOS SDKs.

I prefer:

    brew install hub
    alias git=hub
    git create [-p] [[org/][repo name]]

100% agreed -- if it wasn't clear, I wasn't trying to downplay the importance of immutable state. Just saying that it's perfectly achievable in Go with a small bit of effort.

I've written a heaping pile of Go code over the last few years. I consider myself a fan, but not a fanatic. I tend to believe that Go's failings aren't any worse than the failings of most other languages, and for me, the drop-dead-simple cross-compiling and batteries-included standard library is well worth its warts.

That said, I found myself vehemently agreeing with the author re: how hostile Go is to FFI/etc. IMO, a network boundary is indeed the sanest way for most other things to communicate with Go code.

Re: Go on Windows: anecdotally, things seem a lot better than even a couple years ago, but there's still room for improvement for sure. It's baffling that the semantics of e.g. os.Rename() are so different between POSIX-y platforms and Windows when they don't have to be (Windows supports POSIX-style renaming semantics if you ask nicely). I ended up having to reimplement os.Rename() on Windows in terms of SetFileInformationByHandle() with the FILE_RENAME_POSIX_SEMANTICS and FILE_RENAME_REPLACE_IF_EXISTS flags set to get the behavior I was looking for.

Re: mutable state, I think these concerns are mostly overblown. These are problems we've been dealing with in the vast majority of mainstream languages for many years now, and there are plenty of strategies for dealing with it.

For example, if I want to pass an "object" by reference in Go but do not want it to be mutated, I'll wrap it in an interface with getter methods for its fields, but no setters or anything that can cause side effects. Sure, it's a bit more involved than tagging something with the `const` keyword in e.g. C++, but it's plenty effective.

Yep. First time I’ve seen anything like that on GitHub.