l_t

Judging by your post history, you might be a software engineer. As such, you might benefit from a few specific tactics I haven't seen in other comments yet:

1. Being an interviewer.

2. Being a mentor. (onboarding mentor, for example.)

3. Join your workplace's "Donut" program, if it has one. (I don't know what these are normally called, but at my job it's a thing where you get matched with a new random coworker every two weeks for a half-hour chat.)

The common thread of these tactics is you have the opportunity to meet new people in a mostly-familiar workplace context where you probably have more confidence and a greater sense of belonging. The more supportive environment lets you learn conversational skills that you can then deploy in more unfamiliar contexts like meetups or gyms.

Not only that, but for (1) and (2) you -- hopefully -- get training/shadowing opportunities before being thrown in the deep end.

Between those three things, I've had 1-1 (or 1-1-1, for interviews) conversations with 100+ different people over ~5 years. In retrospect, this has considerably reduced my social anxiety, although that had never been my explicit intent (I was just trying to help / learn / etc.)

As with all things in life, YMMV. Obviously these tactics are workplace-dependent. And if the idea of mentoring or interviewing puts you in the "panic zone" (brain shuts down), you might be advised to try some intermediate steps first.

Not disagreeing with your point, and I'm sure you already know this, I just wanted to point out (for the benefit of people that don't have other options) that it is possible to build "webhooks" in such a way that you're confident nothing is dropped and nothing goes (permanently) out of sync. (At least, AFAIK -- correct me if this sounds wrong!)

Conceptually, the important thing is each stage waits to "ACK" the message until it's durably persisted. And when the message is sent to the next stage, the previous stage _waits for an ACK_ before assuming the handoff was successful.

In the case that your application code is down, the other party should detect that ("Oh, my webhook request returned a 502") and handle it appropriately -- e.g. by pausing their webhook queue and retrying the message until it succeeds, or putting it on a dead-letter queue, etc. Your app will be "out of sync" until it comes back online and the retries succeed, but it will eventually end up "in sync."

Of course, the issue with this approach is most webhook providers... don't do that (IME). It seems like webhooks are often viewed as a "best-effort" thing, where they send the HTTP request and if it doesn't work, then whatever. I'd be inclined to agree that kind of "throw it over the fence" webhook is not great and risks permanent desync. But there are situations where an async messaging flow is the right decision and believe it or not, it can work! :)

Yep -- under the hood, "immutability" in Clojure is implemented with data structures that provide pretty good performance by sharing sections of their immutable structure with each other.

For example, if you have a vector of 100 items, and you "mutate" that by adding an item (actually creating a new vector), the language doesn't allocate a new 101-length vector. Instead, we can take advantage of the assumption of immutability to "share structure" between both vectors, and just allocate a new vector with two items (the new item, and a link to the old vector.) The same kind of idea can be used to share structure in associative data structures like hash-maps.

I'm no expert on this, so my explanation is pretty anemic and probably somewhat wrong. If you're curious, the book "Purely Functional Data Structures" [0] covers these concepts in concrete detail.

[0] https://www.amazon.com/Purely-Functional-Data-Structures-Oka...

w.r.t. long-form writing, two suggestions -- depending on whether you prefer keyboard or handwriting:

- Keyboard: With a phone that supports USB host mode, you can plug your keyboard of choice into the USB port and use that for input. With a small mechanical keyboard like [0], you can have a great mobile typing experience.

- Handwriting: E-ink tablets like the reMarkable 2 [1] are quite cool if you want a paper-like writing experience.

[0] https://www.duckychannel.com.tw/en/Ducky-One2-Mini-Pure-Whit... (Note -- this is just an example; I'm not familiar with this specific keyboard, but there are a lot like it out there.)

[1] https://remarkable.com/store/remarkable-2

I've been involved in rewrite-from-scratch projects that worked, because the scope of the system being rewritten was relatively small. So, I've concluded "rewrite from scratch" projects get a bad rap because they tend to also be very big, nebulously scoped projects, almost by definition. But it's totally unrelated to the fact that they're rewriting a codebase, and everything to do with the size and scope of the project to rewrite a codebase.

