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%
The 12% returns are not adjusted for inflation or depreciation. Historically, India had a much higher rate of inflation than the US. And the rupee has continuously lost value against the dollar.
US 10 year treasury yields are ~4% while Indian treasury yields are ~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.
IIUC, whereas previously companies could deduct salaries in year Y from revenue in that same year Y, now section 174 allows deduction of only 1/5 of those salaries in each of the 5 years [Y,Y+1,Y+2,Y+3,Y+4].
After 5 years of this law being in effect, will the numbers balance back out to pre section 174? That is, does that deduction from year Y carry over into year Y+1, Y+2, etc.?
I mean, this probably still matters a lot for startups given their shorter lifetimes, but it seems any large company(I'm thinking of, e.g. Apple, who has plenty of cash on hand) that's been around for a while could just wait it out? I am not familiar with corporate tax law and how deals are structured, but could you also defer revenue in the same way to offset(e.g. customers with a 5 year contract paying progressively more but keeping the same total $ amount to sync with your deductions)?
This is for specific R&D costs, like doing something patentable. Most developers are not doing R&D.
Most developers are fixing bugs, helping sales, keeping systems online, keeping up to date on patches, performing security scans, complying to some internal policies.
> (3)Software development
For purposes of this section, any amount paid or incurred in connection with the development of any software shall be treated as a research or experimental expenditure.
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).
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.
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?
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.
I’ve most definitely been in numerous places where arrogant 25 year olds with CS degrees but not smart enough to make it to FAAnG think they know what they are talking about when they don’t. Not every 25yo is an idiot, but many especially in tech think they are smarter than they are because they’re paid these obscene amounts of money.
But that's just it; you can't even have that discussion if the response to "hey, should we be backing up beyond S3 redundancy?" is "No. Why would we? S3 is infallible"
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.
>"Maybe they are getting tired of arrogant older programmers..."
And this is of course valid reason to ignore basic data preservation approaches.
Myself I am an old fart and I realize that I am too independent / cautious. But I see way too many young programmers who just read sales pitch and honestly believe that once data is on Amazon/Azure/Google it is automatically safe, their apps are automatically scalable, etc. etc.
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.
Would you put the one and only copy of your family photo album up on AWS, where AWS going down would mean losing it? Because your customers' data is more important than that
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.
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.
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.
