I don’t know how to count that low

I always wanted my documents (and particularly equations) to look as nice as the formatting in my textbooks, and it felt like no matter how much finagling I did (which was not an insignificant amount of time being spent), it never looked quite as good.

Also, I never fully knew what copy-paste was actually going to do. Was it going to copy the source formatting? Was it going to adopt the style of where I was pasting? Was it going to do neither and just break everything? I was never sure, so I always ended up pasting into Notepad and then re-copying it to guarantee all the formatting was stripped out.

And sometimes there would be just a vanilla "I pressed a random keystroke by accident, all the formatting broke, and undo doesn't appear to do anything" issues. This might just be gross incompetence on my end (it wouldn't be the first time) but nearly everyone I've described this issue to has experienced similar problems.

Also, I can't remember the details of it, and it's possibly fixed now, but I had issues with the equation editor simply not having all the symbols I needed.

In fairness, I have similar complaints about most of the other WYSIWYG word processors, so I don't mean to pick on MS Word specifically (most of these complaints apply to Pages and LibreOffice as well).

I agree for most people, though I feel like I'm pretty quick with Markdown + Pandoc -> LaTeX.

Definitely agree with the citations stuff though; Pandoc's BibTeX support is generally good, and I've had substantially fewer headaches with it than trying to get the reference stuff in MSWord to work.

Weirdly enough I know someone with a book published by a big programming book company, and they accept manuscripts in Word only.

I've worked in the book publishing industry and I've typeset books both using QuarkXPress (now everybody moved on to InDesign) and LaTeX. Using Word to typeset a book is a major PITA. Nobody in the professional book publishing industry is using Word to typeset books (well, ok, maybe 0.1% of masochists out there).

Word is convenient to quickly edit crappy looking documents: it's a document editor. It's not a typesetting program.

Except that today i literally ran into the problem of Writer crashing whenever an image in the page was resized. There was a table that was spanning multiple pages and my dad was attempting to add pictures to it, along with small text comments below each picture. And, without fail, that particular document crashed whenever you'd use the drag tool to attempt to resize the picture, so that instead of overflowing into a new page, it'd fit within the current one.

Now, i didn't have the time to debug further (Windows 10, Writer 7), but one cannot say that Writer is bulletproof either, even if it's perhaps one of the very few office suites out there that are probably worthy of most people's time and present a usable alternative to the proprietary .docx and other file formats.

Honestly, at this point i'm convinced that Writer is okay for when you absolutely need a more advanced text processor, but for every other sort of note, shorter pieces of writing etc., Markdown is more than enough. Now i mostly just reach for Visual Studio Code, Notepad++ or even just nano when i want to take notes, write some fiction or anything of the sort.

Plus, i can currently combine all of the notes from my driver's ed by simply concatenating the .md files, as well as searching becomes infinitely more easy when compared to binary file formats and such.

Edit: Also, if we're talking about annoying cases of LibreOffice breaking, here's an example of references (bibliography) failing to work when i had to hand in my Master's thesis: https://blog.kronis.dev/everything%20is%20broken/libreoffice... (the tone expresses my frustration at that time)

Maybe true, but Libre Office is not really any better, just free and open source. It's also nowhere near as familiar and well supported, and that's worth a lot.

Since I very rarely type in my native tongue on that computer, and I annoyingly frequently have had to reinstall the OS from scratch, I no longer bother with customizing xmodmap or similar things on that computer.

So the few times when I have to type æ, ø or å on that computer, I just Google aelig, oslash or aring respectively and I go to the Wikipedia article about the letter or some other page from the results that has the letter on it and copy it from there.

Works well enough given how rarely I type any of those letters on that computer.

Video here https://youtu.be/pP2D4DEQBTU?t=146

Great to find characters you don‘t even know the name of.

Is that fair? No, not at all, but that just seems to be how it is.

That really depends on what you mean by "casual users". It's a lot of overhead for someone who isn't familiar with LaTeX already. I've tried showing this to students, and it's a much heavier lift than MS equation editor for limited tasks. Of course for professional typesetting or many complex equations LyX will win, but truly "casual" use it isn't close IMO.

"""

It was a major advance, and in the introduction he proudly claimed that the printing once again looked just as good as the hot type of volume 1.

Except it didn’t.

Reading his introduction to volume 3,1 had the feeling that Knuth was wearing the emperor’s new clothes. Squinting closely at the type in volume 3, I saw the letters had that telltale look of a low-resolution laser printer—not the beautiful, smooth curves of real type or even of a photo typesetter. There were “jaggies”— little bumps that make all the difference between good type and bad. Yet here was Knuth, writing the same letters that I was reading, and claiming that they were beautiful.

“Donnie,” I wanted to say. “What are you talking about? Can’t you see the jaggies?”

But he couldn’t. Donald Knuth’s gray matter, far more powerful than mine, was making him look beyond the actual letters and words to the mathematical concepts that underlay them. Had a good enough laser printer been available, the printing would have been beautiful, so that’s what Knuth saw and I didn’t. This effect of mind over what matters is both a strength and a weakness for those, like Knuth, who would break radical new ground with computers.

Unfortunately for printers, most of the rest of the world sees like me. The tyranny of the normal distribution is that we run the world as though it was populated entirely by Bob Cringelys, completely ignoring the Don Knuths among us.

"""

From Accidental Empires. Which you can get as a book, but he uploaded a scan to his blog here: https://www.cringely.com/2013/02/10/accidental-empires-part-...

I would personally say that it totally depends on what you're trying to do. Most of what corporate types need is done fine with MS Word and like others have said, there's always that "expert" that can get you out of tight spaces. It works well enough for the general public so to speak.

You want something scientific to look the part and not have any of the formatting hassles we all know from Word? Go use LaTex! I wrote both my Bachelor's and Master's thesis in LaTex. Yes, pure TeX is way outdated and even with LaTex you have to look at what the "current" packages are to use for various things (this was 15+ years ago and I have totally never had a reason to use LaTeX again, so I'm not current).

Fun anecdote (at least to me): I did my Master's thesis at a company, so sort of outside of the "scientific environment" where LaTeX would've totally been accepted. The company wanted my thesis as a Word document. I refused. I said I'd give them a Word version as an export afterwards but without any changes to the formatting, no niceties, nothing. Just a plain export, that's it. I was not gonna go through the formatting and editing hell of Word for a thesis, ever! Unlikely hero: my direct 'boss' at the company, who was overseeing the thesis work had written his own thesis like 10 or more years before that in LaTex and he defended me against his boss. Next day he comes to me and proudly tells me he went and grabbed his own Master's thesis from backup, downloaded a current LaTeX and ran it through. Looked as beautiful as ever!

Fitting 1000 short rows in memory is something I'd expect anyone to know off the top of their head just works. It really depends on the specifics of the question and the seniority of the role...

Someone who suggests a complex highly scalable replicated database architecture for a 5MB database is very likely an unsuitable candidate.

Also the interviewer could be looking for whether someone asks the right questions to be able to suggest an appropriate solution, rather than someone who doesn’t ask, jumps to conclusions, and makes poor assumptions.

Once you have worked with one architectinaut that builds baroque solutions, you make sure you don’t employ that kind of person. Anyone can design something complex, it takes talent to simplify everything properly.

Thankfully the author left the name of the company off. I'd hate for half of a secondhand account like this to cause candidates to avoid interviewing at a company!

        And I retrained on smaller numbers and got that job at that start-up.

Edit: I interviewed a year later, wasn't asked about SQL at all, absolutely fumbled my way through some networking questions, and was still hired, so it's clearly very dependent on who's interviewing you and what they ask.

This is one of the biggest obstacles I've encountered when hiring people out of big companies and into smaller startups.

At a very big, very established tech company it's easy to focus on your narrow problem and leverage all of the company's infrastructure to get things done. Moreover, you should be leveraging the company's infrastructure and not reinventing the wheel.

Some (though not all) of these people struggle to adapt when they move to another company where all of that infrastructure isn't available. Maybe they never had a chance to learn how to do it. Or maybe they've just been convinced that their previous company's infrastructure was the only correct way to do something. Either way, they get stuck in a position where they don't know how to solve problems without their previous company's infrastructure.

Best case, they admit the gap in their knowledge and work on filling it as fast as possible.

Worst case, they spend years trying to recreate their previous company's big-company infrastructure before they can get started on this new small-company problem that they've been given.

absolutely not. questions like that give you a baseline for idealized performance. not that you should ever expect to reach it, but it does give a good sanity check for whether or not a technology choice is a sane one.

i've seen cassandra clusters used for datasets that would fit in a sqlite (with indexes!) in a ramdisk on a cheap laptop.

so yes, scale problems go both ways. and to your point, the "difficult" problems aren't harder necessarily, often just those that you (and your team) don't know how to solve.

You know what else is a hard problem? Delivering a quality product on time and in good working order. Not everything has to be at a million user scale for it to be considered a difficult task.

Why's that? If I'm sure the answer is always yes, I can quickly write something to solve a user problem that is way faster and less expensive to run.

So maybe 'broccoli' is their way of saying craziness? Like being on Google drugs. But obviously that's not a perfect fit. Maybe its a misspelling of something else?

In the internally famous Google video, Broccoli Man was the jaded production-savvy SWE/SRE who told the earnest SWE (Panda Woman, I think?) what hoops she needs to jump through to launch her service. Among the most famous lines: her "I just want to serve 5TB of data" to his "I forgot how to count that low".

The video had a huge impact because it was funny and had more than a little bit of truth to it. Lots of Google infrastructure was oriented toward huge problems and required the same heavyweight processes for things that aren't so huge. It inspired a bunch of changes to simplify deploying small (by Google standards) services. Many small things are still difficult at Google, but a bit less so now.

I've only said and heard "I forgot how to count that low" as a reference to this video, making fun of the unexpected difficulty of doing something small rather than actually making fun of someone for wanting to do something small.

I discuss my opinion a bit more in depth upthread https://news.ycombinator.com/item?id=28990879 but we don't actually know what happened, so it's impossible to say.

The candidate that is unable to explain any details about how linux containers actually work, other than to say "I used kubernetes at my last job" is getting picked after the person that actually understands how they work (given that we're hiring for a low-level linux role in this hypothetical :) ).

Or to frame it in a different way, how would you sort an array of numbers? The answer "I'd call array.sort()" isn't wrong per se, but there's an answer the interviewer is looking for and that's not it. If the interviewee furthermore becomes rude and aggressive about it and doesn't even know what time complexity is, that's a pass. (Not remotely suggesting that that's what happened here, but sometimes the biggest interview isn't official - if you're a raging asshole to the person at the reception desk, don't expect to get a callback.)

There was a problem with our license file which meant we got through 5-10 screens of installer and then hit "The SID file you selected is not intended for the order you are deploying because the Tech Support Site Number values do not match. Select a SID file with a matching tech support site number."

And then two weeks later we were finally able to get a correct license file from the IT department. I can't say how much of that was IT's fault or if it really took two weeks to get the fixed license from SAS, but either way I'd be happier to never touch it again.

Pretty old by now, don't know when you started at Google but probably not seen much anymore.

"An order of magnitude" usually refers to 10x. I interpreted it as being 10x off with his guess.

FWIW, you can get 2TB of ram on a single node these days. No need to shard.

I can't help but think he'll fit right in at Google.

We have a lot of stuff that "scales" and would not solve a real problem if it didn't "scale", but there is also an equally good solution not in the domain of the person who was tasked with writing it.

So for example, we were distributing a "large" (~100e6) multi-dimensional lookup table to ~30 servers to do some transformation job. The engineer who did it didn't like to think about data formats, so they used JSON. They didn't like to think about cache friendliness, so it was just maps of maps of maps. They didn't look at the actual dataset contents - which was some mostly opaque-to-us customer catalog SKUs - so didn't notice the massive redundancy in it. Implementing their algorithm as a straight line process, yeah, it did really take several hours to run and it was too long and probably required more memory than we wanted to commit.

But the solution wasn't "farm it out to a Hadoop cluster", it was "translate the dataset into some DFA-like things and then run some optimization passes on them" which yeah, was slow to "compile" - like 2min - but once compiled could chew through the rest of the job in another 10min, with sub-1G memory.

Very big / indirect "everything looks like a nail" situation, combined with lots of people who want to rush for the Big Data / ML / whatever stuff and not fundamentals. And the reasons don't seem to be uniform either. I've seen it from careerists and architecture astronauts, but also bootcamp grads who just weren't properly educated, at startups often early non-technical or technically-adjacent employees trying to help out but don't realize the mess they're making, and sometimes people who just don't want to think very hard.

This is over engineered? Yikes.

I once rewrote an internal tool that used AJAX requests to fetch data asynchronously for "performance"; the asynchronous fetches generally took 1-2 seconds because it had to use a super-slow API. The whole thing was a really weird mess of javascript, perl and Python and each component seemed to be tacked on to work around some issue (usually performance) with the other parts of the system.

My version ended up being a single file of terrible go code (it was my first go project) and a few templates. Everything is rendered server-side and directly does read-only queries to the source database, bypassing the horrendous API.

Of course, not using the API is "wrong" and liable to break at any time, but to this day the database schema has never changed such that that would have required me to rewrite the few bits of SQL I used, and the entire thing is fast enough that all user actions are effectively instant, even though the code is fully synchronous and does several database queries. Turns out databases are fast when you query them directly.

Writing that tool made me realize that I prefer writing "badly" engineered tools optimized to be disposable, so that I can scrap and rewrite them really quickly when I need to. Instead of thinking "what do I do if I need to extend this later?" I try to ask myself "How easily can I delete this code?"

I can better focus my effort on writing code that's reasonably performant and does not fail basic security when I don't really need to worry about whether the architecture is "good" or not, because as soon as I realize that it isn't, the bad part gets deleted and rewritten.

Of course, in larger systems you don't often have the luxury of doing full rewrites, but even then the principle is applicable to individual functions, modules, or whatever subcomponents your system has.