lbayes

Just another anecdote here, but I'll go ahead and share.

I was essentially raised by a single working mother who spent 12 years getting herself a Master's Degree while working full time and raising a very independent and even more obstinate little boy.

We weren't the poorest people I knew, but clothes came from Goodwill and we did not have enough money to put oil in our home's heater during some winters.

By 7th grade, I had been managing my own meals, hygiene, laundry and getting to and from school for a few years. I was also running as fast as I could directly to jail or worse. I had become feral.

I was extremely lucky that my mother forced me to try out for a magnet program, which got me into a different social group and even though I continued to find some trouble, I did not continue to find ever worse kinds of trouble.

Of course, I could be wrong, but I believe that art program and the teachers, students and counselors there saved my life.

It would be a real shame if we allowed people to dismantle those programs, as I certainly am not the only economically disadvantaged person who found themselves at least somewhat stimulated and essentially saved by the experience.

Definitely.

In fact, it's super easy to back up as it's in a SQLite database (for now).

Ex-Googler here and 20+ year veteran of SF startups.

It sounds like you have a great set of intuitions, and you're right, all that infrastructure is a nightmare to set up and manage.

Step 1: Question every requirement

Step 2: Drop everything that is not critical

Step 3: Profit!

Git hooks and Makefiles are great!

I have an HP workstation I bought from eBay under my desk that has 32GB of RAM, 2x 12 core CPUs and a static IP address. It's probably 8 years old, but fast enough to serve whatever we need for a long while.

The machine (Old Blue), hosts our Git repos, web app, database and integration service (git hook that calls, 'make publish').

We're not serving Google scale traffic, so we don't need Google scale infrastructure.

Keep it simple whenever possible and don't let the modern stack complexity creep in until you absolutely need it.

Even going to the cloud, when you've done it 10 times and know how, is way more work than you need when just starting out.

Take on those costs and complexities only when your traffic requires it, and you may just find out that you never have to pay rent for compute.

You're right. Thanks for calling it out.

(deleted stupid comment) apologies!

Also hit the back button trap with Firefox on Android.

Ew

I've been really surprised at how simple it can be to configure complex ICs with basic pull up / pull down resistors and voltage dividers.

The (older) books I was reading got me really nervous about needing to design all kinds of complicated circuits, but most things these days are just finding an available IC and configuring it.

Well... It's not so trivial to find an "available" IC this year, but hopefully this too shall pass.

I feel obliged to point out the destructive power of Knuth's statement, "Premature optimization is the root of all evil."

I have encountered far too many people who interpret that to mean, "thou shall not even even consider performance until a user, PM or executive complains about it."

Challenge accepted!

I found myself in a monthly meeting of 12 or so (Unnamed FANG) managers where they would curate a collection of 3,000-5,000 bugs / issues / feature requests.

It was almost entirely the same collection of old, stale bullshit that no one was ever going to work on.

The meeting started with recently added items, and those were usually digested within minutes.

The rest of the old items were just waste.

This meeting sometimes took a full day. It took enormous amounts of time and energy to review and re-review and debate and re-debate, and with every new contributor, all the old discussions had to be repeated for many of these items.

100% of this effort was waste.

In contrast, our team carried zero open defects. We agreed to either fix or honestly reject defects immediately. We experienced none of this waste and on the handful of occasions where we inappropriately rejected an important defect, it became clear very quickly and we fixed it.

Put the things you want to do someday in some other tool.

The icebox is cancer.

It reads like pretty good GPT to me.

Couldn't a build system use a hash of the accumulated files as a cache key and rebuild it's internal state when that changes?

I'm not seeing a big downside, but maybe I'm missing something obvious.

I had my first real exposure to CMake earlier this year.

It demos beautifully, but quickly becomes an outrageous collection of side quests to find the secret key.

What collection of hidden methods, global constants, environmental variables and insane incantations must I assemble to cross compile this software?

None. The answer is, None.

