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.

Comments URL: https://news.ycombinator.com/item?id=24509588

Points: 1

# Comments: 0

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.