Either way, though, we're lead to similar conclusions as the article, regarding refactoring. If a codebase/system is too large to rewrite in a single project, you have to break the work into incremental steps. Theoretically the only difference between "refactor" and "rewrite" is the scope of the affected code.

As someone who's experienced something very similar, I've built a theory around why it happens:

1. The floating from task to task is almost always avoidant behavior. The experience is usually accompanied by a "slippery" thought -- something you don't want to think about, something that makes you feel sick or causes you stress, and so your thoughts are trying to latch onto something to distract them.

2. One solution is to eliminate distractions, rest calmly in yourself, and practice mindful attention. Meditate. Engage rationally with the slippery thought. Or just observe it, practice letting it happen without interrupting it. Teach yourself: that thought is not to be feared.

3. The long-term solution is to resolve the concerns that your slippery thoughts are related to. For example, In the case of the person you replied to, they mentioned this phrase: "thoughts that center around a perceived lack of meaning in my life." In that case, there might be actual life changes that you can make to introduce a greater sense of meaning. On the other hand, if the underlying thought is "I have a presentation tomorrow," that's a case where you may want to look at reducing your performance anxiety in general. And so forth.

Of course every case is different, but when this happens to you next I'd strongly recommend looking inward to see if there are any of those slippery, "hot potato" thoughts that you're subconsciously trying to avoid. If so -- I suggest addressing that. If not -- well, maybe you've got a dopamine addiction :)

Not a theory per se, but my "lightbulb moment" with jq came when I thought about it like this:

jq is basically a templating language, like Jsonnet or Jinja2. What jq calls a "filter" can also be called a template for the output format.

Like any template, a jq filter will have the same structure as the desired output, but may also include dynamically calculated (interpolated) data, which can be a selection from the input data.

So, at a high level, write your filter to look like your output, with hardcoded data. Then, replace the "dynamic" parts of the output data with selectors over the input.

Don't worry about any of the other features (e.g. conditionals, variables) until you need them to write your "selectors."

YMMV, but that's what's worked for me

Sure! I don't have the GergoPlex keymap on Github yet (still a WIP, that one...) but I used the modal chords concept in my Faunchpad keymap as well. Here's the .def file with "modal chords" in it (the first parameter is the layer aka mode, then the rest are the usual ones.)

https://github.com/luketurner/qmk_firmware/blob/master/keybo...

The forked engine (with very minimal changes) that's used in that keymap is here:

https://github.com/luketurner/qmk_firmware/tree/master/keybo...

The only change is that all the chording macros (PRES, KEYS, etc.) accept a QMK layer number as the first parameter, and will only activate when that layer is active. The end result is similar to the "sticky bits" functionality, but without the side-effect of masking the signal of those bits.

This is my first foray into embedded programming stuff, so I can't promise I didn't do anything dumb in there. It seems to work for me, though!

I recently got a GergoPlex and it's so fun to be able to actually reprogram the keyboard itself.

In fact, I got so addicted to keybindings that I tweaked the chording engine to make chords QMK-layer-dependent. The ability to do "modal chords" is just great.

Anyway, thank you for making these things -- I may never have heard of QMK if it wasn't for your boards!

I think of this as an optimization kind of problem. The word "efficiency" itself is only meaningful in context of what's being made more efficient.

A system could be "more efficient at becoming stable," for example.

But if by "efficiency" we limit ourselves to mean "the time-cost of a set of actions," (as in the most efficient path is the one that takes the least time), we quickly encounter problems with maximizing usage of time and how that conflicts with unexpected work, which leads to the anti-stability you mentioned.

The way I think about it is that a 100% time-efficient process has zero time-flexibility. If you want to gain time-flexibility (e.g. the ability to pivot, or to work on different things too, or to introduce error bars to your calculations), you lose time-efficiency.

Good point, thank you!

It's an interesting thing, because I also take caffeine, and exercise, and meditate. Maybe it's just a matter of degrees, a sliding scale. But "too much of a good thing" isn't unheard of, and I have a strong suspicion that "pleasure control" is one of those things that's tolerable in small doses, but ultimately isn't conducive to survival or satisfaction, especially taken to the extreme of avoiding negative emotions entirely.

