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'm a programmer who loves 'building the brain'. I've been coding professionally for about 16 years.
I've written some code I'm really proud of. A couple of specific pieces of code are actually used in a LOT of major websites you probably use. Like almost every health care site or major retailer site. I actually find most code written by 'whiz' startups - even successful ones - to be incredibly simplistic. Not a knock on them, just stating this for reference - I have even written some encryption code that gave me headaches to understand but is still in use by a few major financial corporations years after I wrote it. I know I can write some serious code. I studied and work with AI programming in my spare time.
I don't have a GitHub page, nor do I have an interest in having one. I barely have a StackOverflow profile. I post on Hacker News now and again but that's about it.
I don't care about hackathons or solving puzzles.
I hate the term 'nerd' or 'geek'. I am neither and I find the terms insulting. I'm just smart and I like to code. I am not socially awkward. I'm introverted, but I'm not shy. I played football and basketball and I played chess. These concepts are not mutually exclusive.
>>> I don't have a GitHub page, nor do I have an interest in having one.
Glad I'm not the only one.
>>> I don't care about hackathons or solving puzzles.
Couldn't have been said any better. I never produce anything good when its tightly timed, under pressure, when people are watching over you.
>>> I hate the term 'nerd' or 'geek'. I am neither and I find the terms insulting.
Add "ninja", "guru", "rockstar" and other hipster name floating around these days to your list. I hate it too.
I've been doing programming for 3 years on and off. I program for fun, as a hobby and I can't see myself programming to meet unrealistic deadlines year in year out for someone, that's my personal opinion. I grew up in an athletic environment so I also play rugby and sprint for fun too. The most I would do is to program small projects at my own pace and share them to people or keep it to myself. I hate rushing into things which I feel hackathons encourage.I like to think, research, think and then create.
I program because I generally like making things, not just programs but also technical drawing, house designs (architectural and interior) and custom-modded computer builds , it has no correlation to solving puzzles or cramming algorithms I probably will never use.
Edit: There is this insanely think barrier filled with confusion in Human Resources, as a recent Computer Science graduate, some of the job descriptions have unimaginably high expectations for entry positions I actually think you have no place here if you don't know 4+ languages, 2+ trendy frameworks, and 1-2 years of experience from a fresh graduate.
I wish programming culture didn't scare away people who enjoy athletics. I love playing basketball and sometimes it's hard to find other programmers who enjoy the same.
When I see "Ninja", "rockstar", etc. I run. Can't stand that.
Other fields seem to have managed to solve this problem without resorting to sophomoric faux-titles. It just reeks of childishness and the sort of tomfoolery that tends to get our profession laughed at.
When I see these words, it screams either "bunch of young kiddies" or "a bunch of olds desperately trying to seem cool" and neither are situations that I want to get involved with.
And all of this isn't even getting into the problem that 99.9% of people want rockstars, ninjas, jedi and superheroes but only about 0.1% really need them.
Why do we need to give programmers such punchy titles? I haven't heard anyone doing this in any other craft. In my view, calling someone a good, great, excellent, skilled, or top programmer as appropriate is more than adequate.
I am not arguing that programmers need to have "punchy" titles at all. However, others clearly that some sort of term beyond those you listed is necessary, and these names are evidence of that.
There is no need for those terms. They are marketing names dreamed up by people who think they can neuro-linguistically trick developers into thinking working for them (usually for less money than they are worth), then they can get over on them.
Again, what is the difference between a doctor who is one of the best in the world versus a doctor who is just 'decent'? What is the term that is necessary to describe that doctor that doesn't exist? Why would any profession be any different?
I don't think I'd even want to go to "Dr WhateverName, Ninja Orthopedic Surgeon" or want to know that he wrote "Secrets of a rotator cuff repair rockstar."
I just say they are world class programmers. Or excellent. There is no problem. How do you describe doctors who are very good at what they do? Do you call them ninjas? "Med nerds"?
You're claiming there is a problem here that doesn't exist. We have words to describe people who are good at what they do.
We need more of this. I played baseball and basketball and yes, I also played chess. I'm not an introvert (although I do love alone time). This narrow idea of what traits a good programmer has is the fault of Eric Raymond who when describing what kind of person is a good hacker was clearly just describing himself (interested in martial arts, plays a musical instrument and speaks a foreign language, all perfectly great interests but what makes them better than cooking or chess or painting?). While it's great to have hobbies that involve critical thinking, nothing about the going stereotype of a programmer is necessary to be a good programmer or good thinker.
Imagine if there was an equally narrow stereotype about what kind of person is a good doctor or lawyer. Doesn't that seem ridiculous? What about programming is different? Nothing. It seems so absurd to me that as an industry we're telling interested parties that diverse interests are a bad thing if you're a programmer and you should just stick to a short list of approved interests. No wonder there's no diversity in our field.
I work with a bunch of smart programmers who would, by the "if you aren't a 12 year old coder and you don't spend all your free time buffing your github profile" metric that pops up on HN, be unemployable. They are deeply, deeply clever people who speak assembler like a second language (or understand the bits of the JVM that most people don't think about, or what have you). They have lives outside their job.
Of course, this affects whether you can work on certain projects or not, but not that "every programmer knows that" is a fallacy (except for something really fundamental)
Many companies have a hiring process that favors hiring very similar engineers. Hiring different types of programmers would increase their diversity, which for me is a great quality of a team. The challenge here is to identify the competent engineers when you can't use cookie cutter assessment tactics.
Diversity is a strength, and I have learned this managing several teams of varying sizes over the years for different companies, as well as for myself.
I have heard many start up advisers tell people to 'hire people you like to hang out with'. This isn't the best advice. Personality is extremely important, and you don't want to hire people who will be incredibly difficult or toxic or adversarial. But you need different people in different roles, with different viewpoints, to make a strong team.
Suffices to see how several founders (of successful startups) were rejected or quit big companies. I believe Google is one of the worse offenders there.
> 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 perhaps an interesting secondary effect. CS concepts become useful not just because they are useful (and they are) but also because recruiters at many companies think they are. If tomorrow juggling skills somehow become popular during Google interviews. You'd see a lot of juggling programmers out there.
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.
An interesting heuristic difference between the two types of, lets call it, challenges, is how you define success.
In a puzzle, you achieve success as a well defined solution, or (in a lot of the theoretical cases) by showing no such solution exists.
In a problem, there is many goals to balance (simplicity, efficiency, cost, implementation time, etc). Often, the best solution is not needed, or the "optimal" one is too complex or takes too long to implement. Often, the perfect solution is not possible, and you have to think about how to change the definition of the problem to get something acceptable.
Totally agree! Puzzles are just one way of studying human (or animal) behaviour in a controlled environment. It's absurd to be used as the main tool to evaluate a person's competence.
So true; the Google, Facebook, Microsoft, Fill in Here puzzle interviews are pretty silly. Rather than splitting people into groups of "good developers" and "bad developers" they can really be split up into these two categories.
1) People who read Cracking the Coding Interview
2) People who haven't heard of this book.
Seriously; any competent programmer can crank through the stuff in that book in a week or two and be solid for the types of silly questions they will be asked in those interviews.
Honestly the best interview I ever had was one where I interviewed with a highly technical IT director and it was just very conversational. We spent about two hours of just chatting about the different types of technologies we had been working with and kept diving deeper and deeper into knowledge areas. At the end of it he just says, "Ok, you are obviously a smart guy; I'm going to send you over to see the VP now so you two can discuss salary requirements."
As the author of said book who has coached MANY people, I can assure you that many - heck, most developers - could not pass a Google interview regardless of how much they prepared. They'll get better with preparation, but it doesn't just fix all issues.
Don't get me wrong. I made it through the Amazon interviews thanks to your book. I spent a week reading through and cranking out examples before the interview. Then I spewed out all of the desirable answers at each step of the interview process.
Now I'm a highly experienced developer with 15+ years experience across a variety of technologies. I contribute to open source, answer questions on Stack Overflow, present at technical meet ups. I solve problems that need solving even when no one else will step up.
Despite all of my experience, implementing hashes and sorting linked lists in place, as well as many of the other questions asked by these companies just don't come up on a daily basis. A good developer isn't someone who can explain those things in an interview, it is someone that can examine the problem and design a solution. They should have an idea of the tools necessary and then reach for the right book or use a healthy dose of google searching some api docs to build the solution.
The current interviewing techniques are broken. I would like to offer the solution, but quite frankly I've spent plenty of time interviewing people and we haven't gotten it down yet either.
-------
The ideas Malcolm Gladwell discusses in, "Blink: The Power of Thinking Without Thinking", applies here. Some of the most experienced developers will have an intuition for how best to implement a solution, this does not necessarily translate to them being able to well articulate the why and how.
So, you're a good developer who is smart and passed the interviews with some studying. That's exactly how it's supposed to work :).
You're right that the problems that some up in interviews typically aren't real life problems. But that's not necessarily an issue. Are the skills they test (developing good algorithms) important for real life?
An interviewer doesn't ask you to develop an algorithm to return a random node from a binary tree because they particularly care if you know THAT algorithm. They're asking as a way of evaluating your skills developing solutions to problems you haven't seen before.
I believe that is the most common argument made, but also therein lies the fallacy.
I'm not developing anything new when I implement a quicksort algorithm; Tony Hoare certainly was back in 1960 when he created it. The same goes for the hash; someone at IBM made a big leap when they first used hashes back in the early 1950s.
Since that time numerous people have made some improvements to these (and other algorithms of course), but by and large companies are just testing is the developer interviewing able to code existing algorithms and explain their Big-O notation.
I think you end up with 4 subsets that the interviewees fall into.
I = {interviewees}
A = {I | bad programmer and can't solve algorithms}
B = {I | good programmer and knows the algorithms}
C = {I | bad programmer but knows the algorithms}
D = {I | good programmer, doesn't know the algorithms}
It is subsets C and D that concern me.
In subset C we have someone that studied the algorithms really hard, but just can't write good code and solve real original problems. One approach to this is the "hire fast/fire fast" mentality, but in some organizations "fire fast" is not an option; so you would rather not hire them in the first place.
In subset D we end up missing out on good developers. In a bad job market there isn't much need to worry about this; if we miss a good developer easily enough we'll find another. Right now though developers are in such high demand I see this loss as a bigger deal.
I also think that this type of interviewing technique works better for the tech giants (MS, GOOG, FB, etc...) than it would for a lot of smaller organizations. A good set of programmers will self select out of interviewing at these companies because they don't believe they are "good enough" for MS(or alt). Additionally a good set of developers that do believe they are high caliber enough for these organizations will do some research about the interview process before hand and end up studying up on the right things before going in.
With smaller companies or businesses with non centralized hiring processes for developers interview candidates may just not know what to prepare for in the interview and while an algorithm may seem obvious in hindsight; there is a reason nobody was using it until it was "discovered". I can't reasonably expect someone to devise the answer to that type of question when I interview.
Honestly I would love to hear some ideas on this; as it has been a pretty major concern for me for the last couple of years.
Actually I think graph theory is pretty important. For example many programming contexts have to deal with dependencies, and often dependencies form a directed acyclic graph. Understanding that will aid in writing better, more reliable code. Path finding is also pretty important, especially if you want to make a game.
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 <language that becomes super popular next year> 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.
> You know what I really wish? Programmers would spend 1/100th of that algorithm studying on learning to write readable, maintainable code.
IME, programmers that write readable, maintanable code and those that have a solid grasp of algorithms and theory as it applicable to the problem domain tend to overlap considerably. Having a clear analytical mental model of the approach to the solution leads to clearer and cleaner code -- and, where necessary, clearer and more useful comments -- than hacking your way to something that works. (And I'd say thats as true of my own code -- where I've done work on both extremes of the clear model to hacking-my-way-through axis -- as of others' code I've seen.)
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.)
Agreed. Some people say you'll only use it in games or AI or something fancier, but that's not entirely true. I work with what would be considered pretty boring enterprise software, and yet I once solved a pretty big problem using graph algorithms. That actually earned me a good reputation among my coworkers.
I don't think the primary complaint about these types of skills is that they are never useful. It's just that they are treated as disproportionately important, i.e. interviews consist of 80% CS knowledge but the real job only requires it 1% of the time on average.
I used some super simple graph theory recently to write a Java tool that spit out data from multiple tables on a database into SQL files, with statements in the right order so that foreign key relationships were preserved. And this was for a CRUD-ish web app.
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.
It's not the subject matter per se, it's the difference in habits and typical incentives for people who identify more with one description or the other.
For many products and businesses, it's not really necessary to avoid long-term dead-ends (say 3-5 years) if you can be much more effective in the short-term (say 3-12 months). So a high up-front cost (required knowledge and planning / research experience) approach often loses out to simply banging out more code, which requires little CS knowledge.
Because everybody can do "actual progrmaming." Especially in grad school.
Computer Science is broad (even AI is different), but I'd say it's more about Turing's academic papers, and computational mathematics. Programming, and computers, aren't even needed, they're just models which either can or cannot derive solutions, or in a reasonable time. Such as the halting problem, P, NP, NP-complete.
In a way it's mathematical logic, but with more rigorous proofs.
Everybody else can learn a generic language with some external libraries and make almost anything they want. But that's not more academic than it is to do woodworking, or sewing. Comp Sci is academic, and one of the more important ones because it determines a lot of research other disciplines do. I.e physicists and mathematicians do comp sci, while the softer sciences run models without understanding why they work.
I'd say fluid-dynamics and plumbing. Most businesses really just want us to connect this to that and not have the shit back up. If you can deliver that quickly, without much analysis, and without fuss than you're very effective for many business and product types.
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.
Algorithms are independent of both puzzles and computer programming. I learned plenty of algorithms in my EE undergrad that were used with a pencil and paper.
Would you disqualify a candidate based on that one data point? If so, I think you're missing good hires, and not in some false-negative preferred to false-positive way.
By discovering puzzles you are still a programmer, and you are a better programmer for it. Make no mistake. Yes you don't need to know algorithms to be a programmer, but you are better programmer for knowing the algorithms.
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.
Yes. We need to stop thinking of programmers as artists and more as artisans. This is not a devaluation, this is exactly what it is and a very necessary job. Each shoemaker used to be proud of his shoes, even though there are not so many different ways to make them. Less so in the early modern ages.
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 kludge snippets from StackOverflow to create a product. I personally live for challenge, I learn new languages and tech as a hobby, and lead growth and change in every org I've worked for. Often at the cost of health, and relationships. We're all programmers, but we're not all the same.
The best programmer I've ever worked with is done at 5. He has lots of other hobbies. But at work he's incredible efficient and solves really hard problems in brilliant ways. You don't have to give up your whole life to be a good programmer, contrary to what many people on HN seem to think. This mentality drives me crazy.
Agreed. I don't understand why we are so obsessed with putting in the hours.Its not just in programming, but also other sectors of the economy.I value my health, family and personal life, I'm competing with myself not against the clock. The clock will always win, no matter who you are or how great you are at programming. Work smart, not long.
I really don't like this euphemism. When I read this I know what you mean[0] but I wish this meaning wasn't tied to leaving the office at 5pm. If someone's effective in their role, why should they be judged on what time they leave? This mentality doesn't encourage people to work harder or be better employees, it only encourages them to stay later. That eats into their free time every day, giving them less opportunity to relax and recharge and probably causing them to become less productive and more prone to burnout in the long run.
If I can get my job done by 4pm every day then don't force me to sit at my desk until 6pm to keep up appearances. Either let me go home or help me fill my time by offering me more work (and if I'm highly productive, more compensation).
[0] The person is only putting in the bare minimum effort, has no interest in personal development, is more interested in the paycheck than craftsmanship and professionalism, etc.
In fact, Scott Adams proposed this in The Dilbert Future as a workplace scheme to improve productivity (he called it 'OA5'). He may be accurate in thinking it's up to the employer to destigmatise leaving 'early' (when in fact it's a symptom of an employee having a good work-life balance, providing his performance is sufficient).
However, I've been thinking about this recently - the logical extreme is that you should never expect the employee to turn up at work at all, provided he performs his tasks (say via telecommuting). Perhaps employers mandate 'desk time' because it's important to have regular physical access to the employee, for example in order to talk to him? I can think of HR/legal reasons where a private in-person interview is needed in order to inform the employee of something or to retrieve information from him. Consequently, if an employee only came in to work for these meetings, it would be obvious when the employee was engaged in some sort of 'serious' communication with the company. It would make mass layoffs especially conspicuous and difficult for the company to hide.
> 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.
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.
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 calling the leave-at-5pm programmers lazy. To them it's a job, and maybe even a job they're good at. I spend a lot of time living life outside of work, and I (usually) end up quitting after only about a normal day's work.
But I also get more done in my work day than 98% of "programmers". And the reason is that I've had a consuming passion to learn about programming techniques, tools, algorithms, and even logic puzzles, ever since I can remember. So some of that free time involves reading about programming; if I enjoy it, then it certainly counts as living my life. When I don't feel like learning something about coding, I do something else in my varied set of hobbies and interests.
The reason it would be nice to have different words for different tiers of programmers is that what I do is qualitatively different than what the copy-and-paste JavaScript writer is doing. I can certainly call myself a software engineer, or a game developer, or a graphics engineer, or a low-level programmer, but none of those really encapsulate it all; I also hit high performance server development, database optimization, networking, encryption/security, video streaming, and petal-to-the-metal assembly language optimization when necessary (though that's a skill that's less and less useful these days). And on top of that I write tools that help optimize the software development process for myself and my team.
When I look at what I do vs. what a junior front-end web developer does, calling what I do the "same" as what the junior developer does is somewhat akin to calling an assistant handyman and an engineer who designs skyscrapers or rockets or nuclear reactors "both engineers, because they both help build things!". All that extra work the engineer puts in to learn and hone his trade should be worth something, and having a title for it does help.
Something that bothers me about your coal miner analogy: The best possible coal miner is likely not more than 2x-3x better than the worst. Brooks' famous 10x performance difference only captures a small part of the real difference: There are things that I can do that a JavaScript developer simply can't do, no matter how much time they put in. Brooks was only measuring people trying to accomplish similar tasks, after all. And I'm not talking about domain expertise; I also follow and keep up with JavaScript and front-end development, and it's just orders-of-magnitude simpler than what I code on a weekly basis.
And I do find that puzzle solving (though not the physical kind) does correlate pretty well with the ability to do the high-end, hard-core programming that I do. I certainly am good at both, and it would be hard to imagine how I could solve the complex algorithmic issues that I solve on a daily basis if I couldn't think clearly about logic puzzles.
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 CPU and graphics card, designing and implementing for network security (including testing for HTTP headers, XSS, CSRF, etc.). What is it you do again?
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.
Fair enough. I think what we do is probably pretty similar, the difference being that I do it mostly in JavaScript.
Perhaps there is something to your point -- I doubt there are nearly as many successful "copy and paste C++ developers" (although I have met at least one). It might be harder to cobble together even a barely-working piece of software from StackOverflow C++ posts.
I've met a copy-and-paste C++ developer myself, though he ended up losing the job eventually.
Blew me away to discover this when I sat down to help him debug an algorithm that he had, in fact (correctly) copied from somewhere else, but then he'd slaughtered it trying to "make it work." Most of the fixes involved reverting his changes, and then making a couple minor modifications that WERE actually necessary.
He'd been fighting with it for a couple days. I had it streaming sound in about 15 minutes. Based on his words to me after the fact, he was really just not understanding what the code was doing. Pretty much at all.
That said, he did have some good insight into user interface design. I could see that he did have some important skill sets, but understanding how to manipulate memory in C was not one of them. Whether he was a "successful" developer is debatable, since he didn't hold the position, though.
I'm sure that "copy and paste" developers exist for most common languages. I've heard from several sources that finding a non-copy-and-paste developer who uses JavaScript is a real rarity. I've also been told that Google in particular is looking for that skill set. Sounds like you could write you own ticket. :)
>It's a job description.
Counter point: no, it's not. I coded professionally for 10 years. I'm now coding recreational for 29 years. (I'm 36, do the math) I contributed to various platforms, frameworks, libs, open source thingies. I have a shitload of code side projects. I'm the organizer of a quite popular code related meetup. I'm not a hacker, I'm a programmer. I don't code for money.
Nah you need to do a few coding boot camps and hackathons before you can call yourself one. Also, you need a git account full of forks of other projects that you haven't made any changes to.
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.