9 ms·

The ending is the most important part. > Now, what do you suppose happened to that clueless programmer who didn't know anything about foreign key relationships

by welder 5y ago

The ending is the most important part. > Now, what do you suppose happened to that clueless programmer who didn't know anything about foreign key relationships? > Well, that's easy. She just wrote this post for you. That's right, I was that clueless newbie who came up with a completely ridiculous abuse of a SQL database that was slow, bloated, and obviously wrong at a glance to anyone who had a clue. > My point is: EVERYONE goes through this, particularly if operating in a vacuum with no mentorship, guidance, or reference points. Considering that we as an industry tend to chase off anyone who makes it to the age of 35, is it any surprise that we have a giant flock of people roaming around trying anything that'll work?

Aeolun 5y ago
> My point is: EVERYONE goes through this A lot of the basic issues beginners go through can be mitigated by paying attention in class (and/or having formal education in the first place). I’ll grant that there are other, similar, things that everyone will go through though. My own was manually writing an ‘implode’ function in Javascript because I didn’t know ‘join’ existed.
carapace 5y ago
(It seems a lot of folks are getting nerd-sniped by the set-up and missing the moral of the story, eh?) I don't know the actual numbers, but it's been pointed out that at any given time something like half of all programmers have been doing it less than five years, for decades now. That, plus the strident ignorance of past art and practice, seem to me to bring on a lot of issues.
- twic 5y ago
  I don't think it's purely nerd-sniping. If your story is "at first you are bad, but then you get good", but your example is of a case where you did something fine but then replaced it with something worse, that rather undermines the story.
  - emilsedgh 5y ago
    > but your example is of a case where you did something fine but then replaced it with something worse They way I see it is that it was a case of something that wasn't working, then replaced with something that was working. I don't know what your metrics about "good" or "bad" are but eventually they got a solution that covered their use cases and the solution was good enough for stakeholders and that is "good".
  - adolph 5y ago
    Chronology alone only progresses; progress sometimes regresses.
  - mwcampbell 5y ago
    If even someone with Rachel's level of experience still doesn't know all the minutiae of database optimization, I think that just amplifies her point about the importance of mentoring novices.
    - duxup 5y ago
      I recall reading a rant on another site about someone so upset they had to deal with clueless noobs at work. They then went on to list the errors that this brand new entry level employee had made when writing ... an authentication system ... I was more than a little shocked when I realized they were serious and hadn't realized the issue was sending the new entry level guy to do that job alone.
      - gonzo41 5y ago
        I would expect most seniors to want a set of eyes across their work doing any form of authk or z. If only to share blame :p
        thaumasiotes 5y ago
        > authk I've always seen authn. Where'd you pick this usage up?
- beering 5y ago
  > (It seems a lot of folks are getting nerd-sniped by the set-up and missing the moral of the story, eh?) The narrative should lead to the conclusion. If I told you the story of the tortoise and the hare in which the hare gets shot by a hunter, then said the moral is "perseverance wins", you'd be rightfully confused.
- deleted 5y ago
  [deleted]
- lamontcg 5y ago
  > It seems a lot of folks are getting nerd-sniped that is an excellent term.
  - jacobolus 5y ago
    Origin: https://xkcd.com/356/ https://xkcd.com/356/
    - wwweston 5y ago
      Old enough some people under 35 may not have encountered it… ;)
      - egeozcan 5y ago
        I feel like that phrase has been there forever, and I'm exactly 35. Will this happen more often as I grow older? Ugh. Feels weird. Maybe also a bit depressing.
        lamontcg 5y ago
        It was weird seeing all the spongebob squarepants memes take over the internet when I was too old to ever grow up with that. I turned 28 in 1999 when that first aired. That was my "holy shit I'm so old" moment when that finally trickled up into my awareness as someone nearly turning 40 or so.
        yesenadam 5y ago
        Same age as you. I have a lot of friends in the Philippines. I swear the Facebook employment info of half the people in the Philippines says they work at the Krusty Krab. (And for most filipinos, the internet = facebook.) For some reason I never asked what that meant, and for many years I thought that was just some odd joke, and was vaguely puzzled about how widespread it is. Eventually I happened on the Spongebob connection!
        _carbyau_ 5y ago
