l_t

Here's my take -- the list is incidental. It could have been anything. The key here is that he engaged with his dreams in a real way. He thought about them, made them concrete, and then tried to actualize them. He gave his life a goal and a self-directed "meaning."

Imagine if he tried to do the things on his list, but failed. Would he be less happy? Probably not.

Of course, this is all assuming that he is truly the "completely satisfied" person that the article paints him to be. I doubt any person is quite so simple as that.

I don't think so. What is old is new again; even this blog post is an example of a developer relearning that core lesson.

Also, I'd like to point out that in both this blog post and the Taco Bell one, the "UNIX way" is being compared against a straw man example, not a real example of over-engineering. Neither post actually provides any evidence of any real inefficiency. Both authors are just trying to explain and improve their own thinking about programming, not trying to cast judgement on a generation.

I like the "everything is text" mentality, but really, the "hard part" of the GNU/Linux CLI is getting things done when you don't already know how.

If you've memorized the hundreds of different invocation arguments for find, sed, grep, tr, sort, uniq, cat, xargs, etc. -- then yes, you can be very fast. If not -- be prepared to RTFM for about 4 different programs to get your job done.

That's an incredible hurdle and it really only makes sense if you are using these tools daily/weekly. I'm still not completely convinced that its "worth it" to master these tools, when general-purpose scripting languages are almost as succinct and obviously way more powerful. That's speaking as someone who's written a fair amount of Bash.

In contrast, I think tools with higher discoverability and self-documenting nature (arguably, Excel) usually offer a more user-friendly way of doing the same thing, unless you are doing it a lot.

Yeah, great point. Kubernetes done right can help with these things, but done wrong, it can cause more problems than it solves. Of course, for a personal project, hitting those "unknown unknowns" is all part of the growing process, but in a business context I would be even more hesitant to adopt K8s unless you already have an ops team that's ready to support it.

IMO, Kubernetes is one of those things where if you have to ask, you don't need it. It's only really "justified" if you're actually using features like:

- High availability services (more than one copy running at once).

- Service discovery (services talking to each other in a resilient way).

- Ability to automate operational tasks.

- Rolling deployments of services.

Very few personal projects will tick those boxes -- by the time they do, they've usually evolved into a full-on "real project".

Doesn't mean you can't mess around with Kubernetes for fun and learning, of course. But from a purely practical perspective, it's overkill unless you have all of those requirements above. (If you just have one or two of those needs, there is usually a simpler tool to fulfill it with less overhead).

Well, we can certainly get better as a culture about promoting moderation and social consciousness over greed and winner-takes-all mentality.

Competition will always exist, and we should accept that, but it's not a binary thing, it's a spectrum. I for one would be happy to see our society move to a less competitive, more collaborative mode.

The most important thing, if you haven't already, is to set the noImplicitAny and strictNullChecks compiler flags. I find that not having these flags set is a common source of Typescript type unreliability.

The flags prevent two behaviors that are a major source of type failures: defaulting some types to "any", and allowing null/undefined to be valid values for ANY type (!). Enabling these flags for an existing codebase is likely to uncover hundreds of type errors that are papered over with the default compiler settings.

W.r.t. upstream types for libraries being wrong, I find the silver lining here is that libraries will usually be happy to accept patches for their types, often with significantly less fuss than a patch to the actual code.

edit: Even with those in place, I also notice that Typescript types are not 100% trustworthy. This often comes down to unsanitized input, use of the "as" keyword, or hidden type violations. The conclusion I've come to is that it's just very hard to type Javascript code, partly because the values themselves are so prone to being mutated. So I agree that Typescript doesn't feel like the perfect solution to me. (I usually use Clojurescript these days).

The author's stated stance is that you can, but usually shouldn't.

Personally, I think to myself before using regexes to parse HTML:

1. Am extracting more than the contents of a single element?

2. Is the input HTML prone to change?

3. Will there be issues if the parsing completely fails?

4. Do I plan to use this code for more than a few months?

