I'm a writer for a marketing agency, but I write Google App Scripts, JavaScript, and PHP on a regular basis to automate tasks, try out ideas I have, etc.

There's no way I could work as a professional software developer, but I know how to code enough to help make my professional/personal life easier and more fun.

Isn't there something to be said for that? Not every skill needs to lead directly to a job. Can't it just be another skill to have when you need it?

I learned to code through Codecademy and trial and error with frequent Stack Overflow searches. If I can figure it out, anyone can.

Edit: For anyone saying they would hire me, I'm flattered but am very happy working as a writer who gets to program occasionally. If you're interested, here are two little projects I've put together: http://playRollo.com and http://WriteByNumbers.com. Feedback? Email me, paulcole@gmail.com.

In architecture there is a trend of computational design - if you google for 'designed with grasshopper', you'll see some amazing shapes. The best designs don't come from the best programmers, they come from the best architects and designers who also know how to code.

Maybe it would be possible for them to become professional programmers, but I think it's much more valuable for them to be hybrids. Not every job can benefit from coding skills, but software is eating the world and learning how to code is becoming more and more widely applicable and useful.

That said, I think most people can learn to code, but I don't think _everyone_ can learn how to code. I have worked with a few people in menial jobs that I honestly don't believe could learn how to code. I realize that this is a pedantic assertion about corner cases, but I am a programmer. :)

Maybe that'll change in the future, but for now the wiser course may be to keep your superpowers to yourself.

Which is fine, but the tasks that go down that path aren't really enough to point me toward a full-time dev gig. So I'm in a weird middle ground between being a PM/BA/Developer without acquiring full experience in any of the three roles right now.

That being said, if I had to do it again I'd do the same thing. Just not sure how to navigate out of it.

Actually given the way our economy is currently structured, it's easier to get a good job as a developer having never written a line of code than it is to get a good job as a marketer even with 5+ years of experience. It might take you a couple tries to pass the interviews, but that doesn't matter because getting interviews is relatively easy. (Albeit if you don't have a GitHub portfolio, getting each interview will probably require you doing some take home assignment that will take a couple days for each company.)

There's always a few programming jobs that no one wants because the pay is awful and the company/job description is crap (PHP web apps for 28k/year? ROFLOL). But then they act as proof of employability for slightly better companies and soon you have 12-24 months of "professional" experience and landing interviews at OK companies is not unreasonable.

That's how a lot of us, no degree type, got our first foot in the door.

IT systems type roles are also a good segue into programming roles. And IT admin roles are so much easier to land.

Lotus Domino. Never Forget.

"client-server" VB6 apps with an MDB file on a NT4 fileshare passing as server is the lowest I've been lucky to have to deal with. Boy that was crap. That and actual cgi-bin script actually written in perl.

I suspect it broke me as a programmer for years!

As for family businesses, they rarely if ever hire software developers. They hire someone for a different role who can code, such as the "help wanted" sign I saw last week in Santa Fe looking for a sales clerk who could also maintain a small website front to back.

Amen. I'm constantly writing little Ruby scripts to do some automated task, usually fixing CSVs or extracting data to load it in a database to compensate for crappy reporting in a tool I use. I suppose that this or my recreational Clojure programming is something I could turn into a job, but I prefer to have it be a tool that allows me to do my job better. Or to run better D&D campaigns...

There definitely is a divide between like software engineer, and say person who uses programming to make their job a bit more efficient. It seems as though everyone is representing it as a binary choice when as paulcole said it's more of a gradient.

A lot of software interviews I've seen (and had to sit through) tended to be about tangential stuff like language minutiae, and whether you have memorized the Big-O complexity of the interviewer's favorite algorithm, and can you invert a binary tree without looking it up (because obviously we all code without internet access). Very computer-sciencey.

i liken it to any skilled trade. you can probably fix your kitchen table or change the brake rotor on your car but you're probably not qualified to work at a bespoke furniture shop or the porsche dealership - but you could be, if you really tried, or if you got lucky. and if you did get lucky, you could probably figure it out with some help.

some people just can't do these things, no matter how hard they try. they simply don't possess the aptitude, or iq, or whatever you want to call it. maybe just plain old discipline.

the interesting thing about programming to me is it's easy to lose - i'm totally unqualified to do anything serious these days because for the past 5 years i've spent most of my time running a business and doing 'housekeeping' technical (sysadmin, very light dev, some ops stuff) tasks that i don't want my senior devs to do.

You can code. The whole point the article is trying to get across is that a lot of people are simply unable to learn how to code. You've learnt. You CAN become a professional.

You just don't realize it.

The step you've taken is the hard one. In fact, there's another big dirty secret in programming.

A load of professional programmers aren't able to do what you can do, they can't make new programs. They can only modify existing programs. Making new programs is beyond them (or at least takes them an inordinate amount of time). Automating scripts to make their job easier is something that they would take weeks to do.

EDIT: I'm not sure I agree with the article though, I've heard several arguments that we simply teach programming badly. Especially in universities.

A load of professional programmers are not able to make new programs.

A load of professional programmers are not able to modify existing programs.

And a load of professional programmers are not able to finish programs.

Almost no-one is good at all 3. Most are extremely bad at least one of these.

Lots of people who are "good" at making new programs are actually pretty bad.

I'm bad at this. I'm not sure if this is caused by a lack of programming skills or a lack of project management skills.

But, try to actually take them up on the offer and you'll probably find yourself jumping through programming interviews that will scoff at your basic skills.

Most of us got started writing little scripts. It's definitely a great start. To say that he could work as a professional programmer now is ridiculous. Could he have a career if he put in the time? Maybe. Can he get a job? Maybe. But, it's not the slam dunk these people are suggesting.

Note that I'm not even differentiating getting past interviews vs actually doing the work. I think either would be a stretch from writing a few scripts.

Starting and ending one's programming skills with scripting is not a programming sin. For some businesses, there is a real, constant need fulfilled by someone who glues together data and systems with scripts. Personally not my cup of tea, but I recognize it works for some people and organizations; if those circumstances work for you, then that kind of job is nearly a slam dunk.

There is an enormous spectrum of software to be done. And not enough people to do it, currently. So getting a job could be very easy.

But, the point is a "professional software development job", not "something to do with computers"

I've never seen that work for actual software development, but I guess it depends on where you work/what sort of job you do.

I've seen it work for sdets though so who knows.

Working in a non-development group doesn't somehow make you not a software developer.

My point was the skills required in architecting a solution vs testing a given specific solution differ. So, while you can more easily fall/move into a automated testing role, it's harder to do so into a core programming job. The bar for moving into the latter, rightly or not, very much higher.

Personally, I think you probably aren't ready to actually interview and land a dev job. But, if people are saying they would hire you[0], this is a great chance to take them up on their word and in doing so, get your foot in the door.

[0] I don't believe them. You should take them up on it just to see what happens either way :)

I'll hire you.

I've worked in a marketing role in a software company and realize that I don't have the understanding of how to contribute in a meaningful way to a team-based professional programming project.

My workflow isn't ideal: bang my head against a wall, Google my way out, copy/paste/edit until things work, and move on.

Because I'm generally on a mission to get something done, I don't have the patience to name variables in a meaningful way or write clean code. I'm basically programming to accomplish something in the moment and it works for me.

To paraphrase the Woody Allen quote, "I'm not sure I'd want to work anywhere that would hire me as a programmer." :)