- WorldMaker 5y ago
  The math would resemble xkcd's Lucky Ten Thousand: https://xkcd.com/1053/ https://xkcd.com/1053/ With yes the added confounding factors of how often our industry seems to prefer to hire youth over experience, and subsequently how often experience "drains" to other fields/management roles/"dark matter".
crispyambulance 5y ago
Yep. Folks are getting lost in the weeds discussing indexing of database tables. That's _totally_ beside the point here. The thing is, the first implementation was a perfectly fine "straight line" approach to solve the problem at hand. One table, a few columns, computers are pretty fast at searching for stuff... why not? In many scenarios, one would never see a problem with that schema. Unfortunately, "operating in a vacuum with no mentorship, guidance, or reference points", is normal for many folks. She's talking about the trenches of SV, it's even worse outside of that where the only help you might get is smug smackdowns on stackoverflow (or worse, the DBA stackexchange) for daring to ask about such a "basic problem".
- otterley 5y ago
  I’d be a lot more sympathetic if the major RDMSes didn’t have outstanding and thorough reference manuals or that there weren’t a mountain of books on the subject that cover, among other things, the topic of indexing and its importance. MySQL’s manual, for example, has covered this subject from the very beginning: https://dev.mysql.com/doc/refman/5.6/en/mysql-indexes.html https://dev.mysql.com/doc/refman/5.6/en/mysql-indexes.html (I don’t have the 3.x manuals handy but it was there back then too). It’s not clear from the article whether the author spent any time studying the problem before implementing it. If she failed to do so, it is both problematic and way more common than it ought to be. “Ready, fire, aim” But you know what they say: good judgment comes from experiences and experience comes from bad judgment. Compounding the problem here is that the author now has much more experience and in a reflective blog post, still got the wrong answer. IMO the better lesson to take away here would have been to take the time getting to know the technology before putting it into production instead of jumping head first into it. That would be bar raising advice. The current advice doesn’t advise caution; instead it perpetuates the status quo and gives “feel good” advice.
  - dasil003 5y ago
    I couldn't disagree more with this comment. No amount of reading documentation teaches you how to build production systems. You progress much faster by getting your hands dirty, making mistakes, and learning from them. The challenge of writing good software is not about knowing and focusing on the perfection every gory detail, it's about developing the judgement to focus on the details that actually matter. Junior engineers who follow your advice will be scared to make mistakes and their development will languish compared to those who dive in and learn from their mistakes. As one gains experience it's easy to become arrogant and dismissive of mistakes that junior engineers make, but this can be extremely poisonous to their development.