If the answer to any of the questions is "Yes", then don't use a regex :)

Isomorphic in this context means the library supports running in Node.js as well as in the browser. (This is mentioned further down in the README).

I see this as a cultural problem, with a cultural solution.

If you think about "free riders" versus "cooperators" as a dichotomy, you won't find a solution. Everyone is both a "free rider" and a "cooperator", depending on social context. The issue is that our social fabric itself may be incentivizing people towards long-term destructive patterns.

So, how do we fix it? IMO, the best any one person can do is try to create an environment where people feel safe to cooperate. I believe human nature is fundamentally cooperative in large groups, but we are often "forced" into a competitive track by a lack of resources or other external pressures.

For example, many US workplaces pit employees against each other. It's perceived that there are too many workers for a limited number of jobs, so workers feel forced to compete for their "slot." If there was less communal anxiety about being fired, more individuals would feel comfortable to cooperate with their coworkers instead of competing.

Ofc, this is an insanely complex issue, so that's just a tiny facet, and I'm sure some of the points are debatable. But I honestly believe that "taking care of people" is one of the key ways to achieve more collaboration.

It seems like YDNW is like a CMS that uses Google Drive as the "backend"/admin UI.

Personally, I see the benefits to using GDrive as the backend, but instead of having to host a server, I would rather be able to run a static site generator that exports my GDrive folder into some HTML that I can push to a free/cheap hosting provider. Is that something you've considered?

Static site generation would also obviate the concern that Google could "delete your blog" -- at worst, they could delete the source documents, but the published blog would be unaffected.

I think the article hits on the key problem:

"Less than 100% reliability is essential for the sustainability of an off-the-grid solar system."

IMO, this can only become mainstream once there is no longer an expectation of "100%" uptime for websites in general.

It's far-fetched, but I can imagine it becoming mainstream if mesh networking becomes popular, or if the Internet were to become a widely self-hosted platform (e.g. people had their own "clouds" running in their homes). In such situations, 100% uptime would no longer be an expectation, so the perceived cost of using an off-the-grid system would be reduced.

For an interesting perspective on this topic, I'd recommend "Man's Search for Meaning", by Victor Frankl.

Frankl was a Jewish psychiatrist who survived Auschwitz, and one of his points (as I understand it) is that humans deeply desire to know that their life is meaningful, and even if another person is torturing you, you can find meaning by maintaining your human dignity in the face of the evil around you.

The stories in the book are heartbreaking, but there is a clear sense that it's possible to find something even when it seems like there's nothing. I guess he would say: perhaps you can't always find peace, but you can find meaning.

Changing the title of an issue, presumably so it doesn't show up in search results? Deleting the body of the issue? Not leaving any explanation? Yeah, that doesn't seem normal to me. Can't say I approve.

Choose a startup where:

- People regularly take vacation time.

- They're happy to hear that you care about work/life balance and will not work more than 40 hours a week except in emergencies.

- You're not strongly invested in whether the company experiences long-term success.

- They have a moderately refined change control process (e.g. Scrum, but anything works as long as it collects all the work in one place to be prioritized and scheduled).

- You don't have to go on-call. (For many, this can be quite stressful.)

Good point about the testing system. Test coverage plus a good CI/CD system goes a long way to reduce "deployment anxiety", in my experience. Untrustworthy tools or broken processes can be a major source of stress.

But, I wouldn't completely discount startups as an option. There are startups that respect their employees time and offer a great environment for low-stress workers, at least at the 10+ employee level. (I don't have much experience with startups smaller than that). If you value self-determination, a startup can be a great option.

I would tell your friend that programming best occurs at the appropriate level of abstraction to succinctly express the problem at hand.

For example, if you are trying to write "business logic", you don't want to have to worry about allocating memory or ensuring data consistency. You just want to worry about business concerns.

I suspect your friend has simply not tried any sufficiently difficult programming project. If your problem is non-trivial, you feel appropriately grateful for libraries that provide higher layers of abstraction.