That makes sense, thanks. I was definitely thinking in a nearer-term context.

Even in that distant future though, wireheading would be a practice that fundamentally damages the emotional feedback loops that led to that type of society being formed in the first place. (i.e. the feedback loops that cause people in a society to reject agents that want to change or destroy it.)

Without those feedback loops, a perfect utopia would become an unstable equilibrium, because nobody has any reason to prefer that society over any other society. Thus, you could argue that wireheading is long-term incompatible with a perfect utopia.

There is an "out", which is to just have some of the population wirehead, and then have the society be steered by the individuals that don't wirehead, and therefore can make ethical decisions. Alternatively, you could emulate Ian Bank's Culture, and remove decisionmaking power from human hands entirely via automation. But really, even in that world, I'd rather be one of the un-wireheaders who retained their ethical agency, even if it came with suffering. At least, I think I would... although I'm not sure exactly why.

Interesting article. Are there any wireheading proponents in this crowd? I'm curious to understand the phenomenon.

The following quote in the article illustrates what they describe as "Wireheading done right":

"Their primary state of consciousness cycles over a period of 24 hours. Here is their routine: They wake up and experience intense zest for life and work at full capacity making others happy and having fun. Then they go crazy creative in the afternoon, usually spending that time alone or with friends, and explore (and share) strange but always awesome psychedelic-like states of consciousness. Finally, at night they just relax to the max (the healthy and genetically encoded phenomenological equivalent of shooting heroin)."

I can see the appeal of this type of existence. But taking a step back, I question the value in experiencing these states unless they correspond to real events in the world.

For example, focus on "They wake up and experience intense zest for life and work at full capacity making others happy and having fun." This is a perfectly fine sentiment to have. But things should feel better because they're better things to do. Wouldn't a wireheader working in a cheap toxic factory be just as happy as one working in an expensive, safe factory? How might that ultimately impact the factories we design?

With utilitarianism, we attempt to maximize pleasure (very roughly speaking). But part of that is because pleasure has been tied to good events by our built-in wiring. If we have the ability to make any event pleasurable, it feels like we need a new ethical system that employs a full gradient of emotions, including low-valence ones, to appropriately reflect the difference between the desired and the actual reality, and avoid a dystopia where everyone is happy. How does wireheading take this into account?

I don't know. I suppose the simplest thing way to put it is that I don't know who is the target audience.

My feeling is that the people who could use this are, basically, people who are trying to get their first job as a software developer. They don't have connections in the industry, and they're focused on interview prep.

But is that person really going to sign up for what sounds like fairly expensive one-on-one tutoring sessions? Many people in the industry will answer questions for free, if you just send them an email.

On the other hand, is this service for pros who want long-term career growth? If so, you can charge more but you need a much stronger selling point (e.g. mentors who are known experts that people will sign up for your service to talk to.)

Anyway, in either case I'm outside of the target audience because I'm not interested in mentorship as a service, I prefer to build friendships, mentors, and role models in "real life."

edit: removed unnecessary comment

I believe their point is that it doesn't look like the text was written by a native English speaker -- there are spelling and grammatical errors.

For a business, having spelling or grammatical errors is sometimes seen as an early indicator that the business is a scam. There are a variety of reasons for this and it's not necessarily fair.

The practical fix in your case, which I'd strongly recommend if you can, would be to find someone to review the text and fix all grammar, spelling, and formatting issues.

edit:

Also, some of your phrasings could be a turn-off because they hint at information instead of revealing it. (They "play coy.") This behavior is associated with people over-selling, exaggerating, or hiding things.

Examples include:

"Acoto has everything and for everyone."

"We have limited spots and many excited users so don't get left behind."

People have seen excited sentences like this so many times, we're immune to them. In fact they often have the opposite effect. Instead of using excited copy, it's better to focus on your great idea and users will get excited all by themselves.

Interesting, it sounds like I should read the book.

