Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

zef.me

Post reply on HN
Print view View original

161–170 of 268 posts

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

#161

Post by tjradcliffe »

rdtsc wrote: post #68
panarky wrote: post #62

Earlier quoted context omitted.

Once upon a time I was a programmer, building CRUD apps for enterprises. I hated puzzles, too. Then I discovered quicksort, and graph search, and Bayesian inference, and Dijkstra, and Karatsuba. I'm still a programmer, but now I love puzzles, too.

> Then I discovered quicksort, and graph search, and Bayesian inference, and Dijkstra, and Karatsuba. I would guess most "discovered" those because they had to interview. The % of programmers who need to Karatsuba or Bayesian inference to finish their project is very much smaller than the % of programmers who thought "oh shit, I better learn this because Google and Facebook keep asking about graph theory". It it is p…

I distinguish between two types of puzzles: human-made (which I call puzzles) and everything else (which I call problems.)

In those terms, I hate puzzles and love problems. Puzzles are contrived by humans and are generally as much psychology problems as anything else. They basically require you to think like the human who created them, and they have bizarre and arbitrary constraints that are totally unlike the real world, where, as Feyrabend told us, "Anything goes."

Puzzle-style interviews are 99.9% human made, and one of the features of human-made puzzles is: the answer is known and very nearly unique. This makes them almost completely unlike the real problems programmers encounter, where there is no known answer (if there was, the programmer would find it on Stackoverflow or similar) and amongst the potential answers there is no obvious winner.

So it's really easy to be good at puzzles and terrible at problems, which require taste and good judgment to navigate through the combinatoric explosion of approaches and parameters (and no, design-of-experiments won't do more than give you a little assist on genuinely hard problems.) Problems also require one to know when to stop, when a solution is "good enough" for the given domain. Even problems that are nominally non-statistical in nature require decent statistical knowledge to evaluate potential solutions.

So as someone who designed algorithms for a living for quite a long time, and still does for fun and profit now and then, I'm as strongly against puzzles as the OP. I'm actually slightly biased against people who love puzzles because it looks to me like they are spending way too much time playing with nice, neat pebbles on the beach, when the ocean of ugly, intractable problems lays unexamined before them.

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

#162

Post by jakejake »

general_failure wrote: post #107
seanflyon wrote: post #75

Earlier quoted context omitted.

Algorithms are not puzzles, they are solutions to puzzles.

OK, so it would be ok if an interview someone replied "algorithms are solutions to puzzles" ? I don't think they are. They are solutions to problems in computer programming. Solving computer programming problems has nothing to do with your aptitude in solving puzzles and brain teasers.

Unfortunately in today's climate it might be realistic to say "algorithms are solutions to interview questions" Although I do believe the more tools you have in your toolbox the better. Knowing algorithms can be incredibly helpful. Same goes for design patterns, language design, etc.

It just seems like a fad to drill people with algorithm questions in interviews even if that skill will never be required for the job. I suppose it reveals to a certain degree whether that person has formal CS training or a personal interest in algorithms.

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

#163

Post by dragonwriter »

Maken wrote: post #155
rdtsc wrote: post #68

Earlier quoted context omitted.

> Then I discovered quicksort, and graph search, and Bayesian inference, and Dijkstra, and Karatsuba. I would guess most "discovered" those because they had to interview. The % of programmers who need to Karatsuba or Bayesian inference to finish their project is very much smaller than the % of programmers who thought "oh shit, I better learn this because Google and Facebook keep asking about graph theory". It it is p…

I don't get why people tend to think that computer science is something different from "actual programming". In the end everything you can program can be expressed formally and vice-versa, the only thing that changes is how much you abstract from the actual implementation, which is handy in order to catch defects in the approach you are taking to certain problem.

The difference between computer science and programming is analogous to the difference between physics and architecture.

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

#164

Post by computerjunkie »

fredsted wrote: post #4
nemo1618 wrote: post #3

Anyone have a not-dead link to the comic he's referencing? (looking forward to a future where an image's URI is its hash and this problem evaporates)

Here you go: http://mu.ms/f/pxYcdb.png

