Live data from Hacker News

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

zef.me

91–100 of 268 posts

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

#91
I love programming, but I hate puzzles.

Solving puzzles is nothing like programming to me. Programming to me means crafting your own pieces of the puzzle and being able to create something unique and beautiful.

Of course programming has some bad and boring sides. I would compare those to solving a jigsaw puzzle.

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

#92

> I’ve been programming for 18 years now. Then congratulations, you are a programmer! Despite what you'll hear from people peddling various flavors of Kool-Aid, "programmer" isn't a personality type. It's a job description. If you program, you are a programmer, end of line, full stop. Don't let anyone convince you otherwise.

As a self-professed "boring" programmer, I think a lot times I'm extra useful on a team because I don't expect my work to be a fun puzzle and I'm willing to take on things that aren't much like a puzzle, but are still important.

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

#94
I love puzzles - especially ones that are unicolor or close to it but do have weird shapes - but never related it to programmings as a whole. That just seems wrong to me so I'd say your question should be phrased otherwise as it's far from a simple yes/no question. Just depends too much on what you thing 'programmer' means.

Programming itself is such a vague and general term me and my friends tend to split it in smaller, somewhat better defined aspects when discussing about it. I'd say aspects related to creating new code/design/refactoring don't have a whole lot to do with puzzles. Lowlevel debugging of nasty problems on the other hand does have quite a lot in common with puzzles. I should check some research on this, but wouldn't be surpised if one effectively uses different areas of the brain for these aspects as well.

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

#96
I look at puzzles as a problem-class that need to be solved, not the individual puzzles need to be solved, but the fact that there is a puzzle at all should be the thing that's being solved.

95% of software development is not solving complex algorithmic problems, it's plumbing. If the plumbing is so complex that it creates puzzles that need to be solved, then something probably went wrong somewhere along the line.

Preventing the 95% of software development that shouldn't be a puzzle from becoming one is something I'm very passionate about.

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

#97
Silly question of course, anyone who has programmed for 18 years is a programmer. But the missed question is "Am I a hacker[1]?" And it is that which puzzles attempt to ferret out. Let's take the example of the 1000 piece Escher puzzle that the author uses as an excellent example. They are correct that most of the pieces are just 'shades of grey'. Impossible right? If you're a hacker you say "Challenge accepted!" if you're not you say "This is way more work than its worth." Because what the hacker mentality gets reinforcement from, is overcoming the 'impossible' (or simply the 'you can't do this') not the actual puzzle assembly.

So in the Escher puzzle a hacker says, "Hmm the picture isn't much help, its not on most of the pieces. What else can I use? Shape!" and so first will attempt to identify every piece that has a shape suggesting it is on the edge of the puzzle. Next puzzle pieces themselves have a certain symmetry, with some 'coves' and some 'penisulas' (or convex and concave curves, or 'innies' and 'outies') so unknown pieces are often sorted into the number of those features they have. Basically the hacker is looking for any piece of information that can inform on a possible way to get to the end, generally that information is non-obvious at first, more obvious once you find it. Particularly delicious puzzles will have several layers of information.

So if you don't care to figure out ways to solve a problem that is, at first glance, either really hard or nominally impossible to solve, you can still program just fine but you need a set of rules for putting together your code. And you won't find yourself asking if they are the best set of rules for the particular problem you are coding, you just make sure the problem is solved. That is a perfectly valid programming model, it gets things done.

[1] And I'm using the puzzle solving / bounds testing skill here not the application which can be applied to good or evil.

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

#98
I tend to agree, I hate riddles and puzzles, I don't like trying to debug something in an embedded system with no screen, GDB (which is a riddle in itself), and a temporal component that prevent me from using some technique (like breakpoint scripts that continue).

I just put up with them in the hope that I get stuff done past them.

Today I tried an online Mensa test (the quick stuff), I didn't recognize any patterns in the domino section (I tried 5 before giving up, vertically, diagonally, like text, nothing), I guess, some people are not made for that. I know people who love them and are good at it, I just hope to still get some respect from them.

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

#99
Depends on the kind of puzzle to be honest. I enjoy puzzles (as in a physical puzzle like the author is talking about) but only ones that are not stupidly hard like his Escher puzzle. Sod that!

Programming puzzles are very different though. Do I hate programming puzzles? Sometimes. Again it depends on the puzzle at hand.

As for is he still a programmer? Well if he codes and produces something that works how he wanted it too then sure. He might be one of those programmers that hate debugging though so ends up writing more and more code to 'fix' a problem rather than actually find the real problem instead of coding around it.

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

#100
"The Tao that can be spoken is not the eternal Tao The name that can be named is not the eternal name"

Once "art" becomes defined, it ceases to become art. The barista ceases to become important once a machine can replicate the exact results. The artist becomes useless once his or her method can be codified and repeated.

The method of choosing good engineers also becomes useless once it is defined because then that standard can be copied without regards to the traits it originally was trying to gauge. Pure arbitrary processes aren't great because of the lack of transparency that encourages nepotism, but neither is a purely mechanical approach that opens itself to becoming gamed.

A heuristic exchanges information for faster processing. When heuristics are passed around, the original information is lost. Almost everything we do is a heuristic though. 3 meals a day, brushing teeth everyday, etc... Is it better than nothing? Probably. Is it great? No. But everyone offering a "solution" isn't really offering a solution. They're just telling personal stories about what heuristic worked best for them.

The job interview process is quite similar to the friend making process. Not everyone is going to be your friend, and following scripts like saying hello every morning isn't going to do it either. It's just one of those things that are part of life.

Post reply on HN