smiths1999's comments

I apologize if this is a stupid question but why wouldn't everyone be investing in India with these returns being standard? In the US we would assume a conservative rate of 7%

I don't follow. Aren't employee salaries a deductible expense? The above makes me think more along the lines of no longer being able to deduct GPU costs incurred from deep learning research.

I would suggest coming up with a set plan for meals and eat the same thing every day for two out of three meals. For me, during the work week, I have a bowl of oatmeal (steel cut oats, nuts, and a banana) for breakfast, a salad with lots of veggies for lunch, and then dinner varies. Once you get this stable, you can try doing things like occasionally eating once a day (but eating a much larger, _healthy_ meal).

I would absolutely not use a tank of pure oxygen.

This has been my experience as well. The first time I tried it I thought I was going to be miserable all day and have no energy. It ended being totally fine. I have this dull emptiness in my stomach but nothing that affects me in any way. And you are right, as soon as dinner rolls around my hunger increases dramatically.

Zettlekasten is more about making connections between ideas and keeping your ideas organized. The primary use is for generating ideas and writing, not for information retrieval.

The flow is: 1. Read something and take notes 2. Review and distill your notes into key ideas 3. Create cards in your zettelkasten linking these ideas with other ideas already in your zettelkasten

When you are writing and get stuck, refer to the topic in your zettelkasten and follow the flow of ideas.

AWS going down means I've lost it or temporarily lost access to it? Those are two very different scenarios. Of course S3 could lose data - a quick Google search shows it has happened to at least one account. My guess is it is rare enough that it seems like a reasonable decision to not prioritize backing up your S3 data. I'm not syaing "never ever backup S3 data" only that it seems reasonable to argue it's not the most important thing our team should be working on at this moment.

I have my family photos on a RAIDed NAS. It took me years to get that setup simply because there were higher priority things in my life. I never once thought "ahh I don't need backups of our data" I just had more important things to do.

I suppose the caveat is you have to have customers to lose them :) We don't know what the data is or the size of the company.

Sure you can. As the experienced engineer in that setting it is a great opportunity to teach the less experienced engineers. For example, "I have seen data loss on S3 at my last job. If X, Y, or Z happen then we will lose data. Is this data we can lose? And actually, it is pretty easy to replicate - I think we could get this done in a day or two."

It's also possible the response was "That's an excellent point! I think we should put that on the backlog. Since this data is already a backup of our DB data, I think we should focus on getting the feature out rather than replicating to GCP."

Those are two plausible conversations. Instead, what we have is "these arrogant 25 year olds that have 1-2 years of experience and know it all." That's a red flag to me.

Yes - the point of that line was to be ridiculous. Age has nothing to do with it. Anyone at any age can have good ideas and bad ideas. There are some really incredibly _older_ and highly experienced engineers out there. But there are others that think that experience means they are never wrong. Age has nothing to do with this - what is important is your past experience, your understanding of the problem and then context of the problem, and how you work with your team.

And again, my point isn't that you never need backups. My point is that it is entirely plausible that at that point in time backups from S3 weren't a priority.

I'm not sure how you got "backups are for old people" from my post. My point is that there are two sides to this. Perhaps the data being stored on S3 data _was_ backup data and this engineer was proposing replicating the backup data to GCP. That's probably not the highest priority for most companies. Maybe the OP was right and the other engineers were wrong. Who knows.

In my experience, the kind of person that argues about "arrogant 25 year olds that know everything" is the kind of person that only sees their side of a discussion and refuses to understand the whole context. Maybe OP was in the right, maybe they weren't. But the fact that they are focusing on age and making ad hominem attacks is a red flag in my book.

Maybe they are getting tired of arrogant older programmers assuming they cannot possibly be wrong. God forbid a 25 year old might actually have a good idea (and I am far removed from my 20s).

Maybe having S3 redundancy wasn't the most important thing to be tackled? Does your company really need that complexity? Are you so big and such an important service that you cannot possibly risk going down or losing data?

Many people (myself included) that get PhDs simply love learning. Solving problems is important but for some there is this inner drive to need to learn and master everything. It doesn't preclude solving problems, but it's the acquisition of knowledge that is the internal engine, not the desire to solve a specific problem.

In my experience, people that cheat in games like this typically do it to get an edge over everyone else in the lobby. It's not the cheating itself they enjoy but the winning. If everyone in the lobby has the same advantage I doubt they would be content just enjoying the game like the rest of us.

Or they changed their mind (which they are entitled to do).

I disagree. Studying algorithms and data structures is not at all like memorizing integral solution formulas. People who are good at these types of problems generally do the same steps:

1. What is the class of problem I am dealing with? (e.g., solution uses a stack, queue, heap, etc.) 2. What is the likely complexity of the solution?

Knowing, or at least having a guess, to these two questions greatly simplifies the approach. You do the exact same thing with solving integrals (e.g., is this an integration by parts question? is it a substitution question? etc.) and the same for physics, chemistry, etc. With algorithms, once you've done enough and have a very good mental model, you will start making translations between problems. That is, given problem A, you are able to map it to problem B which is easy to solve using some technique you know.

I always thought "serverless" referred to AWS Lambda style services. Recently I saw it used to refer to cloud computing. Is this a common interpretation? It really took me by surprise.

I teach at the university level and this is what I have done with my exams. Everything is open book and in my experience there is no difference in the average exam score between open book online and closed (or open) book in person. It is also way easier for me to not have to worry about who is cheating and where everyone is looking (I also don't like the idea of forcing students to turn on their webcams).

It wasn't clear to me that the other comments were starting from "know how to code," which is why I made my comment. If OP spends time honing their coding abilities then by all means learning more about git is a great plan.

I am really surprised by your comments about git at "regular" companies. If all we are talking about in this chain is understanding workflow and how to rebase, cherry pick, etc. then I completely misunderstood the discussion.

I have certainly gotten myself into some hairy situations. Since I avoid making massive commits, if things get too bad I have always been able to quickly resolve the issue by just doing a clean clone somewhere else and moving my changes over. As a last ditch effort it works quite well and does not take too much time (or stress :) ).

Hmm - that is surprising since I specifically mention I work in industry (and have for quite some time).

It sounds from your post like you may do front-end work. I work primarily on distributed systems for machine learning, so I can't speak to front-end work, but in my experience understanding basic data structures and algorithms is quite useful in day-to-day work. It is great you have gotten to where you are without doing technical interviews. On the other hand, every job interview I have had has had multiple rounds of technical interviews.

And I should also make clear that I am not saying become a competitive programmer or a Leetcode expert. For example, there isn't much value in looking at dynamic programming style problems unless you are interviewing at a top company. But spending 30min to an hour a day on easy to medium level questions will definitely sharpen your reasoning about algorithms and data structures. And like I said, in my experience those are used very often in day to day work (at least on the backend side of things). Also, to clarify, I am not saying you should do this forever.

As an anecdotal example, I recently reviewed a PR that had a lot of complex if-else statements that was dramatically simplified through the use of a set. The updated code was easier to read as well as understand. When I pointed this out, the engineer agreed and understood what was going on. But their initial instinct was to use the one tool they knew: arrays and chains of if-else statements. This is the kind of skill I am getting at - knowing enough about your language, data structures, and algorithms to know when to use the tools in your toolbox.

I don't think it is unreasonable to expect a software engineer to understand the difference between tree-based and hash-based data structures, when you should use arrays, and pros/cons of linked lists, etc. Practicing this kind of stuff, which is very easy to do in Leetcode, is the fastest way to build this intuition (at least in my experience with distributed systems).

Edit: just wanted to add that understanding these things makes it extremely easy to reason about systems like Redis, memcached, Cassandra, Kafka, etc. If you understanding the basic, then you start having these moments of clairty thinking "oh this is just a big hash table!" etc.

Also, meant to add that thee repetition of Leetcode style questions is super valuable in learning the APIs of your language. Things like "how do I create a hash table? how do I populate it? How do I check if it contains a key?" This is all simple stuff but a lot of new grads aren't as familiar with the APIs. It's not a big deal, sure, but it is also an _incredibly_ easy way to stand out.

I'm sure many will come down hard on my comment and disagree. But speaking as someone who teaches at a university and also works in industry and is involved in hiring, I don't think becoming an expert in git is worth your time. At this stage in your career you should spend your time mastering algorithms, data structures, and a compiled language like Java or C++. I would put emphasis on learning how to use your language of choice idiomatically (e.g., iterators, streams, the standard library and its core data structures, etc.). In my experience, the best way to do this is practice Leetcode every day. Doing one question a day (a 30-60min commitment) will put you leagues ahead of your peers. Combine this with reading a major book on your language (e.g., Effective Java or Modern C++ Design, etc.)

Without getting sidetracked about the merits of the technical interview, it is current a fact of life. In my experience most undergrads struggle solving even the most basic problems and even if they come up with a solution, they are unable to code it in any language of their choice. If you are coming out of university as a "git expert" and can't code up a basic solution, you will get passed over every time.

Most teams (at least in my experience) are not struggling to solve git problems (although they certainly pop up). So while you could add some "value" there, overall you aren't adding a whole lot of value. On the other hand, if you know your language and are a moderately competent coder, you can add a lot more value.