What people really mean when they say they want to learn to code


  • Discourse touched me in a no-no place

    The article seems to advocate learning the minimum needed to get stuff done, which I believe is the surest way to create a code monkey, but some here may disagree.

    It should be an interesting discussion in any case.


  • Discourse touched me in a no-no place

    When you’re developing for the web you specifically have to deal with:
    — HTML — CSS
    — Routing
    — Databases
    — Hosting/DNS
    — Application structure
    There’s a lot here to learn. And most of it is pretty irrelevant to non-web development (except databases and application structure obviously).

    If by "most" he means (by his own admission) 60% of his list, then he is - technically - accurate...


  • SockDev

    ... well if i take that article on face value i see we'll be pumping out a bunch of "programmers" with little more programming ability than a common brown paper bag.

    I would argue that coding is a vital skill, as is understanding the basics (VERY VERY BASICS, i don't need to know transistors) of how computers work

    but more importantly is the ability to reason.

    I want coders that can thingk about a problem, can reason through a rough patch, that can break a big problem down into manageable pieces and then solve all the pieces and then hook all the pieces back up into something that solves the problem

    i want coders that can communicate about what they are coding without having to write code to do it, who know how to flow chart a program flow, how to reason from incomplete data.

    those are the truly invaluable skills. and they cannot be taught to one who does not want to learn them. I can take anyone you point to from toddler to 120yo grannies and make a code monkey out of them, but i can't make them a programmer unless they want to be a programmer.



  • @accalia said:

    we'll be pumping out a bunch of "programmers" with little more programming ability than a common brown paper bag.

    Considering there's no shortage of front page material, I'm not sure that's a future situation.


  • SockDev

    I got to this bit...

    At the very least I want to pose the following important distinction I’ve learned: 1. Web development 2. Non-web development
    ...and then I stopped reading.

    Development is development. It makes no real sense to distinguish between web and non-web, as 99.999% of the time it doesn't matter; in either case, you still need a grounding in basic arithmetic and Boolean logic. You also still need to understand how programs flow, and how to handle error situations. And that applies whether you're designing web forum software or embedded system control firmware. Equally, it doesn't matter if you're using SOAP or XML or JSON or BSON or whatever as data exchange, as they can all be used equally well locally as they can over the Internet.

    If you're going to be a developer, you need to know two things:

    1. How to solve problems
    2. How to choose the correct tools

    Get those two sorted, and that's 90% of the work right there; the other 10% is just typing.


    This post contains the inane ramblings of a dude with a beard and a girly avatar, and all figures are pulled directly from his arse. YMMV, try before you buy, don't eat fatty or spicy foods, yadda yadda yadda.


  • Discourse touched me in a no-no place

    @RaceProUK said:

    This post contains the inane ramblings of a dude with a beard and a girly avatar, and all figures are pulled directly from his arse.

    I was considering posting this in the sidebar category for that reason.


  • SockDev

    @antiquarian said:

    I was considering posting this in the sidebar category for that reason.

    I was talking about my own post, not the article :stuck_out_tongue_winking_eye:

    Or have I just whooshed?



  • As teachers, we need to recognize that when people say they want to learn how to code, they often really mean that they want to build a web or mobile application.

    Wow breaking news.



  • @antiquarian said:

    The article seems to advocate learning the minimum needed to get stuff done, which I believe is the surest way to create a code monkey, but some here may disagree.

    I think it depends on whether you keep learning or just stop. When I'm learning some new tool or framework, that describes my first stop. If I decide it's worth keeping on keeping on, then I do.

    I'd say that the person is more likely to continue if they can get to the point of doing something useful quickly. Ceterus paribus I think it's a reasonable stance. But I suspect that when someone says "I want to learn to code," instead of actually taking some initiative and learning to code, they're doomed to failure and possibly code monkeyhood.


  • I survived the hour long Uno hand

    I agree that a lot of people learn better if they get their hands dirty with something they enjoy making rather than starting with theory. But the problem with the JS community is that so many people never bother to learn the rest of it: how to design an application rather than just hack shit together. So there's gotta be a compromise.

    Like, lesson one, simple one-page web app. Lesson two: how to design a decent native mobile app for android (because now you're talking about separation of concerns and routing and logical flow, but still working on something "cool"). Lesson three: data structures, via an application that needs multiple different kinds of data structures to be efficient. Et cetra. Eventually you're on lesson foo: Kerberos authentication and low-level Windows basics.



  • @boomzilla said:

    I think it depends on whether you keep learning or just stop.

    Yeah, there's [i]always[/i] something new you can learn—so many languages, platforms, frameworks, libraries, techniques, patterns that are all continuously evolving. In the last couple of months, I've been playing with OpenGL 3.0, Emscripten, Android NDK, metaprogramming in make, awk, building audio DSP effects and surely a few other things I lost track of. And there's still stuff I feel like I should know that I don't...



  • @antiquarian said:

    The article seems to advocate learning the minimum needed to get stuff done,

    And that is bad because...?



  • @blakeyrat said:

    And that is bad because...?

    Did you read past the comma?



  • Yes, I don't agree.

    I think someone who can solve their problem more quickly using code is doing great regardless of the quality of the code.

    Code quality is not a net negative until their solution begins taking longer than doing the work manually. Until that point, the person is better-off and usually immensely better-off.



  • This article seems to be written from the POV of a web designer who's frustrated with having to learn frontend programming in order to do their job. That's a valid gripe. Except their list misses one more ingredient:

    • Design talent and skills

    Now we have the complete list of skills for someone who can faff around in the browser and doesn't need to know much about memory structure, endian-ness and other low-level stuff (unless SPA-s take off).

    Not something I'd base my career on, though.


  • Discourse touched me in a no-no place

    @RaceProUK said:

    Or have I just whooshed?

    Yes.

    @blakeyrat said:

    Yes, I don't agree.

    I think someone who can solve their problem more quickly using code is doing great regardless of the quality of the code.

    I'm glad you showed up. The discussion had been rather one-sided up to this point.

    @boomzilla said:

    I think it depends on whether you keep learning or just stop.

    I didn't see anything in the article indicating a willingness to keep learning, but maybe I missed it. The "just stop" person is here, though, so have at it.

    brb getting popcorn


  • SockDev

    @antiquarian said:

    Yes.

    Did I at least get flagged for it?


  • Discourse touched me in a no-no place

    @RaceProUK said:

    Did I at least get flagged for it?

    Yes.


  • SockDev

    @antiquarian said:

    Yes.

    Then it was worth it :smile:


  • Grade A Premium Asshole

    @boomzilla said:

    I'd say that the person is more likely to continue if they can get to the point of doing something useful quickly.

    QFT. If you want to get a person interested and keep them interested, you cannot start by saying, "Here is a gigantic stack of books that describes all of the fundamentals of logic, arithmetic, booleans, error-handling, data structures...when you are done with these, then we can start writing code." You need to get them started with a RAD of some sort so that they can have something to get excited about in short order. Then you can start deconstructing it down to its component pieces after they are hooked. If after the quick gains are made they lose interest, oh well. If they stick with the RAD because it is easy...they were going to do that anyway so nothing is lost. But if you drown a person who might have developed into a good developer with a shitload of prerequisite work to the point that they do something else instead, then you have lost something.



  • @antiquarian said:

    I didn't see anything in the article indicating a willingness to keep learning, but maybe I missed it. The "just stop" person is here, though, so have at it.

    I agree. The article didn't go farther than that. I'm certainly projecting my ideas on it, but I don't see that he says not to encourage them to learn. It seem more that he's emphasizing starting them off with something useful to them, as opposed to hello world and then writing sort routines or whatever it was I did in CompSci 101.

    @blakeyrat said:

    Yes, I don't agree.

    This, and the rest is a much less retarded (sorry @kupfernigk) answer than a misleading quote.



  • @blakeyrat said:

    Code quality is not a net negative until their solution begins taking longer than doing the work manually.

    Hmmm... if we're including the time spent cleaning up after somebody inevitably does the manual process wrong then I agree with this.



  • @blakeyrat said:

    I think someone who can solve their problem more quickly using code is doing great regardless of the quality of the code.

    Code quality is not a net negative until their solution begins taking longer than doing the work manually. Until that point, the person is better-off and usually immensely better-off.

    To a point -- I agree with you. HOWEVER: the policy needed to support it is nowhere near in place in most organizations. Once they get to the 'works now for me' point, then the folks this article is aimed at (someone who has their quick-and-dirty RAD thing up and running) will need someone (like one of us here at TDWTF) to take their hand and help them learn and and their code improve beyond that foundation -- instead of throwing it out and replacing it with a bureaucratically written monster, letting it slowly fester for years into a ball of mud, or screaming at the original author "No! Bad dog! Only developers write software!"

    But to do so -- your RAD language and ecosystem need to scale beyond that. VB6 and PHP both fail miserably at this (you can try to make them scale, but it's going to end up on this site if you aren't very, very careful). OTOH, this is something that .NET and Python both do rather well, but in somewhat different ways (.NET by providing a smooth migration path between languages one program module at a time, and Python by being a clean, complexity-scalable RAD language).


  • I survived the hour long Uno hand

    Sometimes I wonder if the problem isn't that many developers still in the early stages of learning think they're in the later stages of code mastery and thus close their ears to all other opinions.



  • @RaceProUK said:

    You also still need to understand how programs flow, and how to handle error situations.

    You should understand those things. Apparently, you can be a paid developer and not get it at all. Today I helped with some code written by a guy how knew how to use C#, ADO.Net, database transaction, stored procedures, exception handlers, and object oriented programming. However, he didn't seem to know how to read the spec or ask questions. He also wasn't very good at testing - not one of the features of the program actually worked. By "not worked", I mean literally everything the application did threw a run time error. BTW, I was brought in to help with "a few bugs found during testing".

    Based on years of working next to a lot of other developers, I'm pretty sure you don't actually need to learn anything in order to make a living as a programmer.



  • @Yamikuronue said:

    Sometimes I wonder if the problem isn't that many developers still in the early stages of learning think they're in the later stages of code mastery and thus close their ears to all other opinions.

    Dunning-Kruger in a nutshell.

    Filed under: If I knew what I were doing, why would I bother?



  • @Yamikuronue said:

    Eventually you're on lesson foo: Kerberos authentication and low-level Windows basics.

    That lesson is a quick one, if it doesn't work just blame the Network infrastructure. According to the article because I don't do web development I don't have to care DNS or routing!



  • I think it is pretty usual to create some abominations when you are first starting off. It happens.

    The JS community I think are less guilty than quite a few others, most projects seem to have unit tests and decent build scripts. But then again I am usually working with horrific home grown .NET apps so maybe it is a case of the grass is greener on the other side.

    @Jaime said:

    You should understand those things. Apparently, you can be a paid developer and not get it at all. Today I helped with some code written by a guy how knew how to use C#, ADO.Net, database transaction, stored procedures, exception handlers, and object oriented programming.

    I haven't got jobs before because they asked me a lot of very specific things about ASP.NET MVC that was mostly terminology that I would have just googled when I needed to know it. There are a lot of devs that are like walking encyclopaedias, but produce some horrific code.


  • Discourse touched me in a no-no place

    @lucas said:

    maybe it is a case of the grass is greener on the other side

    Yes. It's probably also selective observation: the sample of JS projects you're looking at is almost certainly not representative, but rather ones that are much larger and widely used than normal.



  • @blakeyrat said:

    Code quality is not a net negative until their solution begins taking longer than doing the work manually.

    But keeping code quality up helps cut down on the time later on. If it takes you 10 minutes to hack something together instead of 3 hours of designing a sensible architecture, but then fixing every bug takes 4 times as long, all it takes is a few bugs to put you on the red later on.

    If you write flawless code from the get-go (I know you probably do, sure, but think of the lesser ones, o Blakey), you might get away with making it sloppy. But most of the time, you will lose time later on.

    @boomzilla said:

    It seem more that he's emphasizing starting them off with something useful to them, as opposed to hello world and then writing sort routines or whatever it was I did in CompSci 101.

    Yeah, that's a fairly decent point. I'm not sure I fully agree, though - if they want to tackle on more advanced stuff, they will eventually need more advanced topics, and I personally find it easier to introduce how the computer works first, rather than weeding out the misconceptions later.

    Pointers and shit are actually easier to explain when you're in a vacuum (here, it's memory (draw a table), you put data under location such-and-such (mark a bunch of cells), and then use this location to refer to it), than when you already have some very high-level language experience.



  • As for the article, it's bad. Seriously, you want people not to learn structures? Data types? Okay, JavaScript might not have those per se, but pretty much any backend language has (fuck Node). And you still need to mind the types even on the frontend, or you run into those wat-moments JS has.

    The vibe I get is "I want to build a website, but comprehending concepts related to building websites iz hard! I just want grumpy cat!". Can you do that? Maybe; but then again, you can just get a Tumblr or use Apex or whatnot. And it will probably be less limiting than knowing only a few memorized lines of JS.


  • Discourse touched me in a no-no place

    @Maciejasjmj said:

    I personally find it easier to introduce how the computer works first, rather than weeding out the misconceptions later.

    That's only true if you've got someone who is motivated enough to stick to the course of study through the hard bits. Without that motivation, you simply won't get a chance to tackle the necessary difficult parts.



  • @dkf said:

    That's only true if you've got someone who is motivated enough to stick to the course of study through the hard bits. Without that motivation, you simply won't get a chance to tackle the necessary difficult parts.

    Well then, one lazy asshat less in the industry. It's not even the matter of material - if someone's too lazy to try and get through understanding what they're supposed to do, they'll not only not make a good coder, they won't make a good employee, period.

    It's one thing to know what you won't need - it's another to not put any effort in understanding what you do need, just because it's hard.



  • @Maciejasjmj said:

    But keeping code quality up helps cut down on the time later on. If it takes you 10 minutes to hack something together instead of 3 hours of designing a sensible architecture, but then fixing every bug takes 4 times as long, all it takes is a few bugs to put you on the red later on.

    If you write flawless code from the get-go (I know you probably do, sure, but think of the lesser ones, o Blakey), you might get away with making it sloppy. But most of the time, you will lose time later on.

    You're thinking like a software developer. We're not talking about developing software, we're talking about programming.

    There's a million jobs out there where the guy who can do some script-fu in the browser or in Photoshop, or write some VBA in Excel, or whatever, can be ten times more productive than the guy sitting next to him. We don't need more people to write a spreadsheet app, but almost everybody can benefit from programming knowledge.


  • Discourse touched me in a no-no place

    @Maciejasjmj said:

    Well then, one lazy asshat less in the industry. It's not even the matter of material - if someone's too lazy to try and get through understanding what they're supposed to do, they'll not only not make a good coder, they won't make a good employee, period.

    But I'm arguing that with some people you need to encourage them to put in the effort. Putting all the hardest bits up front is a technique to use where you want to cut down the number of people sticking the course.



  • @blakeyrat said:

    write some VBA in Excel

    Oh! You don't want that. I once worked with a company that for a whole month some minions were using the wrong spreadsheet version and so the customer fees were wrong. At the end of the month the company has lost almost half million euros and I got to migrate that code to a Python web app.

    But yes, I agree with your point. I think there was an article about such a situation around here.



  • @blakeyrat said:

    There's a million jobs out there where the guy who can do some script-fu in the browser or in Photoshop, or write some VBA in Excel, or whatever, can be ten times more productive than the guy sitting next to him.

    Hm.. okay, good point, automating some mundane stuff in Excel or something is a good use case. But still, the average data entry drone does not know anything about programming - and to actually do that scripting consistently and efficiently, they need to grasp fairly alien concepts (like variables, or algorithms).

    And cargo-culting all your way through only gets you as far as your luck does.

    @dkf said:

    But I'm arguing that with some people you need to encourage them to put in the effort. Putting all the hardest bits up front is a technique to use where you want to cut down the number of people sticking the course.

    Not everyone's a winner.



  • @lucas said:

    I haven't got jobs before because they asked me a lot of very specific things about ASP.NET MVC that was mostly terminology that I would have just googled when I needed to know it. There are a lot of devs that are like walking encyclopaedias, but produce some horrific code.

    Two-way process...you're lucky to weed out companies like that, you don't want to work for them


Log in to reply
 

Looks like your connection to What the Daily WTF? was lost, please wait while we try to reconnect.