I would argue that it's also theoretically misguided. After all, it's not like programmers in the past didn't use libraries and pre-built components.

If anything, I'd argue the LOC it takes to accomplish many tasks is actually increasing because applications are held to higher standards of quality, scalability, availability, scope, etc.

I think about defining the "maintainability" of code as a reduction in the amount of time that will be spent working on that code in the future. Therefore, there are two broad categories of maintainability fixes:

1. To reduce the number of changes that will need to be made to it.

2. To reduce the time it takes to make each change.

The (1) category encompasses the idea of making code that requires few changes. Such code is essentially "right" to begin with. I think about this mostly in terms of models -- i.e. does it accurately model the problem -- and quality -- i.e. does it have bugs or performance issues. Of course there are other concerns as well, but those are two big ones and they often involve thinking like a "computer scientist."

The (2) category -- reducing the effort of changes -- is achieved by using appropriate abstraction layers, encapsulation, low coupling, and other good-program design. There are many technical concerns in this category, but it seems there are some social ones as well.

I would say the programmer's experience is another huge factor. To sum it up in a phrase, perhaps "writing maintainable code is an act of prediction."

The OP's comment was specifically with respect to the large number of dependencies, which can increase the "surface area" for this type of attack to happen. And, of course, we're talking about VuePress because this is a thread about VuePress. Similar complains are raised for many other Node libraries, so rest assured that VuePress is not alone in that regard.

Fair enough -- it's not like it's completely opaque. But when I start a project and see there is no webpack.config.js in the project root, I feel the opposite of relief.

For example, if there isn't a config file, it's usually because there are more than one. Or, even worse, the config is dynamically generated. A build process like that is much harder for me to fully understand than one with a simple webpack.config.js.

However, this may be biased, as it's coming from the perspective of someone who already "knows Webpack".

Yeah, I guess I got the story wrong. Thanks for the correction.

Yeah, that made me laugh. Is it really a relief to have a config file you can't see instead of one you can?

Based on the title, I had assumed that Google somehow reprimanded the engineer, but as far as I can tell, Google has nothing to do with the story -- he was kicked out of Caesar's Palace while at Defcon.

Well, I wouldn't have clicked on it if the title was "Man Banned From Caesar's Palace For Defcon Tweet", so I guess Wired knows their business.

True, but they can compromise the machine that runs VuePress (or at least, run arbitrary userlevel JS code on it).

Ah, that's true. Good point.

Boolean operators returning values is common, especially in dynamically typed languages. The code is valid in JavaScript, for example, and in Python (except it uses "or" instead of "||").

Ah, thanks for the correction. I remember being told they had the same creator; that's what got me interested in foobar2000 in the first place, years ago.

If you haven't seen it, check out foobar2000 [1]. It was created by the same dude that made the original Winamp (which is now owned by Yahoo, IIRC).

[1]: https://www.foobar2000.org/

I haven't experienced this personally either. What I have noticed is the following:

- Signaling in tech is a real thing. I believe this stems from being (understandably) picky about our peers, combined with a fundamental difficulty of evaluating them. The problem is complex enough that our strong tendency is to fall back on stereotyping and other heuristics.

- Many programmers (myself included) have had encounters with "Web developers" whose primary interaction with JS is copying and pasting. Of course, it's hard to say what percentage of "Web developers" fall into this category -- certainly it's just a small proportion of the whole -- but enough of this type exist that "Web developer" is not always a positive signal -- indeed, it can be negative for some people.

- The above issue appears to be self-reinforcing, because the more the tech culture becomes aware of the problem, the more the stigma grows for existing Web developers that have not changed their title. Posts like the OP's are valuable because they work to correct our cultural narrative.

I'd expect the most likely people to experience this are "Web developers" who haven't yet accrued enough other signals of their competency (like experience, charisma, or similarity with their peers). e.g. a soft-spoken female Web developer without a lot of experience sounds like an archetype where this could be an issue.

Of course, it's a game of chance. But the odds are incredibly different for each person.