jdsalaro

> Things like road surfaces that don't need to be replaced every couple of years,

I remembered this article where they discuss self-healing materials for use in road construction: https://www.theverge.com/2017/5/4/15544156/potholes-self-hea...

I'm torn about your comment.

In principle, I agree with the fact that studying failures teaches one more, whether more is better when it comes to learning stands to be discussed, however.

What I mean by this is that, although you may profit from your parents sharing a plethora of don't-dos such as avoiding drugs, staying away from toxic relationships, not dwelling on your insecurities, et cetera, having regular abstract conversations about how "thinking deeply about my predicament, my objectives and how to reach them despite the former" might be much more useful to you.

In short, the first approach teaches you, potentially, numerous, isolated lessons about specific circumstances you will likely never face. Yes, you certainly learned more things, but whether those things will be useful to you, particularly, is unclear and only time can tell.

If you and your parents, however, have a thorough discussion about what allowed them to lead a happy life, as in the second scenario, both pushing and pulling, trying to discover what it really was and looking to find consensus regarding attitudes, processes, ideas, roadblocks, etc, you might learn a framework what will be useful forever, regardless of the concrete circumstances you are faced with.

Nevertheless, this comment of yours is spot on:

> people who succeed rarely have much luck identifying which selection of choices got them there.

Therefore, I really emphasize that not only the mentor should share the reasons and methods behind their success, the listener must be able to understand why and whether they were as useful as the mentor portrays them.

I agree, partially, I'm adamant about the fact that it's even more important to talk about successes, than failures.

"Vicarious learning from the experiences of others saves making errors yourself, but I regard the study of successes as being basically more important than the studyof failures. As I will several times say, there are so many ways of being wrong and so few of being right, studying successes is more efficient, and furthermore when your turn comes you will know how to succeed rather than how to fail!"

~ The art of doing science and engineering

You might find this study interesting:

"Researchers identify a new personality construct that describes the tendency to see oneself as a victim"

https://www.psypost.org/2020/12/researchers-identify-a-new-p...

> Rationalist circles make just as many horrific logical errors. If you want to dig into this stuff philosophy has dug deep, and frankly all they came up with is all sources should be treated as suspect.

Sharing some anecdata, because I enjoy when others do.

I've got some very dear friends born in a highly prescriptive culture where credential-ism runs deep, being an intellectual is extremely valued -people are often denied leases due to their non-academic status- and authority figures and strangers get the "Mrs." and "Mr." treatment for years after you've met them. Early on in our friendship we would discuss and rant about everything and anything. We would often talk about my attitude of trusting no one and how I believe there are, truly, no experts, in the colloquial sense of the word. We've often had late-night discussions about my "stubborn and deeply misguided attitude", about how it's wrong that the only experts I trust are those who deeply distrust their own abilities, instincts and continuously attempt to disprove their own claims.

Shockingly, they defended the aforementioned views until many of their countries top virologists and they themselves, often and loudly, shared their opinion on covid-19 around March, April and May: covid-19 was nothing special, national mortality trends were unaffected, their country is rich and they had a high number of ICUs, it was basically just like the flu and nothing to worry about. Then, as we all know, shit hit the fan and we saw cooling trucks being turned into mortuary vehicles. I simply told them what I've always told them, and for the first time since we're friends they nodded with some sadness in their demeanour: trust no one, acquire evidence, make your own judgments, try to find hidden risks and the only so-called experts worth trusting are the ones who, in their own words, publicly and candidly express their skepticism towards their very own claims and try to help you reproduce their methods and conclusions.

I love contributions like yours and pmontra's, I really do. It's a huge hobby of mine to find, read about, correlate, compare, distill and share similar, and at times not so similar, concepts from different industries, disciplines and ages.

I really don't know why it's so, so, satisfying to me. Probably I am on the more extreme end of the spectrum, as I assume most HN readers are, of the dopamine-driven reward of information, which brings me to the link and quite I wanted to share ;)

https://www.frontiersin.org/articles/10.3389/fnhum.2013.0076...

> The general function of dopamine is to promote exploration, by facilitating engagement with cues of specific reward (value) and cues of the reward value of information (salience). This theory constitutes an extension of the entropy model of uncertainty (EMU; Hirsh et al., 2012), enabling EMU to account for the fact that uncertainty is an innate incentive reward as well as an innate threat.

This is a wonderful movie and one anyone interested in the stories and fate of Assange, Manning and Snowden will appreciate.

> The entire reason for crypto is the already ridiculous level of control exerted over various gatekeepers. How do I know? I am part of the system.

Can you elaborate on the "ridiculous level of control over various gate-keepers"?

Can you elaborate on your approach to "abstract away the serverless interface and create a test harness that can test the business logic"?

I still don't get how and in whose favor this plays.

> If you managed to finish the app, you weren't very depressed.

