> Coming up with algorithms is the programmer’s version of puzzle solving.
I'm not really seeing the connection. Are they both just things you don't like?
I Hate Puzzles: Am I Still a Programmer? (2011)
41–50 of 268 posts
Re: I Hate Puzzles: Am I Still a Programmer? (2011)
#42Programming is a pyramid. Each strata building on the other. Anyone can join in on any level to contribute. I enjoy living on the framework and data levels. I really don't like front end or bare iron work. That certainly kills some job opportunities, but I'd rather be happy.
Re: I Hate Puzzles: Am I Still a Programmer? (2011)
#43I could have written this; It's me to a T. I build things. I like building things. It's fine with me if it's not completely original. I can ride around my city and point to the parts I helped build. I like that.
When I program I bring order from chaos. I can do that best by using the discoveries of others, and building them up. I'm glad there are creative people who love mathematics enough to figure out original algorithms; I appreciate their work. I'm not one of them. It doesn't change the quality of what I build.
Re: I Hate Puzzles: Am I Still a Programmer? (2011)
#44As many others have already said, if you've been programming for 18 years, then yes, you are a programmer. I wouldn't say you're crazy for not liking puzzles, but I would say you're crazy for not liking puzzles and pursuing a Ph.D in (what I assume is) Computer Science, since that is invariably what most research involves, and what most Ph.D level jobs are going to involve.
Re: I Hate Puzzles: Am I Still a Programmer? (2011)
#45This is what really irks me about the industry as a whole. Large companies like Facebook and Google have hiring processes in place that aim to weed out the strong from the weak by making them solve complex algorithmic puzzles and solve them on a whiteboard, and for larger companies like Facebook or Google who have massive troves of data, this kind of makes sense to me, but only if you're hiring a programmer to work with your data, not make things pretty or interface with existing services.
However, what does not make sense to me is the asinine requirement that a web developer needs to know or understand algorithms. A front-end developer working with HTML, CSS and Javascript will never EVER need to know how to write an algorithm. In my 12 years as a developer thus far I have never needed to solve a complex math problem or write an algorithm to markup some HTML, the closest I get to math problems is simplistic operations in Javascript like calculating the scroll distance from the top of a page or mathematically moving an element around the page in a particular way and I generally use a calculator for these problems.
The problem is many startups try and replicate the likes of Google and have the attitude of, "Well, if Google require you to solve complex math puzzles on a whiteboard in 30 minutes, then that is what we will do too" - reality check: A developer working with HTML, CSS and Javascript does not need to know algorithms whatsoever. Only a developer working with data or writing an algorithm to sort it should need to know that stuff. You are not Google, so stop pretending you only hire smart developers who know how to solve unrealistic math problems that they will never encounter.
I have heard from friends and experience a couple of times myself, broken recruiting processes that ask you to solve non-realistic problems and complex math puzzles (which I always fail myself). My policy is unless I am going for a job working and sorting through data, I should not need to know how to write an algorithm on a whiteboard.
The only skill I think all developers should know regardless of whether you are a front-end developer or writing complex algorithms to sort through billions of rows of privately collected American data through a secret Government program is regular expressions. I do not know regular expressions extremely well, but I know them enough to be useful with them and I think this is one area where most developers fail. You might know the latest tools, heck, you might even know how to write an algorithm to sort through a large set of data, but if you can not write a regular expression (even for the most basic of tasks), then I think we have a problem.
The interview process for most developers should be simple like this: Can you write regular expressions? (yes) or (no) - if (yes) then write me a regular expression to get the value between two curly braces in my Node.js application and you have got the job.
There are always going to be companies out there with this unrealistic inflated image of how smart a developer should be. To be quite honest, I would not call myself an overly smart person. A lot of the problems I solve on a daily basis are merely following simplistic troubleshooting steps with a combination of Google and reading the documentation. Most of my day job is simply just common sense. Web developers in particular are over-glorified Googler's with an eye for detail and a large bottle of strong adhesive used for gluing different pieces together. And you know what? There is nothing wrong with that, it is the truth, because I am one of those people.
Re: I Hate Puzzles: Am I Still a Programmer? (2011)
#46Optimizing out inefficiency and waste is part of good programming. So yes.
Re: I Hate Puzzles: Am I Still a Programmer? (2011)
#47The problem isn't with him, it's with programmers who have an inflated view of how smart you have to be to be a programmer. There are plenty of smart programmers, and there are plenty of problems that would benefit from smart programmers, but the vast majority of problems just need a spark of creativity and a lot of hard work from a person with a reasonable base of knowledge.
And then people don't know where impostor syndrome come from... With a lot of BS being spewed on the net like "everybody needs to know how to unit test", "everybody should learn how to use Vagrant", "everybody should know Ruby", "knowing the SOLID principles is essential" And then you ask them how to write a regular expression and they fall flat on their face. Or the basics of how to do a Fourier transform. Or how to…
Programmers SHOULD know how to write tests for their code. And how to write clean, well designed code (even if they don't call it SOLID). And they should know how to use regexps as well. These are skills that are transferrable whether you're doing frontend work for a small ad agency or crunching numbers for the NSA.
Re: I Hate Puzzles: Am I Still a Programmer? (2011)
#48The most challenging aspect of programming, for me, is the ability to turn something over in my head to look at it mentally. To be honest, I can only do that for any length of time on a good day. Writing stuff down is laggy and sometimes lossy, so I am only at my most productive when I can take a complex problem with a lot of little fiddly bits, ingest it mentally, and keep a holistic model in my head.
Puzzles provide a good first-order estimation of this ability. Not solving puzzles, per se, but at least analyzing them. A good puzzle requires you to use a part of your brain as "scratch space" to hold hypotheses which are applied to other parts of the puzzle. Can I solve it this way? What if I tweak this part over here? Does this assumption simplify the path to a solution, or miss out on an important subtlety? I think the thing I tried previously was more correct; can I remember how to get back to it?
I'm actually not that great at this. Many of my peers are better. Fortunately, I can compensate in other areas (I'm glad to see writing skills called out in the comments, as I like to think I'm a good communicator). I have developed some coping mechanisms (the ability to identify which details in a problem can be succinctly written down and which subset can be stored in my head -- I refer to my notebook as swap space), but I do see the value of puzzle-type questions for evaluating a candidate's ability to do this sort of thing.
Does this mean that if you can't do it, you aren't a programmer? Of course not. I happen to be a kernel developer, so I write a lot of code that communicates with other modules, doesn't have much of a UI, and has a multi-dimensional rather than flat structure. Different types of programming need different sets of skills. Find your niche, and don't fret about how you don't fit into other niches as well as you fit into yours.
(I interviewed at Google seven years ago and was rejected for being weak at algorithm design. A few years ago I had an aha! moment where I found a simple, elegant, and easy solution to the problem I completely bombed in the interview. Apparently my subconscious had been chewing away at it for literally years. I think solving a question in four years or so is sub-optimal from Google's perspective so I'm sure they were right to reject me, and my inability to do it faster speaks to the deficiencies I mention above. But in the ensuing years I have become reasonably successful in my current line of work, which I enjoy completely. My failure at Google does not keep me up at night.)
TL;DR: Puzzles only measure a single axis, so find which axis your greatness lies on and optimize for that.
Re: I Hate Puzzles: Am I Still a Programmer? (2011)
#49The problem isn't with him, it's with programmers who have an inflated view of how smart you have to be to be a programmer. There are plenty of smart programmers, and there are plenty of problems that would benefit from smart programmers, but the vast majority of problems just need a spark of creativity and a lot of hard work from a person with a reasonable base of knowledge.
And then people don't know where impostor syndrome come from... With a lot of BS being spewed on the net like "everybody needs to know how to unit test", "everybody should learn how to use Vagrant", "everybody should know Ruby", "knowing the SOLID principles is essential" And then you ask them how to write a regular expression and they fall flat on their face. Or the basics of how to do a Fourier transform. Or how to…
Yea I also think people mistake the tools for the trade. The fact is, two programmers can exist who know nothing of about each other's toolset, and they aren't necessarily better or worse, simply in different domains.
Vagrant is (can be) great if you need heavily spec'd out VMs, but with python I believe virtualenv would suffice. In the end, they are only tools
Re: I Hate Puzzles: Am I Still a Programmer? (2011)
#50> 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.
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 programmers, elite programmers and n00b programmers.
But they are all programmers, was my point. They all do the work of wrestling with, as one of the people in Tracy Kidder's classic The Soul of a New Machine (http://www.amazon.com/The-Soul-A-New-Machine/dp/0316491977) called it, "La Machine."
In this respect, being a programmer is a lot like being a coal miner: you become one by doing the work. Sure, some miners are handier with a pickaxe than others, and some can stand being down in a dark hole for longer. But regardless of that, everyone who puts on a hard hat with a lamp on it and goes into the mountain is a coal miner. The only thing you have to do to earn the designation is show up and do the work.
Now for the part of my comment where I (respectfully) challenge your conclusions.
You want to divide "programmers" further, into (essentially) "programmers," who are lazy 9-to-5 stumblebums, and "REAL programmers," who code with burning fury 23.5 hours a day (the other .5 hours they spend on HN). And then tell the people outside the "REAL programmers" category that, sure, they're "programmers," but they're not programmer programmers.
But that has a value judgment embedded in it, namely that 23.5-hour-a-day Burning Fury programming is Good Programming, and 9-to-5 programming is Bad Programming. But those positions aren't good or bad, they're just embraces of different sets of tradeoffs. You note yourself that the Burning Fury programmer sacrifices her health and relationships to get to that level. The 9-to-5 person is just someone who has decided against making that sacrifice. Maybe that limits their career growth, but it lets them hold on to those things. Maybe you've decided to let those things go in order to accomplish more in your work.
And both those decisions are fine! I'm not here to tell you how to live your life. I'm just saying that your way of being a programmer is not the only way of being a programmer. There are lots of ways to be a programmer. The only thing they all require is that you do the work.