deathanatos 5y ago
… I appreciate her sentiment at the end there that we should try to change the status quo (which I think does suck), but I'm not sure how much power the average employee has over it. Most employers I've worked at seem loathe to retain anyone past about 2 years. (E.g., currently I'm in the 95'th percentile, after just over 2 years.) IME it takes about 6 months to really learn how a company's systems work to where to proficiency (yes, six months.) which means we're spending ~25% of the time "training", where "training" is usually someone trying something crazy and failing, and getting corrected as opposed to some structured form of learning. Oftentimes the systems that these engineers are stumbling I think are the internal ones; they need more features, or refactoring to account for organic growth, but since they're not shiny new customer facing features they'll get exactly 0 priority from PMs. The engineers who build experience working with these systems and actually know what needs to change and how without breaking the existing use cases … are about to leave the company, since nobody is retained beyond ~2 years. I also find my own team is usually strapped for resources, normally, people. (Usually politely phrased as "time".) Yes, one has to be wary of mythical man-month'ing it, but like my at my last employ we had essentially 2 of us on a project that could have easily used at least one, if not two more people. Repeat across every project and that employer was understaffed by 50-100%, essentially. Some company just went for S-1, and they were bleeding cash. But they weren't bleeding it into new ventures: they were bleeding it into marketing. Sure, that might win you one or two customers, but I think you'd make much stronger gains with new products, or less buggy products that don't drive the existing customers away. Also there's an obsession with "NIT" — not invented there — that really ties my hands as an engineer. Like, everything has to be out sourced to some cloud vendor provider whose product only fits some of the needs and barely, and whose "support" department appears to be unaware of what a computer is. I'm a SWE, let me do my thing, once in a while? (Yes, where there's a good fit for an external product, yes, by all means. But these days my job is 100% support tickets, and like 3% actual engineering.)
unclebucknasty 5y ago
What's funny is there seems to be a lot of debate among grizzled veterans here about whether her old solution is actually better than the new. We're getting into index types, engine implementations, normal forms, etc. And really, this is a relatively simple development problem that I can easily imagine on an interview test. Now, imagine a new engineer, just getting started trying to make sense of it all, yet being met with harsh criticism and impatience. Maybe that was exactly her point--to get everyone debating over such a relatively trivial problem to communicate the messages: Good engineering is hard. Everyone is learning. Opinions can vary. Show some humility and grace.
jjice 5y ago
The way she kept referring to the programmer made me suspicious that that would be the ending. I personally really like that as a way of conveying the message of us all having growing pains and learning the hard way from some inefficient code. I know I've also had these encounters (specifically in DBs), and I'm sure there are plenty more to come.
5faulker 5y ago
Seems like the definition of hacker to me.
jraph 5y ago
I was reading her article like "yeah, well… wow, she's tough / hard with this programmer, it's not that unreasonable anyway!", until this passage. I would not expect her to be like this from what I've read on her blog so I was surprised. Well written!
shrimpx 5y ago
> tend to chase off anyone who makes it to the age of 35 That's definitely not true anymore, if it ever was. Senior/staff level engs with 20+ years of experience are sought after and paid a ton of money.
- deleted 5y ago
  [deleted]
deleted 5y ago
[deleted]
evilotto 5y ago
Two engineers I interact with on a regular basis: 1. Me from six months ago. Clueless about a lot of stuff, made some odd technical choices for obscure reasons, left a lot of messes for me to deal with. 2. Me six months from now. Anything I don't have time for now, I can leave for him. If I was being considerate I'd write better docs for him to work with, but I don't have the time for that either.

by welder 5y ago

Aeolun 5y ago

> My point is: EVERYONE goes through this A lot of the basic issues beginners go through can be mitigated by paying attention in class (and/or having formal education in the first place). I’ll grant that there are other, similar, things that everyone will go through though. My own was manually writing an ‘implode’ function in Javascript because I didn’t know ‘join’ existed.

carapace 5y ago

(It seems a lot of folks are getting nerd-sniped by the set-up and missing the moral of the story, eh?) I don't know the actual numbers, but it's been pointed out that at any given time something like half of all programmers have been doing it less than five years, for decades now. That, plus the strident ignorance of past art and practice, seem to me to bring on a lot of issues.

twic 5y ago
I don't think it's purely nerd-sniping. If your story is "at first you are bad, but then you get good", but your example is of a case where you did something fine but then replaced it with something worse, that rather undermines the story.
- emilsedgh 5y ago
  > but your example is of a case where you did something fine but then replaced it with something worse They way I see it is that it was a case of something that wasn't working, then replaced with something that was working. I don't know what your metrics about "good" or "bad" are but eventually they got a solution that covered their use cases and the solution was good enough for stakeholders and that is "good".
- adolph 5y ago
  Chronology alone only progresses; progress sometimes regresses.
- mwcampbell 5y ago
  If even someone with Rachel's level of experience still doesn't know all the minutiae of database optimization, I think that just amplifies her point about the importance of mentoring novices.
  - duxup 5y ago
    I recall reading a rant on another site about someone so upset they had to deal with clueless noobs at work. They then went on to list the errors that this brand new entry level employee had made when writing ... an authentication system ... I was more than a little shocked when I realized they were serious and hadn't realized the issue was sending the new entry level guy to do that job alone.
    - gonzo41 5y ago
      I would expect most seniors to want a set of eyes across their work doing any form of authk or z. If only to share blame :p
      - thaumasiotes 5y ago
        > authk I've always seen authn. Where'd you pick this usage up?
beering 5y ago
> (It seems a lot of folks are getting nerd-sniped by the set-up and missing the moral of the story, eh?) The narrative should lead to the conclusion. If I told you the story of the tortoise and the hare in which the hare gets shot by a hunter, then said the moral is "perseverance wins", you'd be rightfully confused.
deleted 5y ago
[deleted]
lamontcg 5y ago
> It seems a lot of folks are getting nerd-sniped that is an excellent term.
- jacobolus 5y ago
  Origin: https://xkcd.com/356/ https://xkcd.com/356/
  - wwweston 5y ago
    Old enough some people under 35 may not have encountered it… ;)
    - egeozcan 5y ago
      I feel like that phrase has been there forever, and I'm exactly 35. Will this happen more often as I grow older? Ugh. Feels weird. Maybe also a bit depressing.
      - lamontcg 5y ago
        It was weird seeing all the spongebob squarepants memes take over the internet when I was too old to ever grow up with that. I turned 28 in 1999 when that first aired. That was my "holy shit I'm so old" moment when that finally trickled up into my awareness as someone nearly turning 40 or so.
        yesenadam 5y ago
        Same age as you. I have a lot of friends in the Philippines. I swear the Facebook employment info of half the people in the Philippines says they work at the Krusty Krab. (And for most filipinos, the internet = facebook.) For some reason I never asked what that meant, and for many years I thought that was just some odd joke, and was vaguely puzzled about how widespread it is. Eventually I happened on the Spongebob connection!
        _carbyau_ 5y ago
