Hello fellow old person. I mostly agree, and I think we’re starting to see some convergence on the core patterns that will define the “best way” to deliver web apps for years to come. The various offshoots of React are really just evolutions to see what fat we can trim and tighten it up. But functional-reactive UIs as a general thing are here to stay and better than all the other ways we’ve wired up GUIs to date.
I think Roc has some ideas like this.
On a sandboxing level, I suppose we’d be talking about Unikernels (which seem cool, but the tooling didn’t look simple enough to experiment with them)
I don’t know the specifics of the golf problems, but I’m mostly in c#, also notorious for “having too much boilerplate,” and it looks like it’s 3rd by char count.
My guess is that languages with comprehensive standard libraries can do more with less custom code. As you should expect.
Hard agree.
It looks slightly gross if you try to read/internalize it, but I’ve been making web pages since the mid-90’s and it’s the least obnoxious way to style html I’ve ever used.
Important/generalized patterns reveal themselves over time. I generally push for people to just write the specific thing they need for the given context and then if the same pattern shows up elsewhere, promote the code to a shared library. It’s really hard to anticipate the correct abstraction right from the start, and it’s easy to include a bunch of “just in case” parameterization that bloats the interface and adds a lot of conceptual overhead.
That being said, with low-leverage/complexity code like html views, repetition isn’t as problematic. Although, I do think that HTML components have matured enough to be the correct unit of abstraction, not CSS classes.
Demo videos are not “documentation.” They are “demos.”
If you want someone to repeat your steps, it should be code or CLI commands. You can write more descriptive text, but as soon as you reference pictures to show something, you’re introducing ambiguity that text/code can avoid.
UIs change faster than videos and screenshots, as you said, can’t be searched, and are generally less accessible than text.
The source files for documentation should also live side-by-side with the code in the repo. As soon as it goes anywhere else, it immediately goes out of date.
Yeah, -p can help with that. I’m not much for “commit grooming” - as long as a branch merges to main cleanly and passes tests, I don’t care about an “ugly” commit history.
I think this is an important lesson in general, and one that applies in other contexts:
You don’t need a “cheatsheet” for most stuff. The things you do all the time will become muscle memory, and the other stuff is easy enough to look up as it’s needed.
You don’t need to memorize the entire class structure of your projects. The “hot paths” get the most attention, and you’ll remember the most critical stuff as you work in a codebase. There’s lots of code that is basically “dark matter” - we know it’s there, and it’s doing something, but because we rarely review/modify it, it’s only important to understand its observable effects, not the precise way that it works.
Your brain is basically like an LRU cache - the stuff that you touch a lot will stay loaded, and the stuff that you rarely use will get dropped. Embrace this property.
I’m not sure if you’re being funny, but of course committing the output of your program isn’t what I was saying.
That’s fine until a UI changes, or the steps to reproduce it are incomplete (or a human doesn’t follow them exactly).
Text commands are unambiguous and precise.
There are other reasons to use it. A major one is doing a “code review” of changes before committing, or even deciding to drop a chunk of code from a commit entirely (like a debug statement that no longer is necessary.)
I’m all about frequent commits (and right-sized commits), but the functionality can still be beneficial even in those scenarios.
I also don’t care if I have a broken commit. This turns up very quickly, and there is zero expectation that feature branches are always in a working/stable state. The expectation is that pending work gets off the local machine on a regular interval.
They basically aren’t?
If you’re doing one-off hobbyist stuff, maybe.
But literally anything in a professional setting should be in text that can be committed and searched in a source code repository. If you can’t commit it to git, it didn’t happen.
Cue the first post about the exploit that leads to leaking AWS keys. I’ll wait.
You can stage individual chunks of a file.
Useful if you have a large set of changes you want to make separate commits for. I also just find that it’s a good way to do a review of each chunk before committing changes blindly.
Give it a shot some time, worst case is you stage some stuff that you don’t want to commit, but it’s non-destructive.
I’ve had ohmyzsh installed for years. TBH, I still don’t know what it gives me over bash. In your experience, what is the “killer feature” of zsh?
I use git on the CLI exclusively. I almost never rebase, but otherwise get by with about 5-10 commands. One that will totally change your experience is git add -p
I also have my diff/mergetool configured to use kaleidoscope, but still do everything else in the CLI.
I think you’ll have better luck with podcasts. Technical books tend to have long tracts of code that would be excruciating to listen to.
You might enjoy:
I read The Phoenix Project recently, and had a PTSD episode from all of the hallmarks of dysfunction that I’ve experienced in my career. Good book, but probably needs a trigger warning.
We used JIRA effectively at my last job, the things that made it work for us:
I agree with the premise of the article, JIRA is a communication tool, not a management tool.
Just to add, I’d argue dotnet has one of the best sets of guidance on style. It goes beyond just naming and towards how to structure code for easier consumption and consistency. People love to dump on MSFT, but the dotnet platform is superb.
https://learn.microsoft.com/en-us/dotnet/standard/design-guidelines/