You might start as a junior dev but within a year you'll be talking the lingo, your toolbox will have exploded, and you'll be well on your way.

You have already demonstrated that you have the one quality necessary to be a good programmer. The ability to think abstractly and manipulate and express those thoughts in a concrete manner. Everything else is just practice and hard work.

To be fair, I am a programmer and I've had exactly the same thought over the years! ;)

I guess I finally have to get started with my work day... ;)

I've friends who are in the same boat and invariably the excuse is "I don't have the time to learn the theory, I have other things to do." Because of that, their workflow never really gets any easier. That's fine if coding is that side thing you do to make your job easier. That fails when it's what you want or need to do as an end to itself.

Also, I don't mean theory in the sense of the MIT "Introductions to Algorithms" book, I mean in the sense of the standard library, idioms, syntax and common usage of the languages and libraries you use.

I understand and almost echo that sentiment myself, but bear in mind that it may be an instance of impostor syndrome :).

Lots and lots of office jobs involve stuff like updating content on a Django app or shoestringing together Excel VBA and Access stuff. There's all kinds of tasks where scripts and low-level automation would be useful.

Now the tools for this tend to be awful and workers tend to be locked out of trying it, but that's another story.

Its not a silver bullet, but it is as a core component of developing of computer literacy, a broadly applicable foundational skill for non-menial jobs in the modern world, even if programming itself isn't a central duty of the job.

(In the right context -- though its possible to learn programming without developing much of this -- its also a valuable way, and perhaps the most accessible in terms of providing concrete feedback, to develop technology-neutral systems literacy, which is an even more broadly applicable, foundational skill.)

Someone who works primarily on small javascript web applications has a really different job from someone who works on a large application built on a LAMP stack, or someone who writes complex iOS applications, or someone designs self-driving car software for Google, or someone who works on embedded software for pacemakers, or someone who writes operating systems or designs programming languages.

Each of these jobs probably have a particular set of paths that lead to them. Two people who are both 'software developers' don't necessarily have similar skills, training or education.

A more interesting example is his "pacemaker embedded software" example. There's actually not very much software in a pacemaker. So that's an example of a field where engineering, process, testing & reliability skills are much more important than the ability to actually code. The coding in something like a pacemaker is usually done by an electrical engineer. A good EE may not be a good coder, but they should have the other skills you mentioned.

Do they?

If your job is primarily about taking other people's work and writing code based on it then, in my opinion, you don't really build software. You write code. There's nothing whatsoever wrong with that, but it's definitely different. Building software is much more than writing code.

Software development is working out what a problem is, what the solution to the problem is, and how to implement that solution on a computer. There should be time spent talking to users, gathering requirements, writing specifications, designing a user experience, developing a test strategy, thinking about stuff, writing documentation, and, at the end, a bit of coding. The non-coding side of software development isn't especially different between specialisms. So, really, software development in the sense of everything necessary to make a piece of software does require approximately the same set of skills.

That said though, the knowledge required in any given part of the software industry is very different. A web developer needs to know very different things to someone doing graphics or embedded development.

I would like to emphasise the last point you made. The coding skills, while broadly similar, are still different in each of those specialisms. Learning how to write effective code for a pacemaker is very different from writing a Ruby on Rails web app. They're both "coding" and you need the same kind of abstract thought, but you need to understand very different things to be good at them.

I think the commonality is that at the minimum you need to be able to read English at a proficient level, which weeds out the vast majority of American adults.

However large numbers of adult Americans when faced with:

  3x - 7/3 = 4

"90 million adults with limited health literacy cannot fully benefit from much that the health and health-care system have to offer."

"A two-year-old is diagnosed with an inner ear infection and prescribed an antibiotic. Her mother understands that her daughter should take the prescribed medication twice a day. After carefully studying the label on the bottle and deciding that it doesn't tell how to take the medicine, she fills a teaspoon and pours the antibiotic into her daughter's painful ear."

http://hospitals.unm.edu/health_literacy/pdfs/HealthLiteracy...

Like the government's official data on adult literacy?

http://nces.ed.gov/NAAL/PDF/2006470.PDF

After 1994 they got rid of the 'advanced' literacy ability category, corresponding to roughly the level academic journal articles are written at, because not enough Americans qualified. So currently the top literacy level is 'proficient', which is roughly the minimum level you'd need in order to teach yourself to become a competent developer. (That's basically the level you need to read a newspaper and compare and contrast the information presented in two different articles.)

However, linguistic constructs in most programming languages are not what I'd consider advanced English. A C++ program is hardly written in Shakespearean style, for example. And many words in programming languages do not exist in English per se; e.g., "def" from Python is not a word.

So, programming requires a more basic understanding of written English than you seem to imply.

Linguistic constructs in most programming languages can be at least as complex as anything in English, and aren't even English at all. You know how many experienced programmers have trouble dealing with programming languages with, to them, unfamiliar syntax? To someone who hasn't programmed, all programming languages have unfamiliar syntax.

> So, programming requires a more basic understanding of written English than you seem to imply.

That doesn't follow from the premise that "linguistic constructs in most programming languages are not what I'd consider advanced English."

