Links

Interesting bit on translating sign language at a standup show (for a kid!), trying to choose appropriate tone & sign choice.

Strongly agree with this. Some choice pieces:

Aggressively popularized “best practices” often have a tendency of manifesting cargo cults around them, enticing developers to apply design patterns or use specific approaches without giving them a much needed second thought

Naming tests in accordance to specifications rather than classes has an additional advantage of removing that unnecessary coupling. Now, if we decide to rename SolarCalculator to something else or move it to a different directory, the test names won’t need to be updated to reflect that.

To summarize, we can conclude that it’s a good idea to partition tests based on threads of behavior, rather than the code’s internal structure.

The “write your code so it’s easy to test” idea is silly. Write your code so it’s easy to read. Test speed should barely be a consideration for your 200 line side project. Cypress tests are easy to read and actually test that stuff works. Test speed does become a factor eventyally, but worry about it then, rather than upfront.

All too relatable. I have been struggling with this for years

Amazing write up, and clever outcome. Waist-level pockets are indeed stupid or poorly design most of the time, The reach/support diagram is a good illustration of the problem space

Great writeup, and fun to go through the questions and explanations. I really went off the rails with grep and parsing estimates, others were mostly solvable.

HN Discussion has people alternately arguing about whether modern programs are fast, or bloated and slow.

I don’t think Moore’s Law is an excuse to not worry about program performance, and the current slew of slow apps (web and otherwise) is not acceptable. Many electron apps really do feel slow. Waiting for my password manager to open (either electron app or chrome extension) is frustrating. It’s minor, but it’s friction to something that needs to be frictionless.

That isn’t to say that can’t be made fast. VSCode is a good example - that uses electron but has remainined very performant. They got boot up time down real low (actually relevant for me as I open/close sessions often). BUt on my older laptop (4gb RAM) I can’t have it open alongside browser, so mostly use editors in the terminal. It does still mostly work, but they have focused on perf speed rather than footprint. Still some tradeoffs to be made there, and again another hard thing to think about.

There are definite costs to the abstractions, but also benefits. But none of this is free. Perf is hard, and computers being faster doesn’t mean we don’t have to think about it - time has been unchanged. Only our expectations have (of features and speed).

2 hours saving 10 seconds per file open twice a day is an egregious violation of the xkcd rule, but it was fun and I learned a lot about Vim automation in the process.

AND saved me 2 hours as I simply found this on google

it was more of a synthesis, one idea leading to another and then another

I think a lot of things are developed in that way, but people still love the inventor/flash-of-inspiration narrative

Most of it hinges on this:

I don’t foresee enough people paying for niche newsletters for this model to be feasible.

I don’t know enough to have an opinion on this. People are quite cheap with written content, in particular for niche publications vs a newspaper/journal that publishes across a range. But there are also a lot of people on the internet, so who knows.

Good explanations & debugging tips in there, and entrypoint: [""] was the solution I needed!

I didn’t know about pre/post for all scripts in npm!

git-annex warrants another look.

Instead, you should try to blend together the needed disciplines as best you can, consulting others when necessary, an offer the best plan you can, namely the best plan all things considered.

That might fill you with horror, but please recall from Tetlock that usually the generalists are the best predictors.

Very readable, similar to super tiny compiler

Salaries for different levels of job for a bunch of companies

I really like the original one, and this is a solid reply

Lot of good parts

The high performance parts aren’t React. Mapbox GL, for example, is vanilla JavaScript and probably should be forever. The level of abstraction that React works on is too high, and the cost of using React - in payload, parse time, and so on - is too much for any company to include it as part of an SDK. Same with the Observable runtime, the juicy center of that product: it’s very performance-intensive and would barely benefit from a port.

The less interactive parts don’t benefit much from React. Listing pages, static pages, blogs - these things are increasingly built in React, but the benefits they accrue are extremely narrow. A lot of the optimizations we’re deploying to speed up these things, things like bundle splitting, server-side rendering, and prerendering, are triangulating what we had before the rise of React.

Amazing collection of large numbers and small languages

This is joy

todo

That squares with my experience of software development. It’s like being a furniture maker but spending 80% of your time fixing your goddamn hammer because it keeps breaking and no better hammers exist, or consulting glue-drying tables because they keep changing your glue on you every hour or two and for no good reason every single glue performs differently while accomplishing the same thing.

Ive noticed some people use github almost like a social network. A rough analogy to Twitter would be that starring a repo is similar to liking a tweet, and forking it is almost like a retweet.

Love this term - this is exactly how I learn. Start by skipping over the details,
develop a coarse understanding, then refine your knowledge by learning about specific areas in more detail.

It is a long lesson that I am still not through, will see if it can live up to the bold claim of its title

source

Many helpful perspectives

Great way to learn things, and to make exactly the thing you want.

HN discussion

The Show HN for this has some alternate great tools for similar things

Interesting estimates and numbers - clientside savings really add up.

In fact, it is probably the most effective use of my time when it comes to reducing carbon dioxide emissions.
Just last week I reduced global emissions by an estimated 59.000 kg CO2 per month by removing a 20 kB JavaScript
dependency in Mailchimp for WordPress. There’s no way I can have that kind of effect in other areas of my life.

Highlights:

• People exhibit overconfidence in their ability to calculate exponential growth
• People exhibit overconfidence in their ability to use a spreadsheet
• The results suggest insufficient demand for help and tools

Continuing on why touchscreens are a shitty interface, especially for vehicles

Interactive examples to learn through reading and play. I looked at a music one and it was one of the best visualisations of notes/harmony I’ve seen

Went through a few of these in December and was pretty great. Unsubscribing from services/lists, and deleting a bunch of notification mails.

I noticed this as well. Went from wanting to code all the time, to wanting to do something not web related in spare time. Hobbies are important!

Constrain the infinite vastness of space to the bridge of a single ship