Hacker News Reader

Comment by darkwater | Hacker News Reader

I'd really love to be snarky here but I'll try to be polite: all those comments about the example situation are missing the whole point of the post. And it really worries me that there is a good chunk of the tech workers that just ignores the real meaning of something and just nitpick about stupid implementation details. The post is about managing rookie errors, being empathetic and also warn the ageism that pervades the sector. TBH about this last point IDK the situation nowadays in Silicon Valley, but in Europe my limited experience is that ageism is not that bad; kt's actually difficult to find seasoned developers.

Edit: typos

View on HN

I don't buy it. If the only point was managing rookie errors, etc., the blog post shouldn't have been 15~ paragraphs of technical discussion and 2 paragraphs at the bottom of "my point is ..." You can't advocate that people just ignore 80% of the article because they're "not the point of the post."

I'm sure a good chunk of tech workers are worried that when an influential blogger writes something like this a couple hundred developers will Google 3NF and start opening PRs.

It's a narrative. A story. She told it in that way to lure people who get hooked on technical discussion, and then make the point that they probably would have missed or ignored. Without a narrative example, she could have just said "I made mistakes too, live and learn" but she chose to provide an example before presenting the thesis.

And hey, what's so bad about people learning about 3NF? Are you not supposed to know what that is until you're some mythical ninth level DBA?

Sure, I don't mind that the hook, and controversial posts often create the most educational discussion. I only take exception to the idea that we shouldn't debate it because it's "not the point." (specifically for technical advice; being over-pedantic is a thing).

I certainly don't mean to criticize the author or say that they shouldn't have posted the article. If articles needed to be 100% correct then no-one has any business writing them. And it's still open to debate whether the article is even wrong or misleading.

> Are you not supposed to know what that is until you're some mythical ninth level DBA?

I think the world might be a better place if people _did_ wait until they were ninth level DBAs :p

Jokes aside, I have no problem with people learning 3NF. I'm more concerned that people can be too quick to take this sort of rule-of-thumb advice to heart (myself included). And in my opinion, database optimization is too complex to fit well into simple rules like "normalize when your query looks like this." My only 'rules' for high-frequency/critical tables and queries is "test, profile, load test, and take nothing for granted." But I know just enough to know that I don't know enough about SQL databases to intuit performance.

If she told it to lure people who get hooked on technical discussion, then it’s not fair for you to complain about said people analyzing said technical discussion.

But if she told it to show people who get hooked on technical discussion that this often makes them miss a more important point, then they certainly proved her right.

The problem with her point is that it doesn't go anywhere. Mentorship is obviously good and ageism is obviously bad, and she doesn't have specific suggestions on how to solve any of the problems, so the hook is the most substantial thing to talk about.

The reason "the details are important" here are not because of the nitty gritty around what mistakes a "novice" programmer made.

They are important because the present incarnation of the author is making all the wrong diagnoses about the problems with the original implementation, despite doing it with an air of "Yes, younger me was so naive and inexperienced, and present me is savvy and wise".

She explained the problem, the first not working solution and the second working solution as they really happened in 2002 as an example. The real point is the last part of the post. And it was not "how to properly implement an sql based filter for open proxies in your MTA".

I get all that. But 2020 version of this person still does not understand the problem, and she is arguing that she does while oddly self-deprecating the inexperienced version of herself, who arguably had a better solution to begin with.

Yes, I think an alternate design was found that didn't hit as many MySQL limitations as the previous one. This improved performance and was a win. But the post-mortem diagnosis was lacking.

I think she inadvertently made a different point, which is that even experienced developers sometimes misunderstand the problem and make mistakes.

Or an even better argument: you don't need to actually understand the problem to fix it, often you accidentally fix the problem just by using a different approach.

I would argue instead that this comment thread is making the point that people forget that things that work now wouldn't've worked then and design decisions have to be made based on the database engine you're running in production.

MySQL could index strings in 2002. It would have worked fine.

"mysql could index strings" and "using a compound index over four varchar columns would've worked out well" are significantly different propositions.

Yes, we won't know because she didn't try it. And we know she didn't try it because the problem she described is table scans, not "indexed strings are somehow slow in MySQL circa 2002".

Or she did try it and it didn't work - or researched the question and figured, quite reasonably based on my experience of mysql in that era, it probably wouldn't work - and kept the post to only the original problem and the final approach to avoid having even more technical details in a post that wasn't really about those.

I agree that we don't know, but it seems a little unfair to her to treat every unknown as definitely being the most negative of the possibilities.