"Proficient" literacy (the current highest level) for each area of literacy is defined as follows (from the document provided upthread):

Prose literacy: reading lengthy, complex, abstract prose texts as well as synthesizing information and making complex inferences

Document literacy: integrating, synthesizing, and analyzing multiple pieces of information located in complex documents

Quantitative literacy: locating more abstract quantitative information and using it to solve multistep problems when the arithmetic operations are not easily inferred and the problems are more complex

I would argue that programming tends to require literacy at that level in each category of literacy in that least one natural language (the language in which information about the programming language, etc., and the problem domain is available), as well as the ability to develop the equivalent degree of literacy in the programming language. (This isn't necessarily a prerequisite to learning programming, and especially in the case of early programming exposure, I think programming is a useful context for achieving a proficient level of literacy in a natural language.)

http://stanford.edu/~mkagen/codepoetryslam/

> “In particular, most people can't learn to program: between 30% and 60% of every university computer science department's intake fail the first programming course.”

Argh, I knew when I opened the article that its evidence would end up pointing to the "camel has two humps" study.

That study has been retracted, and the author regrets the damage it may have caused to computer science education:

http://retractionwatch.com/2014/07/18/the-camel-doesnt-have-...

> Though it’s embarrassing, I feel it’s necessary to explain how and why I came to write “The camel has two humps” and its part-retraction in (Bornat et al., 2008). It’s in part a mental health story. In autumn 2005 I became clinically depressed. My physician put me on the then-standard treatment for depression, an SSRI. But she wasn’t aware that for some people an SSRI doesn’t gently treat depression, it puts them on the ceiling. I took the SSRI for three months, by which time I was grandiose, extremely self-righteous and very combative – myself turned up to one hundred and eleven. I did a number of very silly things whilst on the SSRI and some more in the immediate aftermath, amongst them writing “The camel has two humps”. I’m fairly sure that I believed, at the time, that there were people who couldn’t learn to program and that Dehnadi had proved it. Perhaps I wanted to believe it because it would explain why I’d so often failed to teach them. The paper doesn’t exactly make that claim, but it comes pretty close. It was an absurd claim because I didn’t have the extraordinary evidence needed to support it. I no longer believe it’s true.

Some people are musically inclined, they can learn easily and fast and they tend to the best. But most people require some level of training complimented by the dedication of what amounts to mostly self-practice. So in a way, you're self taught.

The vast majority of people are willing to buy an instrument, just to see if they are musically inclined, but when they find out they aren't they don't have the dedication to do it the hard way.

Except with a musical instrument, anybody can judge whether you are good at it. Not so with programming. Everybody who ever wrote one line of HTML can call themself a programmer, but only trained people can tell whether you are a good one.

You might say at this point: so what? But I think the distinction is important, because it may be the reason the "driving force" is missing for a lot of people. If programming really had "rock stars" we might have had a lot more good programmers.

Can I be judged to be an accomplished musician upon that sole rendition?

It's the whole nature vs nuture argument. I wish I could have told myself many years ago to focus more on my "nuture" side. It's amazing how far you can go when you previously wrote it off as being not naturally inclined.

A computer is like a violin. You can imagine a novice trying first a phonograph and then a violin. The latter, he says, sounds terrible. That is the argument we have heard from our humanists and most of our computer scientists. Computer programs are good, they say, for particular purposes, but they aren't flexible. Neither is a violin, or a typewriter, until you learn how to use it.

Marvin Minsky, ``Why Programming Is a Good

I remember reading an interview with Andre 3000 a while back about how he composed "Hey Ya!". It turned out (this is all from memory) that the reason he used the chord pattern he chose was because he was relatively new to the guitar and those were the chords he knew. So in short, Andre 3000 was able to take very limited knowledge of a new instrument and produce something very compelling and interesting. However, this was certainly after a lifetime of building an interest in and understanding of music.

Shortly after reading that interview, I was hanging out in a music store, and a guy was amazing everyone with his acoustic guitar ability. He did some very cool stuff with his fingers while hitting a harmonic and going back down the neck, at a rapid pace, without faltering even slightly. He was available for lessons and corporate events.

Truth is, it actually is possible to do something very interesting with programming with relatively little experience, though you do need to be a creative and technically minded person. At the same time, you know, nobody would have hired Andre 3000 as a session musician. Sometimes I think that those coding tests, where you have to find the least common ancestor of two nodes in a binary tree, handle tricky threading issues while avoiding deadlock or race conditions, or doing complex outer joins, are really done by companies looking for the equivalent of a session musician. They're not saying you aren't creative or incapable of writing novel and useful software if you don't pass. They just can't add you to a band, at least not yet.

Lastly, I am increasingly in agreement with the last paragraph, which is that our "profession" does need to take initiative in determining how basic competence is established.

"If the main point of a professional qualification is filter out people who can’t code, does it really matter if what is being tested for is out of date, or irrelevant to current industry practices? Maybe our tentative qualification would involve the completion of a reasonably serious program in LISP?"

This is insightful. I've been very ambivalent about it, because I am scared of what happens through regulatory capture. But at this point, I do sometimes wish there were an industry-wide, well recognized exam that covered the paces that you go through when you interview at google, amazon, and small companies that are copying them. I've read/heard people say that they'd happily take such an exam formally if it meant they wouldn't have to re-take this exam, in a more capricious way, every time they apply for a new job.

I'm just as worried about regulatory capture as you are, but it might be possible to create a de facto standard exam in this vein just by making a good one and then relying on its merit to make it well known. I mean, fizzbuzz has already reached this status as an easy flunk-out interview question and lots of people take it as a positive test of programming ability. (Which it obviously isn't.)

The basic problem with an 'open exam' in this vein is that it is very easy to copy the work of others. So whatever problems you pick need to be things that are objective enough to be verifiable that someone has solved them but general enough that it won't be something where we all need to worry about whether you pasted your solution in from someones blog.

I've made my living by teaching beginners to code. I have been doing it for the better part of two decades, and I specialize in teaching students that have little aptitude for it.

In my experience, many students can learn how to code, but it takes a very long time!

For example, I make my students code FizzBuzz. It is literally the 106th project I make them do. That is, they have completed 105 complete computer programs before getting to FizzBuzz. And many of them still struggle with it. The nuance of else/if needing to be ordered in a certain way is something they still don't have a good grip on.

