steven2012

Calling external services "microservices" is fundamentally wrong. They are "services". All that will do is create a lot of confusion because you are utterly misusing terminology. You can't just decide to misuse terminology. That's like calling "red" "blue". You don't gain information by misusing well-defined terms, you create confusion and misinformation.

That said, your ideas on distributed systems is wrong. Any point in a workflow can and will fail. You need to account for all of this. You can successfully create an account on Stripe, and then when you bill that account, it could return an error. Or even worse, it can timeout, meaning you don't know whether or not a user was charged.

You have to take into consideration all of these failure situations. There is no atomicity in the way that you expect. Whenever things deviate off the happy path, you fail quickly and decisively so that everyone knows where they stand. That gives people the option to retry or call support.

It's absolutely a basic feature. It's the opposite of buying a share, and your profit/loss is easy to calculate. With options, you need to worry about premium, time decay, spreads and lower liquidity, etc.

For a brokerage managing short position risks are exactly the same as managing long positions. And the implementation is the same too. Do real-time checks and once a position has lost more than X%, sell the position immediately.

The biggest problem presumably for Robinhood is managing the borrowing of the shares. They're probably not large enough to have a pool of shares to consistently borrow from like other larger brokerages.

Yes, a pure short position is much cheaper than buying puts. You pay a lot of premium with options and almost no premium with shorts, depending on what the rate to borrow is. Also, liquidity is much better as are spreads. It makes a huge different to the profitability of a trade.

This is an incorrect statement. CPU utilization and memory matters because it limits how many other containers you can load on the same host, and means that it becomes more and more expensive to run that particular service.

It would never have been prioritized. The time to convince others that this was more valuable than other tasks would have far outweighed the time that he spent working on it on his own time. He thought it was a cool idea and just did it without seeking permission.

It's mostly raw passion. You can't get a 9-to-5 worker excited enough to learn something from scratch over a weekend just to do something she thinks is "cool".

There's also a difference between a better programmer vs more productive. I will never be as productive as the two that I mentioned, but I'm pretty good at programming. I have enough experience to know how to develop a feature and a set of code such that it's easy to read, easy to maintain and doesn't have very many bugs. That's just something I've learned over time. Others may be much more productive than me, but I rarely have to revisit features due to bugs. So there are different measures based on what you want from a team.

Louis CK once said "The only time you should look at what's on some else's plate of food is to check if they have enough." That really put things in perspective to me.

If I'm not making enough for the amount of work that I do, I will find another job.

I've worked with 2 10x engineers in my career. I don't know if they were precisely 10x, but they were the most productive engineers I've ever seen. At the startup I worked at, this was the VP. When he left, the company almost collapsed because he was singlehanded doing so many different jobs that we didn't know about. I would say that was more of a negative than a positive, but just from the sheer amount of work he did, he was definitely more productive than the entire team.

I had another friend who was also extremely productive. He never graduated from college, but he was a programming genius. One day he decided to learn ANTLR. Then he decided to deconstruct our query language for our product into ANTLR and discovered several bugs and inconsistencies in the implementation that made it impossible for ANTLR to parse it. Then I said "Hmm, it would be really cool to use ANTLR to read our XDR files and spit out some code that would implement the migration between versions." He said "great idea!" and accomplished that over a weekend, hand-constructing the grammar by hand. He saved the team probably 1 month of work every release cycle. He was absolutely astounding and the best programmer I ever had the honor of working with.

No offense to the OP but the syllabus is ludicrous. This isn't teaching anything. It's so packed with random software technologies, they will leave the course with nothing. Cut down on the syllabus and focus on a few topics. Make it project based so that you're building on the same project over the 4 days and learning more about programming.

Split the other stuff like git, databases, OOP, functional programming, machine learning my God, for another course. There is no way anyone taking this course will get anything from this, it will just be a confusing mess of information that is quickly forgotten.

Agreed. There is no way that a startup is capitalized enough to survive a payout. Their CEO and investors must be sweating bullets over the next few days, worrying if an earthquake hits closer to LA

Also sinkholes and flooding caused by global warming!