WorldMaker 5y ago
The math would resemble xkcd's Lucky Ten Thousand: https://xkcd.com/1053/ https://xkcd.com/1053/ With yes the added confounding factors of how often our industry seems to prefer to hire youth over experience, and subsequently how often experience "drains" to other fields/management roles/"dark matter".

crispyambulance 5y ago

Yep. Folks are getting lost in the weeds discussing indexing of database tables. That's _totally_ beside the point here. The thing is, the first implementation was a perfectly fine "straight line" approach to solve the problem at hand. One table, a few columns, computers are pretty fast at searching for stuff... why not? In many scenarios, one would never see a problem with that schema. Unfortunately, "operating in a vacuum with no mentorship, guidance, or reference points", is normal for many folks. She's talking about the trenches of SV, it's even worse outside of that where the only help you might get is smug smackdowns on stackoverflow (or worse, the DBA stackexchange) for daring to ask about such a "basic problem".

otterley 5y ago
I’d be a lot more sympathetic if the major RDMSes didn’t have outstanding and thorough reference manuals or that there weren’t a mountain of books on the subject that cover, among other things, the topic of indexing and its importance. MySQL’s manual, for example, has covered this subject from the very beginning: https://dev.mysql.com/doc/refman/5.6/en/mysql-indexes.html https://dev.mysql.com/doc/refman/5.6/en/mysql-indexes.html (I don’t have the 3.x manuals handy but it was there back then too). It’s not clear from the article whether the author spent any time studying the problem before implementing it. If she failed to do so, it is both problematic and way more common than it ought to be. “Ready, fire, aim” But you know what they say: good judgment comes from experiences and experience comes from bad judgment. Compounding the problem here is that the author now has much more experience and in a reflective blog post, still got the wrong answer. IMO the better lesson to take away here would have been to take the time getting to know the technology before putting it into production instead of jumping head first into it. That would be bar raising advice. The current advice doesn’t advise caution; instead it perpetuates the status quo and gives “feel good” advice.
- dasil003 5y ago
  I couldn't disagree more with this comment. No amount of reading documentation teaches you how to build production systems. You progress much faster by getting your hands dirty, making mistakes, and learning from them. The challenge of writing good software is not about knowing and focusing on the perfection every gory detail, it's about developing the judgement to focus on the details that actually matter. Junior engineers who follow your advice will be scared to make mistakes and their development will languish compared to those who dive in and learn from their mistakes. As one gains experience it's easy to become arrogant and dismissive of mistakes that junior engineers make, but this can be extremely poisonous to their development.