Programming a computer is very very hard for most people, but that doesn't mean they can't do it.

All my students are aged 14-18.

I admit my post has a lot of generalizations and I know Bootcamp people that are great engineers and CS grads that are not, but I think you get my point. I see a lot of frustration over this in /r/cscareerquestions.

I agree, but then I realize I live in a bubble.

Here and in /r/cscareerquestions, everyone knows to do side projects. In my school, most people don't. Neither do my friends in other schools. They may get one internship but that's the only "practical" thing they do (usually good enough to get a job though). A lot of my friends are much busier than me and don't have time to teach themselves stuff on top of school and life, at least not well enough to get a job.

Perhaps we need to stress a bit more practicality in CS curriculum?

No, we need to stop telling people who want a career in web development to get a degree in Computer Science. And universities should stop convincing people who really want to be software engineers to study computer science. If you want to work as a structural engineer you'll probably get a degree in structural or mechanical engineering. You don't get a degree in theoretical physics and complain that since structural engineering is just a practical application of theoretical physics your physics curriculum really should be more focused on practical engineering.

I sometimes feel like we should just call Computer Science what it really is, Applied Computational Mathematics. Because, you're exactly right, there is a disconnect between the teachings and expectations of most CS programs.

Then again, my CS program offered lots of 'practical' courses, like iOS and web development. They even created a BA program that removed most of the math requirements and replaced them with those vocationally related classes.

That sounds like great programs that all universities should offer. They just shouldn't call it a CS program.

Also agree, but we tell people to do it because employers ask for it. I guess it's a cycle, but someone's gotta stop it one day.

Rename it to SE first and stop pretending it's a "science". Or, alternatively, accept that it's really a science and stop moaning about the careers in the industry. There'll be a lot to moan around the grants, post-doc positions, publish or perish and all the other funny parts of an academic career.

As a note, the bootcampers we've hired have been people with a little bit of programming experience (not a ton, generally they did it as part of a previous job) that wanted to switch careers. The ones we've hired have been around 24/25, with about a year of experience in a different field like chemistry or geology.

The CS interns were college kids, so it could just be a function of maturity. I think of the ones we've brought in for internships, 2 were hirable (we've brought in maybe a dozen or so over the last couple of years). One of the 2 hirables is someone who I think will have a great career over the long run.

The bootcampers we've hired (thus far two) have been a measure above the CS kids. The CS kids have had a level of entitlement that I think is hindering them. It feels like because they've gotten a job they're set and they don't really need to learn more, when they have a long road to go down. This has been a pretty typical pattern and it didn't feel like they had the will to push themselves despite the fact that many seemed like they were very intelligent.

The bootcampers were older so they seemed to have that will and curiosity, none of them took the job for granted. One of them seemed to be falling behind, he was told that, and spent a lot of time outside of work learning the things he didn't know and has been great.

I understand anecdotes can only be taken so far, but just a couple of observations I felt like sharing.

I'd wager that almost every difference you've noticed is down to maturity.

The average 25 year old who's been working for several years is a light years ahead of the average 20 year old college kid when it comes to attitude.

If you were hiring 25 year old CS grads, they'd likely have the same work ethic, and an understanding of the formal methods underpinning their experience.

I can't possibly believe that with so many new hires the quality doesn't go down. And with the quality of the hires, also the product quality will inevitably go down.

That said, the problem is that many people looking to get software built can't properly identify what should actually be engineered. In the physical world it's a bit more obvious.

There's also huge subset of problems that look like something your nephew can hack together, until he does and there's a huge security flaw that leaks all your customer data.

That said, I have two problems with the article.

#1 - I don't like the idea of qualifications. Sure, the lack of career-path guarantees sucks, but that anarchy also benefits us. If I can get my hands on a computer, I can learn to code on my own (with lots of hard work, yes), build what I dream of, change my life. I can sidestep red tape, bias, prejudice, and credentialism that might work against me elsewhere.

#2 - I dislike the vague word 'aptitude', which the author uses many times. The idea of 'aptitude' may help distinguish Mozart from Salieri, but not Salieri from his cousin Fred. What I mean is, at the level most of us operate at, mightn't factors like motivation, persistence, and health affect us more than 'aptitude'? If the article replaced the word 'aptitude' with 'motivation' I'd like it better.

It doesn't require hard math, but it's still hard in that the sheer number of languages, tools, best practices, technologies is daunting.

And they keep changing. My father is an electrician, after learning the ropes from him, I went into low voltage, which he wouldn't learn how to do because it "keeps changing", meaning you had to take a little bit of time every year to learn some new things. Full stack web developers have to take significant amounts of time every day to learn new things.

I've seen devs who were perfectly comfortable with all the math and "real dev" practically break down when presented with a web project. More than one of them admitted to me after beating their heads against it for a few weeks that it was harder than it looked.

I can understand if you can't appreciate the difficulty. But try taking on a significant project before calling it easy.

What can I say? There is a tremendous amount of reading, trying, cursing, debugging, evaluating, forecasting what will be valuable later. Some of it is churn, true, and it is unnecessarily complex, but what isn't? (tax law, anyone?) Simplifying things is in itself a huge organizational, social, and mental challenge. All in all, it's pushed me past the edge of my abilities, and I constantly feel very ordinary in this field.

Because they haven't done it before.

Hard because you have to learn the framework of the week, deal with shitty tooling, and leverage design skills you haven't ever really had to develop is a very different thing than hard because you have to design and build a complex system with strict requirements and intractable problems.

That sounds like web dev. The intractability of the problems comes from the fashion-like nature of how often things change and the speed at which they have to change. The more you learn, the more you can do, but also the requirements will change as a function of your abilities. Maintaining an business advantage demands it.

The framework doesn't have to change, the tooling can be self-designed, the design skills can be learned, and web dev remains hard and interesting. I understand that lots of devs don't appreciate it, but I still find it interesting after 5 years, and expect it to remain so after 20.

I liken it to a craft, take woodworking as an example. Sure, anybody can learn to bang nails into wood. But the way you hit a nail into a piece of wood the first time is going to be way different than the way you bang it in after 5 years, and it's going to be a totally different experience to the way you bang it in after 40 years.

There's a definite craft to choosing frameworks, growing tooling, and fashioning design to solve interface problems.