I really don't understand your general thrust here. MySql certainly had lots of issues in 2003, but being able to support multi-column indexes was not one of them. Her analysis is simply wrong - it is wrong now and was wrong then. Here is the doc from MySql v3.23:

7.4.2 Multiple-Column Indexes MySQL can create composite indexes (that is, indexes on multiple columns). An index may consist of up to 16 columns. For certain data types, you can index a prefix of the column (see Section 7.4.1, “Column Indexes”). A multiple-column index can be considered a sorted array containing values that are created by concatenating the values of the indexed columns. MySQL uses multiple-column indexes in such a way that queries are fast when you specify a known quantity for the first column of the index in a WHERE clause, even if you do not specify values for the other columns

As I said already: "mysql could index strings" and "using a compound index over four varchar columns would've worked out well" are significantly different propositions.

To be more verbose about it - there is an important difference between "can be created" and "will perform sufficiently well on whatever (likely scavenged) hardware was assigned to the internal IT system in question."

I wouldn't be surprised if the "server" for this system was something like a repurposed Pentium 233 desktop with a cheap spinning rust IDE drive in it, and depending on just how badly the spammers were kicking the shit out of the mail system in question that's going to be a fun time.

A composite index is literally just concatenating the fields and then indexing that value. This is not technology that was out of reach of MySQL in 2002 and there is no reason to presume it was so when TFA clearly described the problem as a complete lack of indexes.

They are not significantly different. It just means sorting using more than one column.

you know for performance the new table would've needed a string index aswell?

A single-column string index is a different beast to implement compared to a multi-column varchar index.

I’m happy the hn comments are nitpicking, I’m not particularly well versed in database schemas but while reading it I was going “???????” and it’s good to know I’m not going crazy

Yeah I was confused because the new design looked like an obvious anti-pattern to me, in contrast to adding an index to the original table. And then I was wondering whether I had a completely false understanding of what database normalization means (especially since this is the first time I’d heard of 3NF).

Just because the author was intending to get across a certain point, doesn't mean the implementation details aren't worth discussing too. I don't think many people here would disagree with the central point, so what's there to discuss about it? I think it's uncharitable to assume that everyone talking about the implementation details is "missing the point".

There's probably also some sense of people trying to paint the lesson of "sometimes rookie errors aren't actually errors, and your seniors will tell you you're doing something wrong, when in actuality their solution is worse than what you came up with."

Which I guess is saying the article's setup story makes the exact opposite point that it's trying to?

As a 48 year old who lives in San Diego (so not Silicon Valley but geographically much closer than Europe) and still works as a programmer and who still enjoys coding and continually fights any attempt to put me into any sort of management role...

I think ageism is a valid concern but its also not a black and white issue because while I know quite a few older folks like me that are still constantly keeping up to date I've also known some people my age or just a little bit older who basically stagnated into irrelevance as experts in now discarded technology who never really moved on, so the line between what is ageism and what is people just not bringing value to the table anymore can be a bit blurry.

I'm by no means trying to suggest ageism isn't an issue in tech, I do see echoes of it when I look around and if I suddenly lost the network of people I work with, have worked with in the past, etc, who understand I'm still very technically 'flexible' for an older person I'm pretty sure it would make it difficult to find a job in the practical sense of getting pre-filtered out often just based on the age thing. So my heart really goes out to people who do find themselves in situations where they are capable but can't find work due to age primarily.

But, uh, the issue is somewhat complicated and very case by case, I think.

The real meaning being that people learn and gain experience over time? Is this really something we need to read two pages of text to find out? I think people are justifiably miffed at having read two pages for such a trivial message. Not only that, but these "stupid implementation details" could seriously mislead someone who really is a clueless newbie.

I think you are leaping to conclusions here. It is possible that most people want to keep HN focused on technical conversations and use this as an opportunity to learn something (I certainly do), which is why you are seeing many more comments on the technical aspects.

In this blog post, senior engineer Rachel talks nonsense about normalization and promotes a bafflingly complicated solution as superior to a simple one, without identifying the actual fix, which appears to have happened accidentally.

In other words, with enough empathy and patience, a clueless rookie can grow into a clueless senior engineer!

Rachel usually makes more sense than that. That's why people are nitpicking implementation details.

Hah, pretty accurate and kinda funny, but could be nicer. I still make mistakes.

Meanwhile, Rachel posted an update. Apparently, the whole section about how "the system got reworked" doesn't describe the proper solution, but her own (Rookie Rachel's) attempt to fix it.

And in that context, everything makes sense.

Reply on news.ycombinator.com