This made my day. Quite weird how that's the case with programming.

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

#165

Post by colanderman »

computerjunkie wrote: post #140
phazmatis wrote: post #125

Earlier quoted context omitted.

That's great if you're a game AI programmer (an incredibly small group) or you're creating Yet Another Dependency Loader (hey, I guess will only have 100 frameworks to manage modules, you'd better create your own as well). You know what I really wish? Programmers would spend 1/100th of that algorithm studying on learning to write readable, maintainable code.

>>>learning to write readable, maintainable code. Which is why I love python. Have you seen some poorly written JavaScript that's poorly indented and has no comments? Until there is a universal guideline for JavaScript and that developers follow, I won't have a go at it again.

Indentation is pretty low on the list of things that make code maintainable or not. (If it bothers you, just pass the code through a pretty-printer.)

Much more important is to pay attention to system-level measures such as modularity, abstraction, (de)coupling, and documentation. 99% of maintenance nightmares are due to code that is not modular (and thus not easily replaced), is abstracted too much or too little (leading respectively to obtuse or repetitive code), highly coupled (causing brittleness when assumptions are broken), or poorly documented.

(There are probably others, but these are the first to come to my head. These measures are also not necessarily orthogonal.)

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

#166

Post by triangleman83 »

R_Edward wrote: post #105

>Four people need to cross a rickety bridge at night. Unfortunately, they have only one torch and the bridge is too dangerous to cross without one. The bridge is only strong enough to support two people at a time. Not all people take the same time to cross the bridge. Times for each person: 1 min, 2 mins, 7 mins and 10 mins. What is the shortest time needed for all four of them to cross the bridge? 17 minutes, if you…

Well if you're stipulating starting positions, the fastest possible would be if the 7 and 10 minute men are on one side, and the 1 and 2 minute men are on the other. Each pair would only have to cross once, passing the torch while they are all on the same side. 10 minutes + 2 minutes for 12 minutes total.

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

#167

Post by lomnakkus »

smacktoward wrote: post #50
fullofcrap wrote: post #14

Earlier quoted context omitted.

I think there are categories, and we haven't figured out what to call them yet or how to define them. I see archetypes emerging over the years, and patterns. I've worked with career programmers that are done at 5:00pm, and never crack a book. They work fine in their niche, and when layoff come, they're working tech support. I know others that love problems but can't seem to make their ideas become manifest, yet kludg…

> We're all programmers, but we're not all the same Which is a rebuttal to something I didn't actually say, but OK. Look, obviously there are all different kinds of programmers. Millions and millions of people program computers today, so there's no end to the ways you can slice them apart. There are kernel programmers and GUI programmers, mainframe programmers and mobile programmers, Lisp programmers and BASIC progra…

Hopefully I'm not contributing to the "schism" here, but:

I tend to divide programmers into "drones" and "meta-drones" (for want of better words).

First, "meta-drones" consider the "meta" level of programming, i.e. "could I program more reliably if I were using a different language?" or "how can I prevent myself from making similar mistakes in the future". Surprisingly few programmers actually fall into this category. This is obviously IME, so the usual observer/survivor biases may apply.

In contrast, a "drone" will just "get the job done" without any further thought.

As far as I've been able to ascertain, code maintainability/quality is entirely orthogonal to the "archetype", but there's a clear tendency that the "meta-drone" tends to improve by orders of magnitude over time.

The number of hours of work put in has no significant effect when you account for those orders of magnitude.

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

#168

Post by maxlybbert »

yen223 wrote: post #132
maxlybbert wrote: post #108