Is it as hard as hard math? No. Is it harder than 99% of people can do at all, and harder than 80% of software developers can do well? I fully believe so.

And still, given all of that, my head spins about the idea of building a compiler from scratch or writing MIPS.

Historically for me, I'm sure that kind of attitude pushed my clueless bosses into thinking I'm some kind of semi-skilled lackey that can readily be replaced with outsourced staff or graduate hires. It's kind of a self feeding one, because if they do outsource it works for a while, until a kind of critical mass happens and it starts falling apart. The confirmation bias after making this call also makes it almost impossible to undo.

I'd disagree on one point - and that is that programmer is a synonym for software developer. It's one thing coding yourself up some scripts at home, another thing altogether building a reliable, scalable technical solution within a (possibly large) team. All software developers are programmers, but not all programmers are software developers.

They're complex arguments to justify the attitude that "only we chosen few (men) with serious tech degrees are gifted enough to do important work in code."

Tech is a big, prosperous industry and will be bigger if we act welcoming rather than creating complex arguments to protect our turf.

Disclaimer: Am a white male with a CS degree who runs a coding bootcamp.

> Let’s stop pretending that there are artificial barriers to entry and accept that the main barrier to anyone taking it up is their natural aptitude for it. Instead let’s work on improving the social status of the software industry – I think this is in any case happening slowly – and also work on encouraging talented young people to consider it as a viable alternative to some of the other top professions.

I'd say he's arguing about getting more of the right type of people into the field, rather than pretending it's something anyone can do, and getting the wrong type of people into it.

If we (as in software developers) were trying to "protect our turf", all we had to do was to continue with what we're doing. The new candidates will be terrible, the potential good candidates will be somewhere else, and we'll be "safe" atop the knowledge tower we built.

Sometimes, you either have the capabilities to do the job, or you don't.

It's considerably easier to get a top-tier CS degree if you're a female or a minority.

The standards are ridiculously low. Most of my coursemates (final year CS students) are literally unable to write software. They can write a single-file cpp file in Code::Blocks on a good day. In my experience (and having talked to plenty of other CompSci students, their experiences are similar to mine), formal education in programming is generally reduced to teaching students all about recursive functions, bubble sort and those kinds of things. There has been a grand total of 0 lectures or labs about unit testing, version control, API design, interoperability, etc. Let alone trying to communicate the idea of "clear, maintainable" code. Only a very small minority of people can write code, yet most of us will graduate.

I have a module called "Software Quality and Process Management" (formerly known as "Large Scale Software Engineering". Good thing they changed the name, at least now it's not such a blatant lie). In this module, we learn all about COCOMO, and how we should estimate the number of lines of code a project will use, and use that to figure out how many man-hours are required to complete it. WTF. I'm preaching to the choir here, but that's like estimating the amount of effort it will take to design an airplane based on the number of grams of aluminium in it. When someone raises their hand and disagrees about the relationship between SLOC and person-hours (or even about whether person-hours is a reasonable unit - it's not), the lecturer responds with a blanket "you're entitled to your own opinion", but draws blanks when asked about whether they know anyone who actually uses these methods in real world software engineering and finds them useful. It's the same story when they teach about the waterfall development process and other similar outdated practices that are known to be detrimental to healthy software.

The vast majority of what I know about software engineering didn't come from my time at University, and almost all of the software engineers I know have had a similar experience. I know correlation does not imply causation, but it's definitely food for thought.

(Incidentally, the university refused to corroborate his degree, on the grounds that it would be a breach of the Data Protection Act, which boggled my mind).

> could not explain to me what Functional Programming involved

See that first term, give him/her a break.

I've worked with experienced devs with many year's experience who couldn't explain the term functional programming, yet practice it every day. Just because you don't know the fancy programming term du jour, doesn't mean you aren't capable or competent.

Turns out I've been using the functional programming paradigm since 2001. It wasn't until six years later I discovered there was a name for it.

What I learned in Automata, Discrete Math, Algorithms, and the other more theoretical classes has been worth it's weight in gold.

The things I learned in "Software Engineering" on the other hand, not so much.

That was my intention when I signed up for University too. However, I've only had two maths modules, and they haven't been particularly challenging.

One of the things I was looking forward to learn at University was hardcore cryptography, since I believe that's one of the few things for which getting formal, structured education is the best way to go. Sure, you can learn the fundamentals on your own fairly easily (even more so today - Stanford's online course in cryptography is very good), but you need to learn about attacks or you'll write code vulnerable to known problems like hash length extension attacks, ciphertext modification...

However, the only time cryptography was mentioned - at all - in my entire BSc was in first year, where we had a few lectures explaining the rudiments of RSA. Interesting, for sure, but pretty much useless without the remaining 80% of knowledge required to have a full picture of what's going on.

Guess what todays topic was? Software Estimates! (that includes COCOMO)

The teachers even acknowledge that the waterfall process is bad.

I don't really see the point of the vocational college. I am learning all the practical skills at the company already.

I think this describes almost all undergraduate degrees. The only ones I can think of that go against this are the 5 year engineering programs, and I liken those more towards a masters than undergrad.

The analogy people in my company like to use is that everyone learns to write, but not everyone becomes a novelist. Everyone learns arithmetic, not everyone is a professional mathematician. Everyone takes science classes in school, whether or not they intend to be a scientist.

Coding is pervasive enough that is is worth at least learning the basics. If you turn out to like it and be good at it, go ahead and pursue it as a job. Otherwise, those basics are just a part of modern literacy.

On the other hand, beyond the borders of the colonial-imperial mindset, we have kids in the slums who - precisely because they were not given the 'golden ticket' of opportunity presented to a select few - had to actually .. you know .. do the work of becoming a very good developer.

Good developers are not limited by class.

(disclaimer; have lived and worked with many good developers around the world, and it has nothing to do with education and everything to do with spirit..)

I think the author would be very happy admit your hard working very good developer friends into the set of 'good programmers'.

Many other professions are the same way, even the doctor example. They constantly have to be learning to be great and the ones who stop 'learning' and teaching themselves are the doctors I wouldn't want to treat me.