deathanatos 5y ago

… I appreciate her sentiment at the end there that we should try to change the status quo (which I think does suck), but I'm not sure how much power the average employee has over it. Most employers I've worked at seem loathe to retain anyone past about 2 years. (E.g., currently I'm in the 95'th percentile, after just over 2 years.) IME it takes about 6 months to really learn how a company's systems work to where to proficiency (yes, six months.) which means we're spending ~25% of the time "training", where "training" is usually someone trying something crazy and failing, and getting corrected as opposed to some structured form of learning. Oftentimes the systems that these engineers are stumbling I think are the internal ones; they need more features, or refactoring to account for organic growth, but since they're not shiny new customer facing features they'll get exactly 0 priority from PMs. The engineers who build experience working with these systems and actually know what needs to change and how without breaking the existing use cases … are about to leave the company, since nobody is retained beyond ~2 years. I also find my own team is usually strapped for resources, normally, people. (Usually politely phrased as "time".) Yes, one has to be wary of mythical man-month'ing it, but like my at my last employ we had essentially 2 of us on a project that could have easily used at least one, if not two more people. Repeat across every project and that employer was understaffed by 50-100%, essentially. Some company just went for S-1, and they were bleeding cash. But they weren't bleeding it into new ventures: they were bleeding it into marketing. Sure, that might win you one or two customers, but I think you'd make much stronger gains with new products, or less buggy products that don't drive the existing customers away. Also there's an obsession with "NIT" — not invented there — that really ties my hands as an engineer. Like, everything has to be out sourced to some cloud vendor provider whose product only fits some of the needs and barely, and whose "support" department appears to be unaware of what a computer is. I'm a SWE, let me do my thing, once in a while? (Yes, where there's a good fit for an external product, yes, by all means. But these days my job is 100% support tickets, and like 3% actual engineering.)

unclebucknasty 5y ago

What's funny is there seems to be a lot of debate among grizzled veterans here about whether her old solution is actually better than the new. We're getting into index types, engine implementations, normal forms, etc. And really, this is a relatively simple development problem that I can easily imagine on an interview test. Now, imagine a new engineer, just getting started trying to make sense of it all, yet being met with harsh criticism and impatience. Maybe that was exactly her point--to get everyone debating over such a relatively trivial problem to communicate the messages: Good engineering is hard. Everyone is learning. Opinions can vary. Show some humility and grace.

jjice 5y ago

The way she kept referring to the programmer made me suspicious that that would be the ending. I personally really like that as a way of conveying the message of us all having growing pains and learning the hard way from some inefficient code. I know I've also had these encounters (specifically in DBs), and I'm sure there are plenty more to come.

5faulker 5y ago

Seems like the definition of hacker to me.

jraph 5y ago

I was reading her article like "yeah, well… wow, she's tough / hard with this programmer, it's not that unreasonable anyway!", until this passage. I would not expect her to be like this from what I've read on her blog so I was surprised. Well written!

shrimpx 5y ago

> tend to chase off anyone who makes it to the age of 35 That's definitely not true anymore, if it ever was. Senior/staff level engs with 20+ years of experience are sought after and paid a ton of money.

deleted 5y ago
[deleted]

deleted 5y ago

[deleted]

evilotto 5y ago

Two engineers I interact with on a regular basis: 1. Me from six months ago. Clueless about a lot of stuff, made some odd technical choices for obscure reasons, left a lot of messes for me to deal with. 2. Me six months from now. Anything I don't have time for now, I can leave for him. If I was being considerate I'd write better docs for him to work with, but I don't have the time for that either.