I disagree, as someone with experience in the matter. I think is fine to question whether OP's depression was a real major depressive episode or to what extent they were really depressed. However, the succinctness of your comment leads me to believe that it's more simplistic than anything and thus counterproductive while discussing depression. It's not always a matter of "but was it real depression, though?"

> Depression acts primarily on willpower.

Depression acts on everything and shouldn't be characterized so easily. That's exactly what happens in real life, where a statement like yours can instantly nullify the efforts of someone trying to tell you that, yes, they look normal, but something is wrong. To that, you'd likely reply, "but Jane, you don't look that depressed!"

Some people are able to keep operating on certain realms, which IMHO is the key to getting out of the rut; grasping whatever still motivates you, even if just a bit, to operate at 1% of your normal capacity and "power" on.

> The bad feelings come as a consequence of not being able to get anything done.

I repeat, not always and not for everyone as the causes for circumstantial and clinical depression are too many to count and so are the symptoms and the way they are externalized.

This article gave me a fair bit of nostalgic feelings. So much so, that I had to go and dig out one of my first university assignments from seven years ago[!], writing a simple Linux Shell, where I actually had to use "decision tables". In my case I remember thinking about using an automata for a grammar to prevent my code from becoming an unmaintainable, unexplainable, SEGFAULT-y mess.

Most important of all, I remember the lecture assistant telling us that we "won't pass the assignment as long as I can bring your program to SEGFAULT."

Many of us struggled, SEGFAULT after SEGFAULT, with uneven quotes, pipes inside or outside quotes, double bars, double ampersands, etc. As the days progressed, many code-bases became more complex and more fragile as we tried to deal with the pesky inputs of the lecture assistant. When our turn came up, we all grinned while the lecture assistant tried in frustration to bring our shell to SEGFAULT. I remember pointing out "those inputs are not supported by the grammar, and walking him through the bits I list below". Those were the days, oh man :)

---

  struct listNode {
   char *token;
   int type;
   struct listNode *next;
  };
  
  ...
  
  #define M_BEGIN  0
  #define T_WORD   1
  #define T_QUOTE  2
  #define T_BAR    3
  #define T_AMP    4
  #define T_NL     5
  
  ...
  
  int validateInput(struct listNode * head) {
  
   unsigned char smpshGrammar[6][6] = {
           {0,1,0,0,0,1},  // M_BEGIN
           {0,1,1,1,1,1},  // T_WORD
           {0,1,1,1,1,1},  // T_QUOTE
           {0,1,0,0,0,0},  // T_BAR
           {0,0,0,0,0,1},  // T_AMP
           {0,0,0,0,0,0}}; // T_NL
  
   struct listNode * iterator = head;
   int validInput = 1;
   int previousState = 0;
  
   while(iterator && validInput){
   
   if(DEBUG) printf(" Debug Information > Validating transition from Q%d to Q%d ... Possible:%d\n",
      previousState,
      iterator->type,
      smpshGrammar[previousState][iterator->type]);
  
   if(smpshGrammar[previousState][iterator->type])
   { 
  previousState = iterator->type;
    iterator = iterator->next;
   }
   else { validInput = 0; }
  
   }
  
   if(previousState!=5){ validInput = 0; }
  
   return validInput;
  }

> Ordinary people with the right tools built into their devices will be able to see very easily "Is it in the chain?" based on a simple enquiry to the ledger, and if the answer is no, then it's untrustworthy.

Not that I disagree, but the first thing that came to mind when I read this part of your comment was that this approach reinforces the Monopoly of governments and media companies on the flow of information. On the one hand it's great that we could protect in this way from unverified, "not-in-the-chain" messages, but on the other hand being a contrarian, producing and coming into contact with information outside of the chain, not necessarily really fake videos, but other types of information is crucial to social evolution and civil discourse.

The "public" and "distributed" would be major priorities of mine in the scenario you describe.

Lose your crypto-material, though, and you're really in trouble. At least in the past and in the near future "losing" our faces isn't a concern and "using" faces to prove our identity and verify each other's comes naturally. Not so much with crypto.

There's another benefit to having a decision journal, even if you do it alone and not as a team or company-wide effort: it reduces the time you have to waste fighting misinformation.

Companies bigger than a typical seed-stage startup usually come with an added level of bureaucracy. Products, tools, documents and others are usually created or pushed forward by different teams as a cross-functional effort. If you are the leader of such a project, the creator of a tool, methodology or document used by others, you will be expected to keep everyone in the gallaxy up-to-date with the details. Failing to do this will lead to certain personalities giving you a hard time. Suddenly people may start questioning your decisions in calls, emails and threads. You'll start wondering where all this skepticism comes from and will be forced to repeat yourself over and over again wasting valuable time. "Yes we did test whether to use X or Y architectures", "yes, we did test and consider this tool but it lacks feature Z".