I also see, across many professions, the ones who are at the top of their profession are the ones who have the ability to teach themselves. In college, you learn very quickly how you learn. Some students have a very hard time learning new concepts on their own, they must attend a lecture and have interaction with the professor. However, on the other side of it, some students get very little benefit from lecture. I would know, I was that way. In a lecture I would always be doing something else, that's if I even went to the lecture. I much preferred to teach myself, and when I run into something I didn't understand, I found the resources that made sense to me to understand something. This is what you have to do in the real world. Every student needs to have the ability to do this in any profession. There is no, 'I finished school, I'm done learning...'. You will be mediocre at your job at best if you have that mentality.

So yes, programming is hard, being a doctor is hard, being the top percent of ANY profession is hard.

Here's an example:

    Q: write a program that reads 2 numbers from standard input, 
    and outputs their sum. For example:
    First number: 3
    Second number: 7
    Sum is: 10

    print "First number: 3"
    print "Second number: 7"
    print "Sum is: 10"

This supports the original article in one way by saying that it's not for everyone and bootcamps for the general public are not going to help much, but it contradicts the secondary point which is that we should be convincing potential doctors and lawyers to start learning CS. Programming aptitude doesn't start with intelligence or background, rather from something innate.

[1] http://blog.codinghorror.com/separating-programming-sheep-fr...

http://www.eis.mdx.ac.uk/staffpages/r_bornat/papers/camel_hu...

While a consistent mental model for things like assignment is a good sign, not initially having it doesn't mean you can't learn how to code. Lately, researchers have found that certain pedagogical techniques (especially pair programming) are pretty effective at overcoming these deficiencies.

I wish I could understand why so many programmers are eager to assume their skills are due to something 'innate'.

That's interesting. Its interesting to me, because -- while I may or may have developed the aptitude independently later without this -- I actually spent a lot of time when I was first learning programming, in elementary/middle school in the 1980s, pair programming (though, you know, the name wouldn't be coined for quite a while) with my dad.

> I wish I could understand why so many programmers are eager to assume their skills are due to something 'innate'.

One reason might be because if anyone could learn it, programmers wouldn't be able to view themselves as special.

Another might be because if people realized everyone could learn it, programmer salaries would fall from increased competition, so programmers have financial self-interest in people not believing that most people can learn to code if they try, especially if its true.

Well, no, because "everyone can learning plumbing" is pretty widely accepted (and has been for quite some time), so the effect of that belief being accepted is already reflected in the current market price. (OTOH, the price is lower than it would be if it were widespread belief that becoming even modestly competent at plumbing required unusual innate gifts that most people lacked, and that attempting to learn plumbing was a complete waste of time for people lacking those gifts.)

> I wish I could understand why so many programmers are eager to assume their skills are due to something 'innate'.

I'm not eager to assume that but it lines up with my experience over the years learning how to program and helping others do the same. It seems like it comes easily to some and harder or not at all to others. When I first read summaries of that study, it sounded correct based on my experience.

Going a little further ... I will say there's something enticing about thinking that you have a special skill that others do not and that you've found purpose for that skill. It's a bit like "finding your soulmate" in a way. I think a lot of us, myself absolutely, want to find that thing that we're good at and were made to do.

Might also be good old fashioned ego :)

At my level (third year Computer Science classes), I've had the following class composition:

- 2 classes dedicated to learning C++ (COSC 1010 was skipped, but included here for numbers, and COSC 1020)

- 2 classes dedicated to algorithms in C++ (COSC 2030, 3020)

- 1 class dedicated to math (COSC 2300, discrete structures)

- 1 class dedicated to functional programming (3015) (mostly proofs related to recurrence relations)

In the future, it looks like my courses will be filled with networking, operating systems, compilers, and a couple other math topics.

The problem is that most students only get a very foundational introduction to programming in this program. Students are tasked with writing code, but only limited quantities in very specific areas. That's algorithm development and implementation.

The answer might be that students should be taking software development or some other degree, but right now CS is the route most students try to take to become developers. This isn't a good approach, because at the end they have very little development experience -- only some algorithms and knowledge of computers.

I too would answer with "self taught" for how I learned to program -- definitely not from this program thus far.

Obviously these are generalizations, but that's what I have seen in my experience.

What an arrogant, false, and self-aggrandizing fiction. Stop over-valuing yourself -- coding isn't some ultra-difficult natural selection process equivalent to winning an NBA Championship.

Designing complex services, scaling and maintaining them on a server stack is hard. Developing, training, and shipping a useful deep-learning network and making it into a useful product is hard. Coding is not hard.

I get sad when engineers, especially ones who's tone seems vaguely threatened, start writing up these discouraging blog posts belittling 'noobs'. Its a pleasing fiction that software engineers are just 'naturally better' and therefor their jobs are ensured. I think that anyone who says this has likely not been in the industry for very long -- because they would have seen scores and scores of devs left behind due to not training up and getting beaten out by upstarts who teach themselves and do well.

Coding requires a turn of mind that at least half of the population lacks: abstraction. You must be able to map a problem space into a form that is amenable to decomposition and solution using data and instructions. I think most technically inclined folks would be surprised how many smart people lack this ability (like doing basic high school math). Many others lack basic skills in logic, or the ability to define a reliable procedure. (I say this after 60 years of life, working in both white collar and blue collar settings). It's not that these people are stupid. Their minds just don't welcome abstract thought and the hierarchy of formal sequential models that is code.

In my experience, the set of skills peculiar to writing software well is surprisingly uncommon.

But that doesn't mean no one can learn it.

Playing the saxophone is quite hard but a lot of students learn how every year, to varying degrees of skill.

Are there studies that took n people from different backgrounds, completely unfamiliar with coding, and tried to teach programming over the course of several weeks/months, and found that the majority were not able to get to an acceptable level ?

Not being rude, but I'm trying hard to figure out if this comment is parody/sarcasm or if you genuinely believe this fantasy?

The biggest thing with coding is finding something you like... Passion is the key here. Some things will come easier than others but if you're passionate, even if you're not a bloody genius and it takes you many times before you get something, you'll spend enough time and eventually get it. And over time you'll get better and better.