For what it's worth, the "death wish" thing wasn't meant to be pejorative -- maybe I should have used a different term. I like your "life-wish" phrasing better, thank you for that perspective.

IMO (having only watched the film), preparation was meaningless because McCandless had a mentality that led him _toward_ risk -- a kind of death wish. He escalated his personal risk more and more, and eventually suffered the inevitable consequences.

But, I get the impression that in his own head, he didn't feel a choice in the matter, or rather the alternative was worse.

Therein lies the true "moral" of the film, as I personally interpreted it: McCandless was trapped in his own head, no matter how far he traveled he couldn't escape his own mentality. The tragedy is that it seems he himself realized this too late. But, who knows -- personally, I imagine him being at peace with his decision and the ultimate result.

Making plain-text diagrams isn't as hard as you might think, especially using "overwrite mode" (that weird thing that happens when you fat-finger the insert key!)

But many of these tools work by allowing you to express the _intent_ of the diagram without having to draw it out. They're basically markup languages that get "compiled" into diagrams. PlantUML is a good example: http://www.plantuml.com/plantuml/uml/SyfFKj2rKt3CoKnELR1Io4Z.... With these tools, you can make diagrams much, much faster (but usually with less nuanced control over presentation)

I'm in my late 20s, and went through something similar when I left my first job a few years ago. I'm sure that has both positive and negative implications for my advice!

The book "So Good They Can't Ignore You" by Cal Newport was really beneficial for me to build a mental model about career growth.

In short, "career growth" is basically _building an asset_ and then _bartering that asset_ for things you want. So in your case, it's really important to understand two things:

1. What assets (career capital) do you have? e.g. Authority borne of experience, a history of demonstrating excellence (or at least good-enoughness), a good network/references, etc.

2. What do you want to barter those assets for? What kind of job do you want to have, ideally?

As an example, in my case, I felt my "capital" was fairly low -- I was still a junior developer. But, I really wanted to work remotely, and work-life balance is very important to me. So, I willingly accepted a pay cut to work from home. Then by building more capital over time, I've been able to raise my salary back to the original level, and above.