Dijkstra commented on this multiple times (e.g., https://www.google.com/search?q=dijkstra+puzzle+minded+ewd+s... ). "I still often hear that a successful programmer should be 'puzzle-minded' whereas I have the feeling that a clear and systematic mind is more essential. A modern, competent programmer should not be puzzle-minded, he should not revel in tricks, he should be humble and avoid clever solutions like the pla…

Having seen people banning list comprehensions from Python because they are "too clever", I am wary of people who instinctively avoid "clever solutions".

The problem, of course, is that there are wildly different definitions/thresholds for clever.

Dijkstra's comment was made when assembly language was widespread, and I suspect that his idea of "clever" involved the various ways people can famously make assembly language unreadable.

In the introduction to "A Discipline of Programming," he asks if advanced language features belong to the solution set or the problem set, but he doesn't define "advanced," so I can't say where he put the threshold.

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

#169

Post by SomeCallMeTim »

reverius42 wrote: post #156
SomeCallMeTim wrote: post #131

Earlier quoted context omitted.

Without calling one group "REAL", it would be nice to have different words for different tiers of programmers. And I can't comment on the poster above, but when I do think of programming skill tiers, it's not at all about number of hours put in. Yes, if you're passionate about a problem it can mean you end up putting in extra time to solve it. But it's not about the time. It's about the passion . Similarly, it's not…

I take offense at your gross misconceptions. JavaScript is by no means an "easy" language, certainly not orders of magnitude easier than whatever it is you do. The skills of a "JavaScript developer" include combining object-oriented and functional design patterns to organize a codebase, efficiently managing asynchronous communication and state, profiling and optimizing rendering and execution performance across the C…

JavaScript can be used to do complex things.

A "copy-and-paste JavaScript" developer, as I referenced above, is someone who can create web pages that have simple actions, but who doesn't do much original development.

The language certainly doesn't define the programmer. I also use JavaScript on occasion; I wasn't trying to paint all JavaScript developers with the same brush.

It sounds like what you do is NOT what I'm talking about, so please don't take offense.

I write games, and tools to make games, and tools to stream interactive applications over the Internet. And apps. And the occasional web site.

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

#170

Post by gaylemcd »

If you program, you are a programmer. By definition.

I suspect what you're really asking is: why do so many companies thinking programming == solving puzzles?

The answer is that: (1) Based on what you're defining as a puzzle, they don't. (2) It is valuable skill (but it's also not the only skill).

-- (1) --

While there are stupid companies that ask "puzzles", this is not the norm at Google, Facebook, and similar companies. The "puzzles" listed at that Google link are basically fake. Link bait. While it's possible that each of those was asked at Google, I doubt that's where the author of that blog post got them from. They are certainly not representative of Google questions.

The "puzzle" questions you're referring to are really more like: - Design an algorithm to return a random node from a binary tree - Design an algorithm to find the nth number divisible by only 9, 13, and 15

You can define "puzzle" however you'd like, and I'm not going to engage in some debate over whose definition is "right." Doesn't matter (and there probably isn't a "right") here.

In the real questions asked at companies like Google, there's typically no sudden insight you need or trick in the wording. Rather, these questions are about working through a different problem and creating optimal solution (and recognizing tradeoffs along the way).

-- (2) --

That is an important skill for a developer. It is valuable for a developer to be good at that, and even enjoy it.

Maybe you don't care about making your solution better. Get it done. Get it out the door. Even if it's not perfect.

That probably makes you a less awesome developer, but it doesn't mean that you are necessarily a bad developer. There are lots of parts of being a "perfect" developer. - Enjoying testing. - Understanding what users want. - Architecting a system. - Understanding the lower level computer architecture. - Being a perfectionist. - Not being a perfectionist and knowing when you just need to get something done. - Knowing how to scale a large system. - and so on.

There are a TON of things here. No one has all of them.

You might be missing one of them, and it's a fairly important one. But it's not the only one.

I once worked [worked = prepping the startup for acquisition interviews] with a developer who was, honestly, quite stupid. He was exceptionally poor at developing good algorithms. His code however was correct.

He would be terrible at a company like Google. But at this company, he was very good. You see, he was very detail-oriented and thorough. If you want someone to write a correct bit of code for a very tedious and boring problem, he's your guy.

Is he a good developer? In the right role, yes.

This doesn't mean that Google is flawed for doing interviews this way - not at all. Their goal is not to hire all good developers. Their goal is to hire enough good people and to not hire bad people.

Problem solving/algorithmic skills and coding skills is a decent filter for that purpose.

Post reply on HN