The best I was able to find, was get the whole artifice running on your actual workstation, then get it (and an entirely different tool chain, including IDE's?!!) up and running on each target platform, dust off your sneakers to go sit in front of another computer, fire up an IDE and find it's build button.

I know it's not, but CMake somehow manages to feel like a solution created by hand wringing, cat petting, volcano living, mustachioed, cigar-smoking proprietary OS and IDE vendors.

OTOH, zig cc leaves me with a single tear of joy and wonder sliding down my cheek like a framed Velvet Elvis.

Update: Also, premake isn't terrible.

This. I'm stunned this kit was ever created with the shape it has, but even more stunned a second person agreed to use it.

It completely blows my mind that this demoware has made inroads anywhere.

Since 2016-ish, I've been using the Dell XPS 13 "Developer Edition" (3 models so far), and they're consistently decent machines.

I still have a Linux workstation for big tasks, but XPS has been good enough to wean me off Macs ever since they introduced the touch bar, which was a hard pass for me.

Caveat:

I had to swap the radio in the first one due to driver issues, and I continue to experience occasional issues with Bluetooth, suspend and graphics rendering.

It's not all roses, but the benefits far outweigh the disadvantages (for me at least).

A couple more:

1) Do not limit the length of the password to some arbitrarily small number.

2) Do not validate email beyond the simplest, "includes an @ and a period. Email is validated by sending a confirmation link.

3) Don't get so stupid with the "secure password" special character crap. Some of us use super long, but memorable passwords, which are more secure than your bull#@!+&$

My first reaction to those reviews was that they read pretty disrespectfully. Writing a book is extremely challenging and some of the feedback is not appropriate for a page that's associated with a standards body.

Then I wondered, "If these are the resources to avoid, where do these people recommend I find the good information?"

Alas, those links are mostly broken.

As a long time programmer recently learning C, I've been surprised by how prickly and unhelpful C culture tends to be.

The concensus seems to be that no published information is good enough, and none of the critics are willing to publish the good information.

Maybe I just haven't found the right groups?

This line was highly distracting for me, "To make matters worse, the shell has been mostly left for dead by both academia and industry, considering it an unsalvageable piece of junk that needs to be replaced at the first opportunity."

Um, false?

Many people in industry use and love using the shell.

Please read, "In the beginning was the command line."

The shell is by far one of the most powerful and expressive tools we have. Yes, there are many ways in which it could be improved, but JSON? That's not it.

I spent quite a few years living in dynamic languages and looking enviously over the wall at those lucky engineers who could use static type systems to catch all their bugs (truly, this is not sarcasm).

Then I finally got an opportunity to work in a handful of those environments, of course the first was everyone's favorite whipping boy, Java.

Yikes!

Maybe I've just been unlucky or unsmart, but wow, I've seen (and even made) some really impressive messes with these languages (specifically: Java, ActionScript 3.0, Closure (.js), Typescript, Go, C++ and C).

In my experience, especially in the context of UI development, the static type systems I've encountered generally make the task of unit testing more difficult and time consuming, while adding little to reliability.

At the end of the day, I just don't bump into major type mismatches in dynamic languages that cause a whole lot of hearteache.

All that said, Go was probably the best static type system I've worked with until I (recently) discovered Zig, which has a really interesting type system (esp. related to comptime) and has testing built into the language itself.

While it might at first look like it, I'm not saying static type systems don't have a home in my heart.

I'm just saying that in my experience (just like TDD and Unit Testing), they haven't led to the bug-free panacea that proponents tend to imply.

I do find it endlessly fascinating that 2 people can walk through similar-ish challenges and arrive at entirely opposite conclusions about how to best tackle them. Thanks!

Overall agree with the OP, but wanted to provide a minor objection, or maybe clarification.

I've been writing software professionally since '98, so I'm a little greener than @tbray. During my career, I've almost entirely been focused on building UI's, though I have done quite a lot of full-stack and embedded work.

I got infected by testing in ~2003-ish when I started reading Kent Beck and Martin Fowler.

FWIW - I had a 4 year stint at Google (10 years ago), where I led the team that built YouTube on TV.