In your case, perhaps you should evaluate whether you have accumulated enough "capital" to "fund" a significant spike in salary, or not. (Chances are, if you've been working at a place for years, you have also made some demonstrable growth. If not, you might want to think about how to grow your responsibility at your current gig.)

I used to live at a fractional address and it was pretty much impossible to represent your address accurately in a lot of systems.

I ended up usually writing it as "200h" instead of "200 1/2".

Worked surprisingly well. One of the advantages of having deliveries still carried out by actual people where the address apparently doesn't have to be an exact match.

I like dependency injection even when I'm not writing tests (which I usually skip for side-projects.)

I find it natural and convenient to think about "What dependencies on other parts of the system does this code have?" Expressing those dependencies explicitly feels like it reduces complexity, not adds it.

But, I'm not talking about pulling in a big fancy DI framework, just making dependencies explicit in your function/class parameters.

I will say that DI is sometimes used as a tool in overly-abstracted systems. An example that comes to mind is the ASP.NET MVC framework -- with DI and inheritance, literally any behavior can be overridden in fairly opaque ways. Trying to suss out the concrete behavior details is like swimming in quicksand. (Or it used to be that way, haven't touched ASP.NET in a while.)

As an aside -- I'm curious about your programming language of choice. I think DI is a lot more useful in some PLs than others. For example, I find JS code often uses imports to create complex graphs of implicit dependencies, and DI can help tame that complexity. But for other PLs like Python or Clojure, I basically don't use DI at all.

Are you referring to the "Sarno method for psychosomatic symptomps" (e.g. https://www.morrisonhealth.com/sarno-method-psychosomatic-sy...)?

This is the first I've heard of such a therapy, it sounds fascinating.

In a well-chosen book, such as the ones in the submitted article, doing the exercises is not to test your memorisation, it's to develop your understanding.

This is a great point and example of the problem with a one-size-fits-all strategy. For some books, exercises are an essential part of comprehension. For others, not so much.

Math is not a spectator sport. Reading about math is fine, but it will not take root and develop unless you engage with it, and the exercises are the way to do that.

My experience is that by taking excellent notes and asking why, you engage with the material to a similar degree, if not a greater degree, than by doing exercises. (Once again, depending on the book, as you mentioned.)

Ignore the exercises if you want, but you almost certainly will end up knowing about the math, but not able to do it.

I would argue that's the point. Usually self-taught math is about self-growth. Getting new ideas, being exposed to new concepts, recognizing patterns. Being able to actually "do it" on-the-spot is beside the point (and is the quickest level of skill to evaporate once you stop focusing on that material, anyway.)

I've tried a few things recently that help with that:

1. Don't do exercises unless you want to. Completionism is a trap.

2. Take notes. Rewrite things in your own words. Imagine you're writing a guide for your past self.

3. Ask questions. Anytime you write something down, pause and ask yourself. Why is this true? How can we be sure? What does it imply? How could this idea be useful?

4. Cross-reference. Don't read linearly. Instead, have multiple textbooks, and "dig deep" into concepts. If you learn about something new (say, linear combinations) -- look them up in two textbooks. Watch a video about them. Read the Wikipedia page. _Then_ write down in your notes what a linear combination is.

Anyway, everyone's different of course, but these practices have been helping me get re-invigorated with self-learning math. Hope they help someone else out there. I welcome any feedback!

(edit: formatting)

Gotcha -- that makes total sense. Thanks!

(P.S. Sorry for putting words in your mouth -- I don't want to imply you said anything you didn't. My bad there.)

I'm very sympathetic to this perspective. If your options are:

1. Stay at unethical job you hate.

2. Get a new job you don't hate.

Well, the answer is pretty obvious. But there is a deeper challenge, which is the choice between:

1. Stay at unethical job you don't hate.

2. Damage/destroy your career and job prospects.

This latter scenario is really a "damned if you do, damned if you don't" situation. It forces you to pick. Would you rather be virtuous (i.e. ethical), or be paid?

You can't just walk away from a decent income because idealism.

Sure you can. You just choose not to -- and (IMO) that's fine.

If this is true, then wouldn't we just be biomechanical robots operating on stimuli

Yes, that's right. Which is one of the big problems with this line of argument for many people -- how do you reconcile "biomechanical robot" with the concepts of "free will" and "moral decision-making"?

I'm personally agnostic on the issue (I don't believe science is able to answer this question yet -- or possibly ever.)

I do think it's interesting that you say "just a biomechanical robot." The "just" implies that being a robot -- a fancy rock -- in some way isn't enough. But in my mind, there's absolutely no (objective) reason to think of a human as any better or more important than a robot, or a rock.

JavaScript Maps are iterated over in insertion order.

It does seem like we've realized that GUIs are not really the most automation-friendly way to interact with programs. But there are a lot of nice macro tools out there still.

For Windows, there is a macro scripting language Autohotkey [0], which has powerful recording GUIs built on it [1]. Although it doesn't support application-specific hooks that I'm aware of, it does allow introspection into the rendered GUI of the application, so you can "click a button" instead of "click a pixel".

OS X has Keyboard Maestro [2], which I've heard is good.

Also, many keyboards have macro recording built in. My Ducky keyboard can record and save macros with no custom software/driver needed. (the macros can even include mouse clicks, but that's a little janky.)

As a final note, I think the place I've seen macro recording still used the most is in gaming. In most other areas of computing, it's seen as preferable to make a special-purpose utility to solve a problem instead of building layers of automation on top of a more general-purpose tool.

(btw, this is just based on my personal experience -- I love automation so I've never been far from the macro-space. I'm not trying to argue against your point.)

[0] https://www.autohotkey.com/

[1] https://www.macrocreator.com/

[2] https://www.keyboardmaestro.com/main/

It speaks to the fact that cancer treatment is almost as scary as cancer itself.

Faced with the choice of poisoning your body to spite your cells, having a chunk of your organs lopped off, or just letting it ride... Hindsight is 20:20, maybe his decision was a mistake, but I have sympathy for Jobs here.