So we shouldn't tell people learning to code is easy, we should tell them it's hard, complicated, exhausting, and exasperating, but it'll be worth it in the end?
Why not just give them some easy code, help them through it, and let them see if they enjoy it?
Are you sure about that? Lots of hard-to-do things are said to be easy by those who know how to do it. You might not think being an architect or writer is easy, but someone who is an architect or writer has a clear picture of how to do it, and they might say it's easy.
I have yet to meet a medical doctor saying "medicine is easy" - because it would diminish their status, salary and they love to brag how it is the hardest thing to study.
If you run around telling people how hard programming is they'll never even get to the point that it does become difficult. That's why we tell people it's easy.
Surely there's a middle ground right? Being a surgeon is hard, being an astronaut is hard... there's a lot of jobs popular culture says are hard but it doesn't stop people from trying.
The thing with programming is that it's turned into one of those things people say "you are born for". So when newbies have trouble with it, they give up and say their minds don't "work that way". I think it's good to tell people that anyone can learn the basics of programming and get started. No need to be a genius for that. I don't know why but people seem to think programmers are "different" than the general populace (even from those with other hard jobs).
But it's not easy. We've all dealt with hard problems in our jobs, classes, or personal projects, right? If you tell people programming is easy they'll hit that first roadblock like the article says and quit. Seen it happen many times.
This doesn't seem true. There are plenty of jobs that are commonly regarded as being hard and yet they attract plenty of people.
I think you also drastically underestimate the number of people who are specifically interested in hard things, not easy things. And in many cases these are exactly the sorts of people you want to hire.
I am going to support Cory Koski's comment on your post:
I don't know what your intentions are, but you have a post titled "Stop saying learning to code is easy" and a photo of three women with laptops. Are you trying to make a correlation of women being glib about the difficulty of software development/programming?
I don't know why the parent post is even trending on HN, it's content-less trivial fluff, but I also facepalmed at the inclusion of the picture. I'm not a supporter of the idea of the "patriarchy" meme, but putting this picture on a post like that certainly implies at least an unconscious association in this guy's mind. Good thing he's a "former professor".
The three young women are programmers sitting in the NYC Microsoft office. They are my friends and the image is part of the WoCTechChat CC Image collection. There is no correlation. Flip a few coins and it could have been three men or a combination. Sorry if it felt correlated, it's not.
I'm not sure I agree. The title doesn't match the content. The title contends that learning to code is hard, and I've never heard anybody disagree, learning to code is difficult. But then the content of the post contends that coding itself is hard. And I disagree. Programming difficulty is a function of a huge number of factors. Among which familiarity and experience are paramount. If you're writing a program that's familiar to one you've written before, programming is easy. If you're writing a complex new system with little to no precedent, programming is hard. There isn't a blanket statement that can be made about the difficulty of programming, it is all contextual.
Except it is easy. In fact, it was designed to be easy by the language architect. Unlike engineering where you're dealing with unchangeable laws of physics, computer languages are designed to be written by people.
Programmers are still dealing with the laws of physics. This is why you get 10,000 asynchronous communication platforms all generally failing to result in massive improvements in usability and parallelization. Most programming problems are communication problems, and most communication problems are a result of physical limitations.
While, yes, you can't run CERN on a raspberry pi, the performance limitations of the underlying CPU are a fundamentally separate problem (unless you're developing for a microcontroller). Going out and writing code (any code!) is a purely mental exercise that's unaffected by the outside world. Don't like the syntax? Use another language! Want a feature that's not currently there? Import a library! The point is that code was meant to be written, whether it relies on a physical processor or not. You have lots of different options that each try to make it easier for the programmer.
That's not entirely true either. Computer programming is largely performed using text in a 2d grid, and there are a good deal of problems not suitable to being represented that way. Language designers have to deal with this when deciding what syntax to support, and how that maps to the desired semantics. This is one of the reasons for the proliferation of so many different languages in the first place.
> where you're dealing with unchangeable laws of physics
The language of mathematics is also designed to be written and understood by people, and is used to describe the laws of physics. I, personally, find writing mathematical statements be comparable to writing code (and also Latin).
Well, writing something in a programming language is the easy part, but it's not sufficient and not the main part of being a programmer.
If you can write in plain but exact English what exactly do you want the system to do and how to do it; and what you wrote actually solves the problem that you intended, then you did 90% of the programming work and have 90% of the required skills. Yes, you'd still need to code that in a particular programming language so that "the computer would understand", but doing that takes a tiny portion of the total work time and learning the skills to do that also is simple and fast compared to learning how to do the first part properly.
On the other hand, if what you described actually describes something slightly different from what you wanted (which is very likely) and doesn't describe the behavior in a bunch of things that you didn't think of (which is even more likely) then the skills in that computer language or the "design by the language architect" won't help. And fixing issues like that take up the majority of programmer-hours in any nontrivial software project.
Sorry. I understand the sentiment behind this but disagree with advisory or demands to speak a certain way. It's blatant political correctness and nobody has an obligation to set another person's expectation regarding coding. In common vernacular we say something is easy as an attempt to encourage a person to continue. This would just be changing words in order to achieve the same goal. What difference does it make if some say it's easy and others say it's hard? Let the dynamic range of opinions be. Is it necessary to squash one opinion over the other in an attempt to soothe the struggling of a few newbies?
I find meta-arguments like this really silly. You are simultaneously telling him that people are entitled to their own opinions while at the same time saying his opinion is invalid.
As to it being political correctness, I would argue that has little to do with it. It's really marketing - an attempt to change the perception of something to achieve some goal. No one's feelings are hurt when you say something is challenging (I guess unless you explicitly say challenging compared to what).
I really feel like current salaries are too much to bear for honchos of the industry and that there's been a recent push to make it seem like "programming is easy" and "everybody can take up code". I agree that the learning process has been made much easier than it ever was before (MOOC, screencasts, collaborative learning, cornucopia of open source code available everywhere), but that's only the first step in the learning process.
That part (the one that leads to being able to produce code) has actually always been rather "easy". It's the next steps that are usually hard. Learning data structures, design, architecture, how to collaborate with coworkers, how to fix, debug and review code, mastering the associated tools (shell, git, regex, making a given editor your home and harnessing its power, etc).
From what I've observed with more junior developers that are usually coming through self-learning or accelerated programs, it's not the "code" that is hard, it's those following phases because in the end, they're what really matters.
Though, don't get me wrong, it's absolutely nice that we're pushing programming literacy and making it more accessible for everyone, I just feel like we should not be selling false hope.
> Learning data structures, design, architecture, how to collaborate with coworkers, how to fix, debug and review code, mastering the associated tools (shell, git, regex, making a given editor your home and harnessing its power, etc).
I learned all of those things way after shipping my first usable and useful code. These things don't make the programming learning curve steeper, they just make it longer.
I agree, you can do awesome things without too much coding knowledge—but a big part of the current push to teach people how to code is to give them access to the coding job market.
If I'm going to hire you as a "software engineer" at an engineering salary, I expect you to know all those things.
Of my friends learning to code for masters degrees now, the ones with a natural coding mindset and studying it hard are taking about 2 years to hit a production engineering level. Most seem to be on a 3-4 year trajectory. That's pretty reasonable for a complex skillset.
> I agree, you can do awesome things without too much coding knowledge—but a big part of the current push to teach people how to code is to give them access to the coding job market.
Makes sense, I guess I was thinking more of the potential in teaching kids how to code so they can use that knowledge as biologists, economists, teachers, geologists and so on. Standards there are lower because you're competing with people who don't or barely know how to code, but there's still a lot of untapped potential in all of those different fields for automation and all the other good stuff that programming can bring.
I agree with you on that. Though if we were selling "Everyone can be a professional novelist" when we're actually teaching people how to read and write, would you agree to some form of deception?
> I really feel like current salaries are too much to bear for honchos of the industry and that there's been a recent push to make it seem like "programming is easy" and "everybody can take up code".
Salaries are too high from the perspective of many executives because they have the programmers doing low-value work. Instead of carefully considering what merits building they just have them build everything and then see what sticks and what doesn't.
If programmers were paid like executives, they would only be asked to write code that made a clear difference towards a company's bottom line. Much thought would go into the decision-making and preparation process before code was written to make sure that both problem and solution were appropriate and well understood. You would have whole fields of lower-wage analysts whose job it was to prepare the work of the programmer. There would be much less code written, but the code that was written would be much more valuable.
If you want to be paid like an executive, you need to behave like an executive. Programmers that just do what they are told will never be treated like an executive. Instead of doing duplicate pointless work, tell your superiors what they really want and do that. If you just implement whatever someone else tells you to do, you are a coding monkey, not a programmer.
Stop dreaming of 'low wage analysts' that do the dirty work for you, and just do it.
Programmers need to take more responsibilities rather than less; after all, who can understand the project better than the programmer who creates it?
You have described a hypothetical where programmers are even more costly AND there are "whole fields of lower-wage analysts". This seems like a LOT more cost for the general contractor who is growing and needs a little bit of customized data entry.
Learning to write code is not too hard, maybe not the easiest thing but really not too hard. Writing good code - readable, maintainable, secure code with few bugs - on the other hand is really hard. The gap between a non-programmer and a junior developer is way narrower than the gap between a junior developer and a good senior developer.
And something that I am missing in most of those articles is that writing code is actually the easy part of the job, the hard part is talking to the customer and figuring out what they actually want you to do and then keep up with them changing their mind every four weeks and still somehow manage to ship something that roughly does what it currently is supposed to do.
The hard part, as you describe it, is usually not the job of coders. It's the job of project managers. In lesser organization the coders are doing work that management is suppose to be doing, so they might be doing multiple roles which makes their job much harder.
I don't think that would be part of the job of the project management or at most it would be their job to keep the number of change requests as low as possible. In my current project, for example, with have people dedicated to requirements engineering and things are reviewed several times, at least in theory, before they end up in the sprint backlog.
But nonetheless I would say that just reading a user story and coding it out is the exception, usually you write a if statement and then notice that there is nothing in the specification that says what to do in case the condition is false. And then you ask and suddenly it turns out that this whole thing totally conflicts what somebody implemented a month ago.
Personally I have never worked in a project where people where just supposed to code out a given specification, they were always also involved in gathering requirements and at least to some extend in shaping the architecture. Only the overall system architecture is usually already fixed by architects, most of the time to ensure that the system integrates well with the existing environment.
Junior coders maybe, but a senior level engineer should be able to make these decisions. Often PM's aren't particularly technical or their tech knowledge is dated, so its good for someone doing the implementing to help with the decision making.
I don't agree. This isn't to disparage the job of project managers, but I think you're going too far in the opposite direction and disparaging the job of developers too much here.
Quoting from the top-level comment:
> Writing good code - readable, maintainable, secure code with few bugs - on the other hand is really hard.
How is a project manager going to help with this? This is clearly the responsibility of the programmer, not the PM.
> the hard part is talking to the customer and figuring out what they actually want you to do and then keep up with them changing their mind every four weeks and still somehow manage to ship something that roughly does what it currently is supposed to do.
I wonder if you interpreted this too literally. Sure, the act of talking to the customer is itself a bit challenging in some cases, but I think the point is that it's especially challenging to engineer a system subject to changing requirements because if you're not good and careful you could build yourself into a corner.
A good PM can help a ton here by figuring out how to talk to the customer and spending a lot of time doing so. But I don't think there's any reason to believe that's actually harder than building the requested system, and if any requirement does change, it's not going to affect the PM directly at all -- it will be an order of magnitude harder for the developers to deal with that than the PM.
Finally, I think developers taking on management roles is exactly what's needed, and it's exactly what happens in most top tech companies. Sure, if you look at extremely high ranking VPs at a place like Google, you'll find many ex-McKinsey Harvard MBAs (alongside engineers as well), but in general the middle management at these places is composed of programmers to a very significant extent.
I agree with this but one other side affect of lowering the barrier to entry (which is a good thing I completely support) is it also makes it easier for people who genuinely don't care about that to get into the game. I've met so many devs who absolutely could write readable, maintainable, secure code with few bugs (while working in places where higher ups supported it and allowed for the time for it). They just didn't give a crap. Those are the ones that drive me up the wall. I have no problem taking time out of my day to help a junior developer learn those things. I'll gladly spend my work day helping someone and then make up the time in the evening but when I meet someone who already has the know-how and just doesn't care I want to scream at them.
True, especially as a child it's not unnatural at all. I discovered qbasic by accident and just played around until I could write small games. It never felt hard, frustrating or exhausting. All fun and play.
That is the big difference to actually work in the field and have to do the boring stuff too :)
To be honest, I'm not surprised to hear a statement like this from Scott Hanselman. Learning to code is hard... when you have to do it inside Microsoft's byzantine, arbitrary .NET ecosystem, with its mandatory thousand-button GUI toolchains and fifty-file project baselines.
In environments with less absurd barriers to entry, like JavaScript, learning to code is easy (especially in light of the things Scott mentions in that post, such as the vast swaths of community support available when running into problems).
I'm in favor of self-exclusion. Anyone who holds interviews should be aware that there are way too many duds in the industry for no good reason. I want to work with the obsessives who tell themselves "no, there must be some right way to do this" rather than relying on some strange kind of cheerleading that didn't exist when I started.
The main thing that makes learning how to code difficult is the sheer amount of technologies you need to learn before you feel like you can make real progress. Each individual technology isn't by itself particularly difficult, with a few exceptions; (looking at you git) but also aren't particularly useful by themselves.
You either have to be willing to learn a simpler stack and pick up skills gradually, or deal with the intense frustration of drinking from the firehose right out the gate.
When I was in high school, I went from doing BASIC to elementary web stuff to trying to learn C++. (I didn't have practically anybody who knew how to code to guide me) I gave up and didn't go back to coding for some ten years, sticking to just being a power user.
If I were trying to teach someone to code nowadays, I wouldn't really know where to begin. People want instant gratification without the frustration. You can't have both. I've had limited success, but only after finally convincing them that they have to be patient.
I absolutely concurr. The hardest thing for me has simply been connecting the dots. Suddenly needing to understand Git, or how to configure Apache, just to learn PHP. THere are so many bits that aren't explained to you, all the while you're jumping into the deep end with a language. It's hard to hang in there, but it's worth it – however many don't.
What we really need is sandbox dev environments. A one-click installer that does everything you need to get a stack up and running and ready for code. But it's way way way too complicated. Something like that wants to be a standard, but won't be robust enough to actually solve the problems a standard solves.
I'm excited for functional package managers for this reason. It will give us a framework for describing machine state that's actually useful enough to give us real-world one-click install.
A one-click installer sounds great but creating it is not the hard bit, its choosing what goes into it. Its not just the Cambrian explosion of JS frameworks and plugins but the whole stack of external dependencies from databases, monitoring, build, testing and deploy.
There have been lots of attempts that pick a stack e.g. Angular-seed for the MEAN stack but they make so many questionable choices that they don't have any longevity. At one point it might have looked sensible but now Mongo is out of favour and React has the ascendancy.
Maybe it needs an organisation like a Linux distribution, e.g. Ubuntu For Web, that chooses a complete end to end stack, develops missing glue, maintains forks when necessary and gives some sort of maintenance guarantee for LTS releases and supports upgrade paths.
JS is a mess. Even though there are standards they are implemented in such a way that it is virtually impossible to keep up with for a non-seasoned dev. The tools we use change quicker than ever, major changes all the time breaking everything that came before, tutorials out of date the week after they are written, new syntax that is widely used but not official meaning we have to transpile everything. Everything mentioned is just another obstacle in the way for a new dev to get started coding. By the time they've setup their dev environment most will have lost all their enthusiasm.
I think the problem is trying to teach 'a technology' if you want to teach someone to code treat it like math - teach algorithms. I'm talking about the basics Conditional statements, Iteration and Boolean logic.
Hell you don't even need a programming language - you could teach someone to code by drawing flow charts on a blackboard.
"if statements" and "For loops" those are the tools everything is built on. Want to teach someone to code start there not with a "Python tutorial".
Totally agree. I have taught to some friends and my gf (pointing that it's people that I care about). What I tell them is that there's easy parts and difficult parts, and that things like SUM() in excel is a basic way of programming.
Then I teach them about html+css but starting only on the "easy-ish" part. So using my own library [1] for things like ".row" where you'd need either floats+negative margins or flexbox. Teaching them about images, images sizes (should be set at 100% in many situations), colors, backgrounds, paragraphs and links. That really motivates them.
Then some day they will need more advanced things, but if they can make a layout with the content then they become really motivated since they can see their programming real time.
I have to do this mainly because some people hate "irrationally" maths, so if I taught the same way I started learning --calculating primes-- then they'd be bored to death. Instead I like choosing something they are personally connected: what website do you like? Okay, let's do something similar...
I've even tried doing a small course for free [2], but so far it's not been really effective with those people I'm teaching, but some other friends asked me things about it :)
You aren't teaching programming, you're teaching web design. Programming doesn't have to start with calculating primes, but it does have to be actual programming. Maybe try introducing the to something like Scratch or Logo.
Serious question: how do you define "actual programming"?
CSS is a markup language, sure (although technically Turing-Complete, depending on the spec), but it's still conceptually telling a computer what you would like to happen. It's more declarative than imperative, but given the wide number of different programming paradigms, I don't think that's a problem.
> Serious question: how do you define "actual programming"?
Solving problems by expressing algorithms in a language a computer can interpret. CSS / HTML are not used for expressing algorithms or computations. They're used for describing visual representations. They're an output format.
CSS has a spec in which it's Turing-Complete? Even if it's true, nobody uses CSS like a Turing-Complete language. It's like saying JSON is Turing-Complete because it's JavaScript.
Would you say Prolog is an output format too? It kind of is! My guess is you just don't consider declarative languages "real programming".
What about running "rails new blog"? Is that programming?
What if you add "-d mysql"? Does that count?
What about changing a YAML config file? Not programming? Does it become programming if the config file is written in Python?
What if it has a loop? Or what if you know that a certain key in the config file will trigger a loop?
I don't think there is any firm line between computer use and computer programming. I think there is only a spectrum between specialized and generic computational primitives. HTML and CSS are somewhere in the middle of the spectrum, between tapping a button and applying voltage to circuits.
> My guess is you just don't consider declarative languages "real programming".
That's ridiculous. There's no "real" programming, and of course declarative programming is.. programming. However, with declarative programming you're still writing algorithms and doing computation (composing functions / querying predicates).
> Does it become programming if the config file is written in Python?
Is it an algorithm? No. It's just like JSON is for JavaScript.
> I don't think there is any firm line between computer use and computer programming.
Solving problems with algorithms is programming and while there is indeed a fuzzy line there, I still find it far-fetched to consider writing configuration files (which are static inputs without logic) or declaring html structure / css styles (which again, lack any logic) programming.
You're not teaching programming, but you are teaching coding, no? You're learning to code, and it's pretty easy.
And you can graduate from coding to programming some basic javascript and get into fun stuff like Liquid (Shopify) without leaving the familiar browser environment and text editor of choice.
> but so far it's not been really effective with those people I'm teaching
Interesting. The resource looks like a good start. Could you give some more detail on why you think it was not effective?
I too am thinking of teaching web design and development basics to my gf and a few other people who are interested. Do you have any tips / more resources to look at which would help?
Mainly because it was not enough and it has not a follow up resources. Now it's better than when I used to show it, but still not enough. So when people finish they are lost about how to continue, and it's definitely not enough.
So I would need to spend a large amount of man-hours to teach it, but if it's just for a couple of people I find teaching them myself, with real-time feedback, corrections and explanations works much better as everyone has different needs.
> but so far it's not been really effective with those people I'm teaching
Interesting. The resource looks like a good start. Could you give some more detail on why you think it was not effective?
I too am thinking of teaching web design and development basics to my gf and a few other people who are interested. Do you have any tips / more resources to look at which would help?
It feels like you could write a perfectly symmetrical article—just as convincing—in the opposite direction. We've been telling people "math is hard" for years and look where that's gotten us. People seem do a better job of learning abstract algebra if you trick them into not thinking it's difficult and arcane.
I'm not saying that one view or the other is right. Rather, I'm just saying that it's not obvious which is better or even how much it matters. Posts like this—which basically do say "it's obvious that..." and little more—aren't contributing anything substantial.
Easy and costly also.Each time new framework and language, most of us will endure dejavu to create same thing.We sometimes not up to all and do please job hunter,interviewer.We arent scientis to know all weird formula phisyic , math and other
Sincerely I think it would be the best to meet somewhere in the middle, between Scott's and symmetrical but opposite opinion on this matter.
I am student, and freelance developer. And I ask myself a lot of times, what is the code that we write? Lines aren't clear like in electronics (I studied EE for 2 years, after which I pivoted to CS), where you got rules, theorems, which you use to analyze and build things. Code is a live thing. It grows, it changes, it lives and it dies. And the most paradoxical thing of all is that computers are pretty "dead" and dumb things, bunch of registers, ICs and transistors. (I am oversimplifying things here to prove my point better).
The way we approach writing code always changes, code can be pretty personal thing, you can have your own style (like handwriting). And possibilities are almost endless now!
So I think people in general should stop treating things with black or white principle. I feel that is very immature. Especially not coding.
Software development is single most weirdest and interesting things that happened to me. It makes me scary and enthusiastic at the same time. It is easy and hard at the same time. And I think it is really stupid to try to ascribe any of those exclusive attributes. But everyone has it's own opinion. And that is what makes dev culture and community so interesting in the end.
Easy and costly also.Each time new framework and language, most of us will endure dejavu to create same thing.We sometimes not up to all and do please job hunter,interviewer.We arent scientis to know all weird formula phisyic , math and other
Coding is like driving. Even someone from a developing nation who has never seen it before can learn it. But we aren't all professional race car drivers.
Coding is like singing. Even someone from a developing nation who has never heard it before can learn it. But we aren't all professional opera singers.
It is easy. And it is very very hard.
My dad was a trailer/truck/bus/cab driver throughout his life. He is sort of retired now, but when I talked to him about Uber and every tom dick and harry now being able to drive a taxi, he just laughed the issue aside.
Sure some one can drive and make a few $$'s a day. But to make that considerable source of income to send kids to a good education, to buy your self a home, a retirement and a decent income to retire one to cover all your expenses you have to do a heck lot more. That is when you realize the taxi license was likely least of your worries. You'd have to wake up at 3 am in the morning, suffer rude passengers, wash your car often, have the discipline to spectrum all those things that being successful in profession demands.
At the end you really come to the conclusion that what stopped you was not the lack of coding classes at college or government bureaucracy or union or any of that stuff. The true reason is its hard, and most people simply aren't resourceful enough to see through the end.
Why everyone is being pushed to learn to code in the first place? The reason behind 'coding is easy' is that industry needs lots of programmers? Really?
If there really was a shortage, there would be no ageism. There is only a shortage of very junior people willing to be exploited because they don't know any better. That exploitation starts on day one of a very expensive"boot camp", continues with 80 hour weeks for 0.01% equity in their first job, then they burn out...
Think of it like sport. Anyone can have a go and have fun, jumpers for goalposts and all that but the vast majority aren't going to end up as your Ronaldos or Andy Murrays. And that's OK.
I don't think that's a very useful analogy since the standard for professional athletes is an inflated moving target. Athletes are evaluated strictly in comparison to other athletes and only the best athletes at a given time are chosen for a very small set of positions. Whereas in software development, there are lots of positions for the same specialization and plenty of average people can make a comfortable living.
103 comments
[ 3.2 ms ] story [ 164 ms ] threadWhy not just give them some easy code, help them through it, and let them see if they enjoy it?
The thing with programming is that it's turned into one of those things people say "you are born for". So when newbies have trouble with it, they give up and say their minds don't "work that way". I think it's good to tell people that anyone can learn the basics of programming and get started. No need to be a genius for that. I don't know why but people seem to think programmers are "different" than the general populace (even from those with other hard jobs).
But it's not easy. We've all dealt with hard problems in our jobs, classes, or personal projects, right? If you tell people programming is easy they'll hit that first roadblock like the article says and quit. Seen it happen many times.
I think you also drastically underestimate the number of people who are specifically interested in hard things, not easy things. And in many cases these are exactly the sorts of people you want to hire.
I don't know what your intentions are, but you have a post titled "Stop saying learning to code is easy" and a photo of three women with laptops. Are you trying to make a correlation of women being glib about the difficulty of software development/programming?
The language of mathematics is also designed to be written and understood by people, and is used to describe the laws of physics. I, personally, find writing mathematical statements be comparable to writing code (and also Latin).
If you can write in plain but exact English what exactly do you want the system to do and how to do it; and what you wrote actually solves the problem that you intended, then you did 90% of the programming work and have 90% of the required skills. Yes, you'd still need to code that in a particular programming language so that "the computer would understand", but doing that takes a tiny portion of the total work time and learning the skills to do that also is simple and fast compared to learning how to do the first part properly.
On the other hand, if what you described actually describes something slightly different from what you wanted (which is very likely) and doesn't describe the behavior in a bunch of things that you didn't think of (which is even more likely) then the skills in that computer language or the "design by the language architect" won't help. And fixing issues like that take up the majority of programmer-hours in any nontrivial software project.
As to it being political correctness, I would argue that has little to do with it. It's really marketing - an attempt to change the perception of something to achieve some goal. No one's feelings are hurt when you say something is challenging (I guess unless you explicitly say challenging compared to what).
That part (the one that leads to being able to produce code) has actually always been rather "easy". It's the next steps that are usually hard. Learning data structures, design, architecture, how to collaborate with coworkers, how to fix, debug and review code, mastering the associated tools (shell, git, regex, making a given editor your home and harnessing its power, etc).
From what I've observed with more junior developers that are usually coming through self-learning or accelerated programs, it's not the "code" that is hard, it's those following phases because in the end, they're what really matters.
Though, don't get me wrong, it's absolutely nice that we're pushing programming literacy and making it more accessible for everyone, I just feel like we should not be selling false hope.
I learned all of those things way after shipping my first usable and useful code. These things don't make the programming learning curve steeper, they just make it longer.
If I'm going to hire you as a "software engineer" at an engineering salary, I expect you to know all those things.
Of my friends learning to code for masters degrees now, the ones with a natural coding mindset and studying it hard are taking about 2 years to hit a production engineering level. Most seem to be on a 3-4 year trajectory. That's pretty reasonable for a complex skillset.
Makes sense, I guess I was thinking more of the potential in teaching kids how to code so they can use that knowledge as biologists, economists, teachers, geologists and so on. Standards there are lower because you're competing with people who don't or barely know how to code, but there's still a lot of untapped potential in all of those different fields for automation and all the other good stuff that programming can bring.
That doesn't mean being literate isn't valuable.
Salaries are too high from the perspective of many executives because they have the programmers doing low-value work. Instead of carefully considering what merits building they just have them build everything and then see what sticks and what doesn't.
If programmers were paid like executives, they would only be asked to write code that made a clear difference towards a company's bottom line. Much thought would go into the decision-making and preparation process before code was written to make sure that both problem and solution were appropriate and well understood. You would have whole fields of lower-wage analysts whose job it was to prepare the work of the programmer. There would be much less code written, but the code that was written would be much more valuable.
And something that I am missing in most of those articles is that writing code is actually the easy part of the job, the hard part is talking to the customer and figuring out what they actually want you to do and then keep up with them changing their mind every four weeks and still somehow manage to ship something that roughly does what it currently is supposed to do.
But nonetheless I would say that just reading a user story and coding it out is the exception, usually you write a if statement and then notice that there is nothing in the specification that says what to do in case the condition is false. And then you ask and suddenly it turns out that this whole thing totally conflicts what somebody implemented a month ago.
Personally I have never worked in a project where people where just supposed to code out a given specification, they were always also involved in gathering requirements and at least to some extend in shaping the architecture. Only the overall system architecture is usually already fixed by architects, most of the time to ensure that the system integrates well with the existing environment.
Quoting from the top-level comment:
> Writing good code - readable, maintainable, secure code with few bugs - on the other hand is really hard.
How is a project manager going to help with this? This is clearly the responsibility of the programmer, not the PM.
> the hard part is talking to the customer and figuring out what they actually want you to do and then keep up with them changing their mind every four weeks and still somehow manage to ship something that roughly does what it currently is supposed to do.
I wonder if you interpreted this too literally. Sure, the act of talking to the customer is itself a bit challenging in some cases, but I think the point is that it's especially challenging to engineer a system subject to changing requirements because if you're not good and careful you could build yourself into a corner.
A good PM can help a ton here by figuring out how to talk to the customer and spending a lot of time doing so. But I don't think there's any reason to believe that's actually harder than building the requested system, and if any requirement does change, it's not going to affect the PM directly at all -- it will be an order of magnitude harder for the developers to deal with that than the PM.
Finally, I think developers taking on management roles is exactly what's needed, and it's exactly what happens in most top tech companies. Sure, if you look at extremely high ranking VPs at a place like Google, you'll find many ex-McKinsey Harvard MBAs (alongside engineers as well), but in general the middle management at these places is composed of programmers to a very significant extent.
Learning to code well is difficult and requires years of experience, obsession, and a titanic amount of patience.
That is the big difference to actually work in the field and have to do the boring stuff too :)
In environments with less absurd barriers to entry, like JavaScript, learning to code is easy (especially in light of the things Scott mentions in that post, such as the vast swaths of community support available when running into problems).
You either have to be willing to learn a simpler stack and pick up skills gradually, or deal with the intense frustration of drinking from the firehose right out the gate.
When I was in high school, I went from doing BASIC to elementary web stuff to trying to learn C++. (I didn't have practically anybody who knew how to code to guide me) I gave up and didn't go back to coding for some ten years, sticking to just being a power user.
If I were trying to teach someone to code nowadays, I wouldn't really know where to begin. People want instant gratification without the frustration. You can't have both. I've had limited success, but only after finally convincing them that they have to be patient.
I'm excited for functional package managers for this reason. It will give us a framework for describing machine state that's actually useful enough to give us real-world one-click install.
There have been lots of attempts that pick a stack e.g. Angular-seed for the MEAN stack but they make so many questionable choices that they don't have any longevity. At one point it might have looked sensible but now Mongo is out of favour and React has the ascendancy.
Maybe it needs an organisation like a Linux distribution, e.g. Ubuntu For Web, that chooses a complete end to end stack, develops missing glue, maintains forks when necessary and gives some sort of maintenance guarantee for LTS releases and supports upgrade paths.
Hell you don't even need a programming language - you could teach someone to code by drawing flow charts on a blackboard.
"if statements" and "For loops" those are the tools everything is built on. Want to teach someone to code start there not with a "Python tutorial".
Teaching, mentoring, and onboarding students to enjoy coding is the real hard work.
Then I teach them about html+css but starting only on the "easy-ish" part. So using my own library [1] for things like ".row" where you'd need either floats+negative margins or flexbox. Teaching them about images, images sizes (should be set at 100% in many situations), colors, backgrounds, paragraphs and links. That really motivates them.
Then some day they will need more advanced things, but if they can make a layout with the content then they become really motivated since they can see their programming real time.
I have to do this mainly because some people hate "irrationally" maths, so if I taught the same way I started learning --calculating primes-- then they'd be bored to death. Instead I like choosing something they are personally connected: what website do you like? Okay, let's do something similar...
I've even tried doing a small course for free [2], but so far it's not been really effective with those people I'm teaching, but some other friends asked me things about it :)
[1] http://picnicss.com/ [2] https://en.libre.university/subject/4kitSFzUe
CSS is a markup language, sure (although technically Turing-Complete, depending on the spec), but it's still conceptually telling a computer what you would like to happen. It's more declarative than imperative, but given the wide number of different programming paradigms, I don't think that's a problem.
CSS has a spec in which it's Turing-Complete? Even if it's true, nobody uses CSS like a Turing-Complete language. It's like saying JSON is Turing-Complete because it's JavaScript.
What about running "rails new blog"? Is that programming?
What if you add "-d mysql"? Does that count?
What about changing a YAML config file? Not programming? Does it become programming if the config file is written in Python?
What if it has a loop? Or what if you know that a certain key in the config file will trigger a loop?
I don't think there is any firm line between computer use and computer programming. I think there is only a spectrum between specialized and generic computational primitives. HTML and CSS are somewhere in the middle of the spectrum, between tapping a button and applying voltage to circuits.
[0] http://arstechnica.com/gaming/2013/04/how-an-accountant-crea...
And you can graduate from coding to programming some basic javascript and get into fun stuff like Liquid (Shopify) without leaving the familiar browser environment and text editor of choice.
Interesting. The resource looks like a good start. Could you give some more detail on why you think it was not effective?
I too am thinking of teaching web design and development basics to my gf and a few other people who are interested. Do you have any tips / more resources to look at which would help?
So I would need to spend a large amount of man-hours to teach it, but if it's just for a couple of people I find teaching them myself, with real-time feedback, corrections and explanations works much better as everyone has different needs.
Interesting. The resource looks like a good start. Could you give some more detail on why you think it was not effective?
I too am thinking of teaching web design and development basics to my gf and a few other people who are interested. Do you have any tips / more resources to look at which would help?
I'm not saying that one view or the other is right. Rather, I'm just saying that it's not obvious which is better or even how much it matters. Posts like this—which basically do say "it's obvious that..." and little more—aren't contributing anything substantial.
I am student, and freelance developer. And I ask myself a lot of times, what is the code that we write? Lines aren't clear like in electronics (I studied EE for 2 years, after which I pivoted to CS), where you got rules, theorems, which you use to analyze and build things. Code is a live thing. It grows, it changes, it lives and it dies. And the most paradoxical thing of all is that computers are pretty "dead" and dumb things, bunch of registers, ICs and transistors. (I am oversimplifying things here to prove my point better).
The way we approach writing code always changes, code can be pretty personal thing, you can have your own style (like handwriting). And possibilities are almost endless now!
So I think people in general should stop treating things with black or white principle. I feel that is very immature. Especially not coding.
Software development is single most weirdest and interesting things that happened to me. It makes me scary and enthusiastic at the same time. It is easy and hard at the same time. And I think it is really stupid to try to ascribe any of those exclusive attributes. But everyone has it's own opinion. And that is what makes dev culture and community so interesting in the end.
It is easy. And it is very very hard.
Sure some one can drive and make a few $$'s a day. But to make that considerable source of income to send kids to a good education, to buy your self a home, a retirement and a decent income to retire one to cover all your expenses you have to do a heck lot more. That is when you realize the taxi license was likely least of your worries. You'd have to wake up at 3 am in the morning, suffer rude passengers, wash your car often, have the discipline to spectrum all those things that being successful in profession demands.
At the end you really come to the conclusion that what stopped you was not the lack of coding classes at college or government bureaucracy or union or any of that stuff. The true reason is its hard, and most people simply aren't resourceful enough to see through the end.