I'm likely not alone in considering the above a less than ideal situation to be in. Having a well organized and detailed decision journal allows you to stop the noise almost completely. Also, as others mentioned, it gives your thought process structure, keeps you honest, committed and makes evolving a deliverable overtime easier.

I did the same but with JabRef, it's a great and simple piece of battle tested software. Highly recommend it.

With respect to preparing one's own obituary in advance the following quote came to mind:

"In journalism, we recognize a kind of hierarchy of fame among the famous. We measure it in two ways: by the length of an obituary and by how far in advance it is prepared. Presidents, former presidents, and certain heads of state are at the top of the chain."

- Walter Cronkite Quotes

American - Journalist November 4, 1916 - July 17, 2009

> What is the value of having(hosting my own data) if I cannot move.

The value of having your own data is, precisely, that you have your own data; nothing more and no less.

Furthermore, and although I'm no expert in Solid's and other implementations, it's quite likely that you, or other technologists, can more easily help you achieve the interoperability you so desire if your data is not locked away behind thousand APIs and rate-limits; after all you do have your data in your pod. Think of Instagram, what if all your data was stored locally? Even if it was stored in a really messy JSON schema or whatever you can think of; it's still trivial to massage that data to import it into Wikimedia, or iterate through it and send it in batches to your email, or remove it, etc.

I'm not sure how solid plans to keep applications from stealthily generating derivatives of the data they manipulate. I can imagine some sort of separation would have to happen at the browser level where the "app" provides a scaffold and the browser replaces in your data.

At GitLab we have a very flexible PTO policy and although I've never heard of a colleague being forced to take time off, we do have a couple of stern remarks codified in our handbook and constantly remind each other to do so:

> We don't frown on people taking time off, but rather encourage people to take care of themselves and others by having some time away. If you notice that your co-worker is working long hours over a sustained period, you may want to let them know about the time off policy.

> Not taking vacation is viewed as a weakness and people shouldn't boast about it. It is viewed as a lack of humility about your role, not fostering collaboration in training others in your job, and not being able to document and explain your work. You are doing the company a disservice by being a single point of failure. The company must be able to go for long periods without you. We don't want to lose you permanently by you burning yourself out by not taking regular vacations.

https://about.gitlab.com/handbook/paid-time-off/

Thanks for this comment, it puts into words some ideas I've been considering in a very concise manner. Also, the replies are quite interesting.

Software for VJing, mapping images, light beams, etc to projectors, surfaces or screens.

Wouldn't creating a plugin for the likes of VLC or contributing directly to OpenShot be a better idea?

I work all-remote at GitLab as an Engineer and interviewed for other remote positions before deciding to come onboard, so I believe I'm qualified to answer this question.

Yes, those remote positions and compensations are most likely real.

Companies go/explore/allow all-remote in order to profit, usually in three ways:

- by getting access to talent pools otherwise not available to them due to geographical constraints.

- by getting access to talent pools and markets where they may get a similar output/value for a similar or even lower salary to that expected in the markets where they have a physical presence.

- by being active in the conversation about remote work and the future of the workplace and wherever those conversations happen.

So, even if your salary at one of this companies is 8 times your local rate, if you're good it'll most likely be worth it to them. Especially since:

- if they hired someone in NYC, Amsterdam, Tel Aviv or SF they'd be paying much more.

- they most likely don't need or want "a rockstar", whatever that is.

- they've interviewed you and have verified, to a certain extent, that you can perform well and can get you to comply with their standards, their expectations and needs; different as with an overseas contractor/outsourcing agency.

If your profile is impeccable and it screams "this person is a potential amazing hire", I'd suggest you aim for being compensated on the value you provide at the highest possible market rate the company you're interviewing with has access to.

If you're a good professional in a not-so-great job market in a developing country aiming to break the ice with remote work and big/interesting tech players, I'd suggest you aim for at least 1.5 your possible local compensation.

As someone pointed out in another comment, you can use GitLab's salary calculator to benchmark your country of residence and you job family in different scenarios.

https://about.gitlab.com/handbook/people-group/global-compen...

https://about.gitlab.com/handbook/people-group/global-compen...

If I would have more than one up-vote to give you, I definitely would.

Although I have less professional experience than you, around 6 years combined in software development and information security, I've also come to appreciate people who find the right balance of taking what they do seriously without being uptight about it.

Which brings me to a trait that almost always puts a dent on my respect for anyone regardless of seniority: not asking enough questions and being quick to make statements.

I loathe this so much that I've turned the opposite into my work mantra: "no statements until there've been enough questions".

IMHO, this "small" tweak changes one's interactions and their outcomes with other co-workers for the better.

This deck is very interesting, assuming the data it's based on is legitimate. I didn't expect that to be the extent to which they outperform their competitors.