Hi, I'm Asian, graduated from a state school with a humanities degree, worked my way from tech support at a tiny startup into engineering, and now (several jobs later) work as a software eng at Stripe. I've met plenty of other engineers here with non-traditional backgrounds.
I think you're:
1. way too hard on yourself. If you broaden your scope just a bit, you'll see that Amazon is an elite engineering organization.
2. buying way too much into phony credentialism. I don't make a big deal out of it, but personally I consider being able to hold my own engineering-wise while having gone to a state school as a badge of honor.
3. giving way too much headspace to comparing yourself with others in envy. There's always someone better, smarter, etc. I find them around me all the time. I choose to see them as mentors and role models, rather than rivals or competitors.
> I should have done research in high school and I should have gotten at least two first author papers to a top conference in undergrad - instead I got 2 2nd author papers to medium tier conferences because I could never come up with any compelling research ideas. All of my work is ultimately meaningless because it just wasn’t enough - it’s extremely depressing.
I don't think you're ever going to be satisfied if this is your definition of success. You should try to find meaning in the work itself, not in the recognition or status that comes from it.
> when the key bottoms out is probably the best way to go
I disagree. One of the greatest benefits of mechanical keyboards is that they actuate before bottoming out. With some practice you can learn to type without bottoming out, which can greatly increase your typing speed, and decrease the amount of stress on your fingers and wrists.
You've correctly identified a guarantee that you don't have with npm. In practice, anecdotally, I've never run into this issue, while I have many times and with much pain dealt with conflicting deep dependencies using bower and bundler. Which may explain the blank stares. It's a tradeoff I am personally happy to make.
The problem is here: "(accepts a 1.0 object but depends on 2.0)"
This case actually has nothing to do with nested dependencies. Your time zone lib is returning a datum with one type, which you're passing to a formatting lib that expects a datum with another type. This can happen if your libs have dependencies that are totally different libraries instead of the same library with different versions. It can also happen if your libs have no dependencies at all. This is not an issue of dependencies but of you not understanding your libs' APIs.
I think I just mean that a testable unit is a good heuristic for when a piece of code should be pulled out into a separate module. Put another way: when there's enough functionality/complexity in a given function that it needs to be tested independent of the public methods that use it, it's modularizable.
This probably isn't categorically true, but it's served me pretty well.
If you really want to buy into the module pattern, it seems like anything that's enough of a unit that you'd want to test could be in its own module.
In the example given, the sum function could be its own module that you require into the stats module. That way you could test them independently, and the stats module could simply expose its own appropriate methods.
This has the added benefit of making the sum function reusable.
Personally I prefer this approach to introducing environmental concerns into your code.
Note that this trick should only be used
for arrays which you know do not contain
"falsy" values (arrays of objects or DOM
nodes for example). If you are iterating
over numeric data that might include a 0
or string data that might include the
empty string you should use the i, len
idiom instead.
I would agree with you if all the carriers offered transparent plans that charge you just the monthly plan amount without the phone subsidy if you bring your own phone. Only T-Mobile does at the moment. As it is, I can bring my own unlocked phone, but I'll still get charged the subsidy.
I think you're: 1. way too hard on yourself. If you broaden your scope just a bit, you'll see that Amazon is an elite engineering organization. 2. buying way too much into phony credentialism. I don't make a big deal out of it, but personally I consider being able to hold my own engineering-wise while having gone to a state school as a badge of honor. 3. giving way too much headspace to comparing yourself with others in envy. There's always someone better, smarter, etc. I find them around me all the time. I choose to see them as mentors and role models, rather than rivals or competitors.
> I should have done research in high school and I should have gotten at least two first author papers to a top conference in undergrad - instead I got 2 2nd author papers to medium tier conferences because I could never come up with any compelling research ideas. All of my work is ultimately meaningless because it just wasn’t enough - it’s extremely depressing.
I don't think you're ever going to be satisfied if this is your definition of success. You should try to find meaning in the work itself, not in the recognition or status that comes from it.
Good luck!