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.
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.
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."
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.)
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.
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."
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.
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.