In 12 years working in the field I can say I've worked with a fair amount of devs. I've worked in very small software companies, medium sized companies and fortune 500 companies. I've worked with self taught devs and people with degrees. The biggest difference between someone who's great at their job and not is not the education but the passion. Its not even the book smarts. Some people are smart as hell but just aren't passionate and don't enjoy what they do at all. Every year your job feels a bit different. Languages evolve, technologies evolve, libraries and frameworks evolve. You're constantly working with new things. Some don't feel 100% different, others do. Once you've learned a bunch, some new concepts are very easy to grasp. But at the end of the day, if you hate it, you probably won't keep up and will quickly be obsolete. Most new jobs will require a lot of learning. If not new languages then new processes, infrastructure, code bases, etc. If you're passionate enough to keep learning and patient enough to spend the time it personally takes you to grasp concepts, then you can learn.

Its not for everyone. True. But not everyone will be developing physics engines for games or deep learning algorithms.. Some coding skills are easier to grasp than others and most people can, given time, become decent at some of it.

... and it only takes 10 years to become a doctor.

* Get a degree

* Don't get a degree, go to a bootcamp/teach yourself

* Do side projects

* Get an internship

* Network and go to meet ups

* Learn algorithms and data structures

* Practice brain teaser questions

* Learn these languages

* Learn these languages' frameworks

I'm exaggerating and people can get hired by not know all (or any!) of these, but you get my point. It can be a confusing and overwhelming path both for people who want a career change or are graduating from university.

For some, the path to being a doctor is "easier".

"Can't code" is the new "can't do math". What it really means is that the person doesn't want to code (or to do math), not that they cannot do it.

But the "learn to code" efforts that are referenced serve the important purpose of exposing people who might have aptitude to the idea that they can realize that aptitude. I imagine that people without the prerequisite aptitude would just quit because it wouldn't interest them, and those who can cut it would continue on auto-didactically. I'm not trying to be too critical, but criticising those efforts with the idea that "it is hard, you probably can't do it" is unhelpful at best.

Experienced devs could take on an apprentice for a year, kind of like an internship, and the apprentice moves does 3-5 of these before moving into a dev role themselves.

https://8thlight.com/apprenticeship/

In my humble opinion, this is because the pedagogy sucks. Intro CS classes tend to teach in a very weird way, with very conflicting goals. Is the point to teach your way around a linux shell? Tooling? Basic programming? Algorithmic thinking? Good engineering practices? To teach automata theory? Complexity theory? Most courses answer "ALLLLLL OF IIIIIIITTT!"

Further down the article, you see that there is a large percentage of self-taught programmers. I suspect that this ratio goes through the roof if you ask "have you done a lot of CS / software learning on your own".

This is because self teaching lends itself better to learning and practicing over and over the diverse variety of skills required to be a successful programmer. Intro classes go very quick and fail to instill any of that. So those who are successful are a lot of times those people who are already long exposed to computers, algorithms, programming or the ideas accompanying those in some shape or form. Or those who find it immediately fascinating and put in much larger amounts of time than a course would normally require.

Those folks who simply haven't had a lot of time programming struggle, and eventually they drop out. And nothing changes to improve this because part of the class succeeds, and thus the conclusion made is that the part that dropped out must have been "bad".

There's a false dichotomy here. Yes, programming is difficult. Yes, being successful in the real world requires a lot of work. And yes, like any craft, the rabbit hole only goes deeper. But the conclusion here isn't that most people just "don't have the aptitude necessary". Most people, given the same time and guidance, can succeed.

The most important part is that getting somewhere immediately /useful/ can be quite quick. That's where programming shines - reasonably low investment costs for a moderate benefit for a lot of people, which eventually rolls into a high investment cost for a massive benefit.

>The current fad for short learn-to-code courses is selling people a lie and will do nothing to help the skills shortage for professional programmers.

Outside the obvious lack of definition as to what a "programmer" actually is, this is a non sequitur (the conclusion doe not follow). There's an assumption built in that those who do possess a high level of aptitude already have CS degrees or are self-taught because it comes to them naturally. What if there are people who possess that high level of aptitude and they want something to help them learn in a structured way?

Extrapolated, the author's argument could be seen as, "Sorry, there's no point in teaching programming, because everyone with the aptitude to program already knows how to program," and I think that is a recognizable falsehood, if only anecdotally.

In other words, even given the assumption that programming does require a higher aptitude than some subset of the population does possess, there is no surefire way to determine who that subset is based on credentialing.

Sounds like a reasonable argument to me.

But I learned enough that when I lived in Ukraine I understood a bit of what people were saying, I could communicate somewhat, and a couple of years later I was reading Tolstoy.

People think about bootcamps all wrong. You don't leave like "holy shit I'm a master programmer." You leave knowing, "OK, it'll take a while longer, but I can contribute a bit now, and I'll pick up more as I go."

I think it's fine to compare learning to write code with learning to write human language. The best of us will still make mistakes; plenty of us will always be incapable of writing well. Once upon a time the idea that everyone needed to know how to write was laughable. These days, it's arguable how well everyone needs to be able to write, but there's a general agreement that it's worth giving people the opportunity to reach at least a basic level of competency, even if their daily lives require little writing.

I had a miserable time learning to write (i.e., failed many assignments) until a few things fell into place, and I saw how writing could be an important part of thinking, learning, feeling, expressing, etc. I had a miserable time learning to code through coursework in highschool and college until a few things fell into place and I saw how code could be an important part of thinking, learning, feeling, expressing, etc.

How did/do we sell everyone on trying to learn to write human language? AFAIK, with some superlative rhetoric about how useful/necessary writing can be without much dithering over what portion of the population will ever be good enough to make a living at it.

So there are varying levels of irresponsibility when it comes to saying everyone should code. There's probably a big potential social upside to fudging things a little to suggest everyone should learn some programming throughout school; it's much more negligent to tell someone with a boring but stable job to quit and blow a few grand on a coding bootcamp without an inkling that they're prepared.

No such evidence, at least not in any respectful sources.

> will do nothing to help the skills shortage

Who said that this is the immediate goal of teaching as many people as possible to code?

> Given the skills shortage one would expect graduates from computer science courses to have very high employment rates.

This logic is broken on so many levels that it's even embarrassing to comment. Let's start with a trivial nitpicking that Computer Science education got nothing to do with the Software Engineering.

> there are two populations: one that finds programming a relatively painless and indeed enjoyable thing to learn and another that can’t learn no matter how good the teaching

It is really embarrassing that the guy who wrote it calls himself a programmer - i.e., someone who is supposed to be logical and rigorous.

