I Hate Puzzles: Am I Still a Programmer? (2011)

In restaurants you have line cooks, prep cooks, and then occasionally if you are a "fancy" enough of a place you have a sous chef and an executive chef.

The one common thread here is, they are all cooks.

Now most line cooks will have never have actually "created" a dish, just like most of us have never "created" an algorithm, (having the vision for something new, knowing which ingredients sourced from what region will work the best, knowing how the various intricacies of spices, how they interact with each other, what temperature is optimal for meats, ect), but I am sure they know how to put something new together.

Does that mean I can't program? Ha ha ha, no. Does that mean I can't manipulate strings like a boss? Ha ha ha, no. I first reach for the language's tools, before I reach for regular expressions (the OP, I would first reach for doing a string search for {, and then one for }, from the rear if you want it greedy, and substringing what is in the middle; it's far less ambiguous, and any dev will know exactly what it does). Even when something ~technically~ takes a regex, if what I'm looking for is just a literal (as it often is; does this string contain X or not?), I don't need to 'know' regexes. So there's a LOT I can do without knowing regular expressions.

Meanwhile, I -have- needed to be able to recognize that something was running in O(n^2) time, and what I could do to optimize it to O(n). I -have- needed to implement my own search and bucket sort routines.

EDIT: Oh, wait, no, for the regex I'd need to escape the brackets, too. Etc. See? Now I have two problems.

I'd only partially agree with this.

One of these things is not like the others: HTML and CSS are not programming languages; JavaScript is, and we're treating it like one now. As we move into a world of "client side applications" rather than "dynamic HTML," JS can be an order of magnitude more complex than it was just a few years ago. If you're going to use Angular or Backbone well, you're going to need to have a solid understanding of at least a few design patterns. You're probably going to need to know the difference between a queue and a stack and when you'd use one or the other (or neither), and you're going to need to be able to look at a problem and say "this is something I need recursion for." There's an awful lot of people who could make a good living as a web developer in 2004 who couldn't in 2014.

Having said all that, I think the current hiring process, particularly among Facebooks and Googles and startups that emulate them, is pretty heavily biased toward things one only learns in computer science degree programs (or when one is desperately floundering around trying to solve a "take home" interview puzzle). I don't want to claim that it's bad to know how to do directed graph cycle detection in your language of choice, but the need to do that is only going to come up in fairly specific circumstances -- and it's more important to know that someone you're hiring can find the information necessary to solve a problem and apply it than it is to know whether or not they have that information memorized.

(I'd also argue that demonstrating they can write readable, well-documented code that other people can actually work on is really important, but I almost never see that tested, oddly enough.)

A puzzle is a puzzlemaster saying "try to find the exit in this maze I devised!". But I'd rather build my own mazes that I'm more interested in, and then try to find the exits for my mazes.

If people find other people's problems interesting, then good for them. Mostly I find that my curiosity creates the most interesting puzzles, perfectly suited to what I'm interested in.

In other words, implicit in liking puzzles is the assumption that you care for what the puzzlemaster cares for. I find that double coincidence to be rare (for instance, Gardner's puzzles as discussed today here are mostly uninteresting to me).