42 karma · joined March 24, 2010
A large company in actual financial distress will sell off a division.
1. You have given up on any sort of consistency. 2. The database implementation will never be able to optimize a lookup workload which is pretty close to pessimal. Not caring about 99% is only viable if can actually avoid the other 1%.
One motivation for creating documents is that modeling document contents as relations requires the creation of a bunch of primary keys which no natural definition. A simple document might be an ordered collection of paragraphs, [p23, p57, ...]
Modifying such things is difficult. In fact, the most effective way of structuring modification seems to be OTs based on document offsets. What Google docs does.
IMO specializing in any particular bit of trendy tech. is a recipe for disaster. Trends come and go. First-principles CS and being able to communicate it continues to be extremely valuable and satisfying.
When joining a startup you are a minority investor. The value of your options depends 100% on the integrity of the majority investors.
Batch data processing is very well understood, cheap and getting cheaper every year. So, if you can afford to boil the ocean every night, DD is a tough sell.
The addressable market, customers with problems which can only be solved with DD (instantaneous exactly correct answers) is probably small right now.
As a statistic, reading is only significant in the past 200 years or so. Given that there was a similar kerfuffle a couple thousand years ago when we shifted from memorizing to writing things down, I doubt that this is too significant.
Literacy is also shifting. Growing up with memes and Instagram and Tiktok has produced a generation that is vastly more literate in design, photography and film.
There are a lot of people operating on that plan. Mostly it doesn't work out for them.
Play this forward ten years with a family to support and a mortgage which committed you to personal inflation and a track record of ...? You can absolutely fool people for a week or a year, but a decade of non-experience will stick out like a sore thumb. Experience compounds, and the one you describe is compounding down. Do this for ten years and you will be much less accomplished than you could be.
If you want practical guidance, my best is to avoid all of the concurrency constructs that are taught in schools. Use log-structured single-writer multiple reader, wait-free, processes and shared memory.
Structure and Interpretation of Computer Programs is still the best single book on computer programming: the most important concepts (closures, continuations, macros, transformations,...) for the least expense in complexity.
To what you learn from SICP, rust and C++, add just one thing: how to exploit a physical stack efficiently. Scheme->C++/rust will be easy. C++/rust->Scheme can still be quite difficult depending on how distracted you got by the complexity.
As a practical matter, most system software is written in C. Being able to read the Unix kernel has been valuable for nearly 40 years. You'd be surprised what one can accomplish with just functional decomposition.
https://engineering.linkedin.com/blog/2020/liquid-the-soul-o...
https://engineering.linkedin.com/blog/2020/liquid--the-soul-...
"Technical surplus" is your ability to learn and implement that learning as code.
The "bullshit" part is complaining about debt while not being able to run a surplus.
https://ourworldindata.org/coronavirus-data-explorer?zoomToS...
Log as if your life depended on being able to debug a single occurrence. If this causes a lot of output, you probably need to add more assertions to the code.
Rewrites: Firefox, IE, Word, Windows, MacOS, ...
Many of these have been rewritten multiple times and they are all orders of magnitude more complex than some random million-line hunk of perl.
Rewriting is hard and may absolutely or just take a long time, but failure to rewrite is pretty much guaranteed to fail.
Choose your employer carefully because the treatment you will receive is a pure test of professional ethics: how someone with power treats someone without.
But regardless of what NASA did or did not find, there were real accidents involving throttles which were stuck open for minutes at a time with the engine completely overpowering the brakes. Recall that in the 100mph LA crash which set off the investigation the brakes were completely destroyed.
That is a real design flaw, an error of commission by Toyota. Other cars, for example VWs, have a brake override and the drivers manual documents an accelerator "double-tap" protocol for giving the accelerator priority, say when starting on a steep hill.
Furthermore, in the week after the recall, the president of Toyota announced that Toyota throttle systems would henceforth include a brake override. Here's their official press release making good on that promise:
http://pressroom.toyota.com/pr/tms/toyota-extends-brake-over...
So I can't develop too much sympathy for Toyota. They made a basic design mistake in a safety critical system, and then refused to acknowledge the problem. That mistake and their mishandling of it cost them a ton of money and that is exactly as it should be.
systems programming, C, ml, python