There are far more categories that these two. And the most important category, targeted by all the programmes he's mocking, is the people who do no even know if they'll find programming enjoyable, because they never tried.

I don't think programming itself is hard. Most people program. It's just that they do it without thinking about the steps they're programming, and they do it without a computer. Parents program all the time, "If you don't finish your homework before 7 PM, then you will not get dessert!"

I think this is an article, and one with votes on here, because it's flattering the audience. Maybe say complicated mathematics is hard. But not "coding". That's what dumb people like me do who prefer to stay inside and play around with text on a computer. Of all the possible jobs I can think of, coding is near the bottom of the list in terms of difficulty. Anything involving a jackhammer is much rougher.

I've made my living by teaching beginners to code. I have been doing it for the better part of two decades, and I specialize in teaching students that have little aptitude for it.

I make my students code FizzBuzz. It is literally the 106th project I make them do. That is, they have completed 105 complete computer programs before getting to FizzBuzz.

And many of them still struggle with it. The nuance of else/if needing to be ordered in a certain way is something they still don't have a good grip on.

Programming a computer is very very hard for most people.

I've noticed that the industry really prides itself on algorithms and this is commonly reflected in interviews.

However, it seems to me that merely discussing algorithms, however clever they might be, is actually an intuitive human activity not unlike the example of the parent verbalizing procedural instructions to their child. Therefore, I would argue that algorithm design, though clearly an intellectual challenge in its own right, does not target the essential part that makes programming hard and inaccessible to so many people. (Disclaimer: a high-level algorithm discussion is usually followed by whiteboard coding, which I'm ignoring in this critique as a separate kind of activity).

Do you agree with this claim that algorithm design is not actually the thing that makes programming so difficult for laypeople? Can you give your take on what does make programming hard or what students struggle with the most?

Are you familiar with the concept of "chunking" in memory research? Well, computers don't chunk but humans do. Humans tend to think about their algorithms in terms of the chunks they already know, but for computers sometimes each chunk has to be broken down into much smaller sub-steps.

And that's non-intuitive and hard. When explaining stuff to a human you get immediate non-verbal or sometimes verbal feedback if they don't understand the chunks, but computers just give a syntax error.

SECONDLY. Students have trouble making an accurate mental model of what the computer is doing at each step, so they can't trace through the code, much less create new code.

Those are the two biggies, in my experience.

The evidence presented is fairly poor, and consists of:

(1) failure rates of university first courses in programming for majors (which could indicate how hard it is to learn programming -- or how poorly designed university first courses for majors in the field are for the audience they attract.)

> I don't think programming itself is hard.

Actual coding isn't all that hard, once you have the foundations. But structured problem solving is a key foundation, and isn't all too often deliberately and effectively taught outside the context of programming (and, unfortunately, often isn't effectively and deliberately taught with programming, either, but programming seems to be the most common context where it is taught.)

> Most people program.

I don't think that's even approximately true. Most people do not plan out detailed step-by-step process from inputs to desired outputs that are expected to be successfully implemented by an execution agent that is perfectly literal and exact and exercises no independent judgment and has no ability to fill in the blanks and do what you probably meant given their understanding of the desired outcome even though you failed to specify it.

Even preparing step-by-step procedures for human agents is hard, not done a lot by most people, and done poorly by most people who do it, because most of them do so without good training.

System/process analysis skills that underlie both programming and procedure development may not be hard, but they are not skills that most people are taught effectively.

Being an electrical engineer is just connecting 2 wires, right? Being a programmer is just booting up your text editor, right?

Becoming a good programmer doesn't require a degree but it helps to set a good base for your knowledge. On top of that you need thousands of hours of self teaching.

This movement will create a few good coders from children, but also make more haters against the profession.

The first one is the main thesis of the post which is that some people have an innate ability to program that others do not possess, and that this is a thing that cannot be learnt. As a result, telling people that it is "easy to code" is a lie.

Firstly, it is actually not clear to me that this ability to pick up programming principles cannot be taught. All we know is that our current methods of teaching yield a double hump distribution for programming ability.

Secondly, if people were actually saying "you will find coding easy" to anyone and everyone then I agree that they are probably concealing the truth. But actually, if you read the tagline on the example given (The Year of Code initiative) it says:

> Start coding this year, it's easier than you think.

"It's easier than you think" (emphasis mine). This is quite a different statement to a flat out "it's easy", and it's one I agree with. To most people, coding appears difficult because they simply don't know the answers to a few key questions (E.g. Where do I write the code? What do I do to run my code? How does the computer understand what I've written?). The (basic) answers to these questions are comprehensible to most people, and furnish them with the ability to write code (maybe not well, but that's a whole other story).

Next observation:

> Folks, which industries/professions give up their own free time to provide free/open training to people wishing to enter the sector? Curious

The fact that only the software development industry seems to do this is painted as a negative thing in the article. Why is that? I ask because this is a fact I think we should be proud of. I personally enjoy what I do so much, that I happily spend time out of my week, teaching it to others for free. I don't do this because I think all the people I teach will go on to become successful software engineers, but rather because I want to widen the net, and expose more people to what we do, because for some of them (maybe even just one of them) this might be their "true calling".

I got into programming originally from watching a cousin of mine editing the themes of his Wordpress blog. He went on to study English Literature and Psychology; To him, coding was just this tool that allowed him to publish his views, but to my 9 year old self, watching him, it really struck a chord and I was hooked. Now, there is not a thing in the world I could imagine myself doing rather than writing code and loving every minute of it (And no amount of "social status" is going to turn me to a life of law, medicine or architecture). What an opportunity I would have lost if I had not seen my cousin working on his blog... Every week-long learn to code course, and every "hour of code" initiative works towards bringing such opportunities to the wider public.

Finally, on the role of Computer Science degrees: I am currently in my final year of a Masters in CS, which I have also enjoyed studying immensely. I would not say that it has contributed directly to my skills as a software engineer, but the things I have learnt have changed the ways in which I approach problems. Very few people write structural induction proofs, loop invariants or abstract specifications to prove the correctness of their programs, but I have found them to be great ways to think about how to write better code. These skills, however, are complementary to those that make a good software engineer, not a substitute. There's no way to prove yourself out of a rat's nest of class hierarchies and control structures.