Our product on the TV team certainly had it's own set of challenges, but quality wasn't one of them. By the time I left, we had over 2,400 unit/component tests that would run in ~30 seconds. This single application ran on many hundreds of SKUs (PS3, PS4, XBox 360, XBox One, Wii U, Smart-ish TV's, Set to boxes, Over the top boxes, Cable boxes, Roku, Chromecast, Blue Ray Disk Players, crazy, crazy stuff).

A given engineer could set up a file system watcher, that would run a much faster subset of tests in under a second. We deployed this application to production every week (which was revolutionary back then), and one of the years I was there, we had a single P0 production incident for the entire year.

We changed out the underlying UI framework 3 times over 3 years. We did this incrementally with side-by-side running frameworks and while delivering to production every week.

It would have been utterly impossible for us to accomplish this work without the testing infrastructure that we had. And by testing infrastructure, I mean:

1) Karma (or Mocha or Jasmine) for unit / component tests

2) Manual testing on problematic machines where automation was prohibitively expensive

The OP-linked twitter graphics are also triggering me.

Every time I've seen "Integration Tests" in a production environment, they've had the following characteristics:

* Slow: 10-40 minutes

* Brittle: Break mysteriously while working (if you can even run them from your workstation)

* Time-consuming: These tests chew a lot of time to author, and much, much more time to maintain

* Flaky: This is the deal-killer for me. They fail randomly in CI, and chew hours of the team's time trying to troubleshoot. You'll know you're here when you see random timeouts in your tests.

The main insight I came here to share is this:

There's nothing magical about UI. It's just software. It's probably (IMO) one of the more complicated areas of software engineering, but that's because of what UI is generally made of:

UI tool kits usually represent the user interface as a long-lived, mutable, wide and deep tree of interdependent state with a multitude of message passing schemes and needless hooks to global references everywhere.

Despite this, it's almost always possible to:

1) Disconnect and/or minimize the hooks to global state

2) Clarify message passing rules/practices

3) Break down the tree into manageable chunks

Once these ideas are in place, we can incrementally test UI as it's being built.

As an example for why we don't need "Integration Tests", I've often written "component" tests that instantiate a relatively complex node of my UI tree, poke the data, and verify some substructure was updated. This can and should be done without random timeouts and global nonsense.

We may not always be able to test our root node or main loop, but jeebus people, make those two things tiny and test everything else.

It's not magic, and it's super valuable.

It does admittedly get me worked up when people notice that UI is rarely tested, and then make claims that it probably shouldn't be.

It's not even mainly about the maintenance. Writing tests first(ish?) dramatically improves the design of my otherwise, much less clean code. Testing as part of development is an extremely powerful design tool that has ancillary benefits for maintenance and reliability.

As the OP said, these tests have to run incredibly fast (< 1 second at author time) and additionally, the unit under test cannot have a bunch of tentacles reaching out to manipulate global state.

Yes, almost all UI tool kits as they exist today are horrible to work with, but that's no excuse to just abandon the primary practice that almost makes our work bearable.

[Update: formatting]

I've struggled with brutal insomnia (getting to sleep and staying asleep) my entire life (45 years old now). Over the years, I've gotten pretty good at forcing myself to get to work early and just made due with 4-6 hours on most nights and trying to make it up on the weekends.

Early this year I discovered medical marijuana. It's completely game changing. A few puffs from a vaporizer (with flower, not the terrible oil pens) and I've had some of the best sleep of my entire life. I don't remember a time when I've ever actually felt good waking up until now.

The other key (for me) was the book, "The Obstacle is the Way" by Ryan Holiday. This helped me dramatically reduce the nonsense and worries that would crowd my mind as I tried to fall asleep.

Obviously YMMV, but these two things together have helped far more and far longer (6 months now) than anything else I've ever tried.

Nice catch, thanks!

What about Noms?

"The versioned, forkable, syncable database"

https://github.com/attic-labs/noms

My friend Kyle lost his arms and legs when he was an infant. He's a competitive gamer and this is his experience/review of the latest Pokemon game.