4 ms·

> Conversely if you love algorithms and are sufficiently good at them then you can spend your entire career with that and never ever talk to non-technical peopl

> Conversely if you love algorithms and are sufficiently good at them then you can spend your entire career with that and never ever talk to non-technical people. I think there are two types of programmers. Ones that are like you that like algorithms for algorithms sake. And the other that like to solve real world problems. I got into software development because I want to solve problems for people. And not all of us likes algo. We prefer to learn stuff that we do use day to day because that has direct impact. For example, I just spent two months understanding functional programming. I use it in my code almost everyday, but it would be worthless in an interview where you are judge by your algo understanding. It’s frustrating when you realize how this standard is forced on every technical role, on companies that don’t even need algo experts because they are too small.

tptacek 4y ago
I've never written a parser because I love parsing. I actually kind of hate it, and have always been baffled by the people who nerd out on it. But, like, when I'm working on a problem that needs a parser, I'm glad I can bang one out! Like I said elsewhere: that's happened a bunch of times in my career.
- setr 4y ago
  There’s another aspect of this that the knowledge and comfort of being able to put together a parser properly means you’re more likely to identify places where it would be useful, and consider it worth the trouble to do so. That is, to one without a hammer, nothing looks like a nail.
  - nowherebeen 4y ago
    > That is, to one without a hammer, nothing looks like a nail. They irony of this is that for one with a hammer, everything looks like a nail. The real problem is that programmers have spent far too much time worrying about efficiency in the wrong places and at the wrong times; premature optimization is the root of all evil (or at least most of it) in programming. Donald Knuth. Knowing when to apply something is just as important as know where
    - benj111 4y ago
      I think the metaphor still works. A lack of hammer implies only having a screwdriver. The point is you should have a tool box (and garage and workshop and spare bedroom) full of tools so you have the exact tool you actually need. What the Phillips head and pozidrive represent in this metaphor are left as an exercise for the reader. As is the adjustable spanner.

tptacek 4y ago

I've never written a parser because I love parsing. I actually kind of hate it, and have always been baffled by the people who nerd out on it. But, like, when I'm working on a problem that needs a parser, I'm glad I can bang one out! Like I said elsewhere: that's happened a bunch of times in my career.

setr 4y ago
There’s another aspect of this that the knowledge and comfort of being able to put together a parser properly means you’re more likely to identify places where it would be useful, and consider it worth the trouble to do so. That is, to one without a hammer, nothing looks like a nail.
- nowherebeen 4y ago
  > That is, to one without a hammer, nothing looks like a nail. They irony of this is that for one with a hammer, everything looks like a nail. The real problem is that programmers have spent far too much time worrying about efficiency in the wrong places and at the wrong times; premature optimization is the root of all evil (or at least most of it) in programming. Donald Knuth. Knowing when to apply something is just as important as know where
  - benj111 4y ago
    I think the metaphor still works. A lack of hammer implies only having a screwdriver. The point is you should have a tool box (and garage and workshop and spare bedroom) full of tools so you have the exact tool you actually need. What the Phillips head and pozidrive represent in this metaphor are left as an exercise for the reader. As is the adjustable spanner.