Stop saying learning to code is easy(hanselman.com)
hanselman.com
Stop saying learning to code is easy
http://www.hanselman.com/blog/StopSayingLearningToCodeIsEasy.aspx
39 comments
> 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.
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 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 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.
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.
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.
There's a difference between being literate and a professional novelist.
That doesn't mean being literate isn't valuable.
That doesn't mean being literate isn't valuable.
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?
Car-analogies are old hat by now, but I like to think of it as having enough mechanical aptitude to change your own oil.
The problem that I see is the imprecision of english when it comes to the word "hard".
There are many different kinds of hard. There's hard like "I have to put effort into it", there's hard like "if you were not born being able to do it, you can't do it", and there's hard like "even people who can do it are only capable at their absolute best moments".
So the issue is not "Is programming difficult?" - clearly any learned skill is difficult to bring to an expert level.
The question I see people asking is, "Can the average person with diligence and application ever learn to program well?", and the answer is obviously yes, they can. It's not "hard" like running a <3:50 mile is "hard".
It's also not hard like "Can you taste PTC or distinguish red and green", in that you either "are born with it" or aren't, and find it effortless if you are capable.
So many people that I've met assume that they're fundamentally incapable of understanding algorithmic thought, and that's very sad. They don't need to be Kernighan or Torvalds in order to gain value from learning some programming skills.
There are many different kinds of hard. There's hard like "I have to put effort into it", there's hard like "if you were not born being able to do it, you can't do it", and there's hard like "even people who can do it are only capable at their absolute best moments".
So the issue is not "Is programming difficult?" - clearly any learned skill is difficult to bring to an expert level.
The question I see people asking is, "Can the average person with diligence and application ever learn to program well?", and the answer is obviously yes, they can. It's not "hard" like running a <3:50 mile is "hard".
It's also not hard like "Can you taste PTC or distinguish red and green", in that you either "are born with it" or aren't, and find it effortless if you are capable.
So many people that I've met assume that they're fundamentally incapable of understanding algorithmic thought, and that's very sad. They don't need to be Kernighan or Torvalds in order to gain value from learning some programming skills.
I think "learning to code" is more ambiguous. I have a designer friend getting in to web design - I've helped him out pick up some jQuery - he learned the stuff that was useful to him pretty fast. Is he a programmer ? No. Can he write code ? Yes.
So yea writing code is easy, copy-paste and replace the stuff that seems relevant to you, especially when you have a quick iteration method like a REPL.
Control flow might take a while to fully grasp but still it's not hard to understand, but takes practice to get comfortable with.
So yea writing code is easy, copy-paste and replace the stuff that seems relevant to you, especially when you have a quick iteration method like a REPL.
Control flow might take a while to fully grasp but still it's not hard to understand, but takes practice to get comfortable with.
Humans generally have a way to look for patterns of repeated effort that could be automated, and then proceed to automate them one way or the other.
It has nothing to with programming. We are trained through evolution to conserve resources as much as we possibly can.
The guy who invented the wheel was the first programmer.
It has nothing to with programming. We are trained through evolution to conserve resources as much as we possibly can.
The guy who invented the wheel was the first programmer.
> The problem that I see is the imprecision of english when it comes to the word "hard".
Learning to code is NP-Hard ?
Learning to code is NP-Hard ?
N log hard :)
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.
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.
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.
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 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.
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 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.
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.
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 :)
[1] http://picnicss.com/ [2] https://en.libre.university/subject/4kitSFzUe
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
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.
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"?
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.
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".
> Does it become programming if the config file is written in Python?
> I don't think there is any firm line between computer use and computer programming.
CSS does have logic:
div { color: red }
.foo { color: blue }
if classes.contain("foo")
color = "blue"
else
color = "red"
HTML+CSS may not be programming, but spreadsheets definitely are[0].
[0] http://arstechnica.com/gaming/2013/04/how-an-accountant-crea...
[0] http://arstechnica.com/gaming/2013/04/how-an-accountant-crea...
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.
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.
I'm seriously not gonna spend time arguing what is programming and what is not on HN, sorry.
> 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?
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.
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.
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.
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.
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.
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".
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".
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.
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'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.
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 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 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 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".
It says nothing about the author's mind, but your comment and the one above says a lot about their authors. It's you making the asumptions.
I work mostly with people teaching kids to code, and for our goals, it is easy. We aren't trying to teach them how to write the most elegant and efficient code... we are trying to get them to understand basic logic and building blocks. We are teaching them how to solve problems, and debug their work. And we are teaching them basic computer literacy.
If they are good at it and go deeper into software development or computer science, then it may get hard. But it is a pessimistic view to look for reasons why something will be hard, and pontificate on those problems. Why not just help people take some simple steps, get a few successes under their belts, and decide for themselves if they want to go into deeper more difficult waters.
If they are good at it and go deeper into software development or computer science, then it may get hard. But it is a pessimistic view to look for reasons why something will be hard, and pontificate on those problems. Why not just help people take some simple steps, get a few successes under their belts, and decide for themselves if they want to go into deeper more difficult waters.
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.
It is easy. And it is very very hard.
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.
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.
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.
I like yours better.
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.
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.
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.
I learned C/C++ by myself with "C++ for dummies". I was already taught assembly at school at a very short class. I learned more from linux and C through a linux fanboy, and I seriously learned industrial C++ at school, but I already knew most of the basics.
I was obsessed about learning how to code because I always played a lot of video games and loved electronics.
I don't have a degree, am chronically unemployed. I admit that learning code is really about understanding the details. Having a taste for computers and math is a huge advantage. If you don't, you will quickly hate it and only learn it for a job, but not for passion.
I agree that code looks lame and is really not accessible, while most people who need it, can't always afford to work with a programmer. There needs to be solutions like MIT's scratch or anything that is more intuitive than textual syntax. It's amazing what some people can manage to do with excel.
I was obsessed about learning how to code because I always played a lot of video games and loved electronics.
I don't have a degree, am chronically unemployed. I admit that learning code is really about understanding the details. Having a taste for computers and math is a huge advantage. If you don't, you will quickly hate it and only learn it for a job, but not for passion.
I agree that code looks lame and is really not accessible, while most people who need it, can't always afford to work with a programmer. There needs to be solutions like MIT's scratch or anything that is more intuitive than textual syntax. It's amazing what some people can manage to do with excel.
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...
I think in part to flood the market with low quality applicants, and drive salaries down.
That will only increase hiring costs and increase the risk to get a lemon as an employee.
Learning to fix electronics is easy. Learning to fix your car is easy. Just open up the enclosure/hood and... do stuff :D
Playing piano is hard, but teachers that keep the learning experience fun see much lower drop-out rates.
Teaching, mentoring, and onboarding students to enjoy coding is the real hard work.
Teaching, mentoring, and onboarding students to enjoy coding is the real hard work.
My personal variant has always been "learning to code is easy, you just have to be okay with feeling completely stupid for a while until it clicks."
It's a way to encourage while being up front with the amount of time and mental toil learning new ways of thinking and expressing your ideas takes.
It also encourages self-selection, as the few people who took it to heart are some of the best devs I know now, they saw the challenge and remained undaunted.
It's a way to encourage while being up front with the amount of time and mental toil learning new ways of thinking and expressing your ideas takes.
It also encourages self-selection, as the few people who took it to heart are some of the best devs I know now, they saw the challenge and remained undaunted.
Interesting. I tend to learn better when I don't perceive something as "hard", as that creates a mental block of sorts for me. Acquiring proficiency requires significant amounts of time investment + effort, but it would seem "hard" should denote something above that.
I tend to prefer terms like "tractable", where it's less about whether the given problem is "easy" or "hard", and more about whether I can find a productive way to reason about the problem. An easy subject can be made intractable by the wrong kind of presentation. Most subjects that are very /new/ to a given person may be intractable on the onset. Some subjects, ones that I would call truly "hard", do not become tractable for a very long time.
So I don't know if I'd call software development hard, but it's still a new and unfamiliar thing to a lot of people, and it can be quite intractable at various times, which is basically what "bad documentation" means.
I tend to prefer terms like "tractable", where it's less about whether the given problem is "easy" or "hard", and more about whether I can find a productive way to reason about the problem. An easy subject can be made intractable by the wrong kind of presentation. Most subjects that are very /new/ to a given person may be intractable on the onset. Some subjects, ones that I would call truly "hard", do not become tractable for a very long time.
So I don't know if I'd call software development hard, but it's still a new and unfamiliar thing to a lot of people, and it can be quite intractable at various times, which is basically what "bad documentation" means.
I think learning to code _is_ easy.
I've recently pointed a friend towards FreeCodeCamp, he's never tried development but was asking about it (previous non-tech related jobs) so I pointed him to the website.
Yesterday he must have spent 8 hours doing tutorials, occasionally asking questions and has started building his first website. He's beginning to pick up the basic building blocks of programming, not for loops and if blocks, but data structures, debugging (Chrome is amazing), etc.
I think the hardest part of learning to code is choosing a language and deciding what to build. The rest is Stack Overflow and online tutorials. Oh, and a whole lot of time.
Sure to become an "Expert" you'll need to learn about a vast range of things that are not code, but affect code - like security, best practices, readability and maintainability, different stacks, etc. But getting your foot in the door with the basics is pretty easy.
I've recently pointed a friend towards FreeCodeCamp, he's never tried development but was asking about it (previous non-tech related jobs) so I pointed him to the website.
Yesterday he must have spent 8 hours doing tutorials, occasionally asking questions and has started building his first website. He's beginning to pick up the basic building blocks of programming, not for loops and if blocks, but data structures, debugging (Chrome is amazing), etc.
I think the hardest part of learning to code is choosing a language and deciding what to build. The rest is Stack Overflow and online tutorials. Oh, and a whole lot of time.
Sure to become an "Expert" you'll need to learn about a vast range of things that are not code, but affect code - like security, best practices, readability and maintainability, different stacks, etc. But getting your foot in the door with the basics is pretty easy.
So this applies to anything.
I helped my friend learn to paint. Bought him a canvas and 4 brushes and some paint. He watched YouTube all day yesterday . I think he painted this circle thing that looked like a sun. Painting isn't hard.
I helped my friend learn to paint. Bought him a canvas and 4 brushes and some paint. He watched YouTube all day yesterday . I think he painted this circle thing that looked like a sun. Painting isn't hard.
[deleted]
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).
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).
Yeap.. people usually forget how hard it was. Programming is not a natural thinking so when learning, first forget what makes sense in "real world" and embrace a new way of seeing thinks. I understand why some say that it's easy, they're trying to bring more people to tech side, but my truth is: i do programming because i really like and all the hard times to get there are battles won, but don't try to win battles from something that don't stand out for you, remember, you really need to like what you're doing. Peace.
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.
Learning to code is easy (everyone who wrote a BASIC program as a child, raise your hand.)
Learning to code well is difficult and requires years of experience, obsession, and a titanic amount of patience.
Learning to code well is difficult and requires years of experience, obsession, and a titanic amount of patience.
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 :)
That is the big difference to actually work in the field and have to do the boring stuff too :)
For me at least learning to code have two different requirements.
The first is shared across languages, getting to grips with ifs and cases and all that. That is relatively easy.
The second is pr language, and it involves learning what is available in the libs and similar. And how to use those to do things like read and write files, connect over networks, or draw a UI on screen. And those are bloody hard.
The first is shared across languages, getting to grips with ifs and cases and all that. That is relatively easy.
The second is pr language, and it involves learning what is available in the libs and similar. And how to use those to do things like read and write files, connect over networks, or draw a UI on screen. And those are bloody hard.
For an alternative take on the exact same subject matter, see Quincy Larson's "One does not simply learn to code"
https://medium.freecodecamp.com/one-does-not-simply-learn-to...
https://medium.freecodecamp.com/one-does-not-simply-learn-to...
"Programming is easy" -- person that has spent a significant percentage of their life programming
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?
Why not just give them some easy code, help them through it, and let them see if they enjoy it?
No one tells people being an architect or a writter is easy. Why lying?
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.
[deleted]
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
I disagree with this, maybe not because coding is easy, and I can't really measure that because I've been coding since I'm 10 years old (I'm 26 now) so it's been "normal" for me. But what I can tell is that learning to code is like learning to do something else that requieres skills and time. It is as easy as learning something else completely unrelated with computers, it depends on you and how dedicated you are.
Yeah, seriously, and stop teaching people how to code. You people are seriously letting the cat out of the bag.
Anyone (probably) with a few tools and some wood can build a dog house.
But you need real pros to build a skyscraper.
But you need real pros to build a skyscraper.
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.
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 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.
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.
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.
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.
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).
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).
Learning to code is easy
Learning to code is easy, learning to use that ability to solve interesting problems is hard.
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).
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).
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.