Advice on learning to program

[Jason Knight]

There are a number of mistakes I see beginners -- and even some experts -- make when it comes to learning to program. They aren't always directly related to any specific language, and I've dropped into these pitfalls more than a few times the past four decades I've been writing code.

So I thought I'm make a sticky outlining said common errors and toss in a few good practices. Anyone has something to add to this, let's hear it.


Editors, wizards, frameworks, and anything that "does the work for you"

One of the biggest mistakes early in learning is hoping that your editor or some framework will do all the work for you. Even the simplest of aids and shortcuts can in the long term bite you in the backside for one simple reason:

You're not learning how to actually do anything.

If you have tools doing things for you, what exactly are you learning? If you're just learning, how are you qualified to know if what the tool is doing is right, correct, or how it actually should be done.

You can see this quite plainly on the front-end with frameworks like bootstrap (aka bootcrap), w3.css, blueprint, etc, etc. They make it LOOK easy, and they let you quickly get a result... but whilst that result might look pretty for YOU, they're done incorrectly, are bloated, slow, harder to maintain, harder to customize for things the framework doesn't do out of the box, and more often than not tell users with accessibility needs to sod off.

That last part can get you into deep legal doo-doo depending on the type of site.

In fact, systems like bootstrap are plainly and evidently written by people unqualified to write a single line of HTML and CSS. If you actually know said languages go to their examples pages and view-source any of them. If you don't recoil in shock and horror at the train wrecks of incompetence and ineptitude, you don't know as much about HTML as you think.

That's a significant part of how people get suckered into using such trash in the first place. You're a nube, you don't know any better, and letting yourself get duped by these allegedly "easier" solutions only creates a confirmation bias that will hobble you when it comes time to do things right. There are a LOT of supposed "experts" and "professionals" out there who use these systems to the exclusion of all other approaches, and to be brutally frank most of them are unqualified to do the job at the business level. Frankly, I doubt that those who adopt said techniques even know enough to do so casually for personal websites.

It is because of this I consider much of the 'automation' out there to fall into the trap of "false simplicity". It is possible to make something look simpler, whilst making doing the actual task harder. When your task is learning to do things, having anyone or anything do it for you means you're not learning!

I personally have to be careful with that, as I'm prone to saying "oh I can do that in three minutes" and just doing it for people.. When I do so though, I at least TRY to document everything so they can learn from it.

This said, there are useful tools that if they help go ahead and use, as they are more about helping you keep track than doing things for you. I personally find colour syntax highlighting to be an illegible useless broken mess, but some people find it helpful. That's fine, it's not coding for you, it's a tool to help digest / separate the code. Brace matching is a tool I rely on all the time given how many {[([])]) nests we end up dealing with. Those types of things don't do the work for you, they just make the work easier.

A difference lost upon some...


Don't make excuses, FIX THINGS

It is very easy to start going "well I can fix that later", or "well I haven't learned that yet", or "this isn't part of my audience" or any of a dozen other lame excuses not to do things right. Whilst certainly time constraints can be a legitimate reason to put something off, once you start doing it the whole mess snowballs.

The "I haven't learned that yet" part is particularly frustrating for YOU, because if you're just starting out and learning, falling into that behavior will stop you from EVER learning it!. It might suck, but buckle down and learn it. If you're having trouble understanding it, come to a forums like this one and ASK.

For great examples of "lame excuses" I always point people at this article:

https://www.456bereastreet.com/archive/200704/lame_excuses_for_not_being_a_web_professional/

Whilst over a decade old, most of it is more true today than when it was written!

Whitespace and consistent formatting are your friend

Whilst there are a plethora of "style guides" out there, so long as all your code is consistently formatted which one you use shouldn't matter.

Whilst you'll have tons of pointless pedantic arguments over Spaces vs. Tabs and how wide your tabs are and so forth, or over if an opening { is on the same line as why or wasting a line all to itself, the bottom line is that it shouldn't matter as any decent editor should let you quickly switch between the different styles, and there are tons of "pretty printer" programs out there to reformat existing code however you like.

But again, don't rely on the tools for your own code. Learn to do it a specific way, keep with that way, and be consistent. Good block-level indenting, extra whitespace such as newlines around blocks that feel cramped, can make your code easier to read and digest, and can clearly show the logic blocks.

Whilst excess whitespace in HTML, CSS, and JavaScript can make a page a hair slower, if you have enough whitespace for it to really be an issue in the age of gzipped content delivery handled by the server automatically, you might have a problem; but if it really matters to you? That's what minification is for. Plenty of tools to strip out excess whitespace and comments for your deployment copy... just don't do that to your development copy!


Learn when and when NOT to comment

It's often painful going into codebases that are unclear through the lack of verbose variable or function names, only to then find a complete lack of comments. At the same time painfully obtuse over-commenting can be just as bad if not worse, as you can't find the actual code in the sea of comments.

Good well written code SHOULD be self documenting, in that you use variable names that are standard practice (For example i, j, k for loops in most languages, "e" for a local scope element and 'd' for document in JavaScript) of flat out describe what the variable is, or is for. Same for markup where you should be saying what things ARE.

HTML is a great place to show this as you'll often see bloated stupid commenting like:

Code: [Select]

<div id="mts_103"><!-- START top section -->
</div><!-- END top section -->

Really, opening a DIV starts a section and closing the DIV ends it? WHO KNEW?!?. When the tag already says its doing something, don't waste time saying it again in the comment!

Likewise the painfully and pointlessly crypic ID -- the type of which you see all the time -- would make the opening content pointless if the coder had just called it id="topSection"

The only useful comment there is that with the </div> it's often hard to tell WHICH <div> is being closed. I dealt with that a lot in the SMF skin when giving it this repaint. As such a closing comment can actually help, but keep it simple.

Finally, and this is a HTML thing comments have been known to cause rendering bugs in IE and FF if it's placed between sibling-level elements. Whilst no longer a major issue when/if this crops up, you'll tear your hair out wondering what's wrong. Easiest way to avoid this is to put your closing comment before the tag.

Hence what should probably have been written there is:

Code: [Select]

<div id="topSection">
<!-- #topSection --></div>

Notice also the use of the # to indicate that it's an ID. If you've got a lot of content in such a DIV it's often handy to know that <!-- #topSection.modal --> is what's being closed when the opening tag is off the top of the screen.

These practices can apply to most any language in that a closing comment can save your tuchas. Even something as simple as:

Code: [Select]

function doNothing() {
} // doNothing

Can work wonders when/if that function grew larger than what fits on the screen... or when trying to figure out where/if you forgot a } or used an extra one. This also plays well with the previous section about formatting habits.

Really if you have to resort to comments for "normal code" there's something wrong. The best time for your content to have a comment is either explaining values that can be changed with impunity (common in JS), or when you are violating a good practice for a good reason.

This article on IBM's Linux developer site whilst meant for C programmers I feel is useful for every skill level of programmer regardless of language used.

https://www.ibm.com/developerworks/library/l-clear-code/index.html

I'm particularly fond of the "oh, now we're done?" part, since that's exactly what I just described people doing in HTML.


Stick with good practices, until you can't.
A lot of developers -- and I've done this myself -- will say "there's no reason for invalid code". ANY rule, no matter how well minded has to have exceptions. This is doubly true if the standards bodies setting the rules go off the deep end like the W3C has been doing the past few years.

Again, HTML is great for examples of these exceptions. Take the media="" attribute on LINK, which says which types of devices should obey said <link>. There used to be a whole bunch of them, but the specification itself said that which ones exist is up to the vendors, not the specification because a new type of device or method of interacting with the web could come along at any time.

Now though? Anything not on a shrunken "approved list" throws a warning in HTML validation. That's utter bullcookies when ones like "projection" (often used by kiosks) and "tv" (MSN TV, Wii, WiiU, DS) still have users in regular circulation. As such when the official HTML 5 validation throws a warning about that, I tell it to kiss off. That's a legitimate reason in that I'm putting users ahead of what the standards say.

Another example is the recent pointless change so that TFOOT before TBODY is invalid, when in 4 Strict it was the other way around. There was a reason for TFOOT before TBODY, and that reason was for multi-page delivery (print) or summary use, you needed that information so that it could be printed on every page or directly accessed before the content even finished downloading.

IF they had loosened the rule becuase the number of people using TFOOT properly could be counted on one hand, I'd be fine with it. But now throwing an ERROR (not even a warning) for all the people who actually understood it and used it right? That's just BS and makes me ignore that error.

Now, whilst I just listed some examples of when to ignore it, it becomes too easy to take that attitude with everything. Some changes -- like those in PHP -- are done for very good reasons, and throwing a hissy fit "wah wah, I don't wanna use prepare/execute" is not how you should handle things.

There are many more esoteric cases -- like the invalid browser prefix stuff in CSS -- that are necessary but incorrect. It's just the nature of the beast and it's why CSS validation is basically a joke at this point.

THAT DOESN'T MEAN YOU DON'T TRY!!!. Try as much as possible to have valid/proper code... and if you are blatantly, fraglantly, and wantonly violating the rules, take the time to toss in a comment to explaini WHY!


You can't remember every little detail, use a quality reference!

When learning to program it's often essential to learn what can be done, but it is impossible for everyone to remember everything all the time. Get a quality reference (PHP.NET, MDN), and learn how to search and navigate it. This seems obvious, but from the questions that often pop up on development forums? Well... there's a reason some tubby snobs constantly belt out "RTFM".

That's an attitude some of us greybeards need to keep in our pants. The idea that someone went through the effort of registering for a forum, following the confirmation e-mail, and creating a post without having first at least tried google? Land's sake Google is probably what brought them to the forum! They're nubes, they might not even know the correct terminology to search for.

You can't know it all, you can't remember it all, so if in doubt, go to the reference. If the reference fails you, come someplace like this and ASK.

There is no shame in not knowing something; this is why I don't consider the word "ignorant" to be an insult. It just means you don't know. You can fix ignorant. Though as Ron White said, "you can't fix stupid."

Just beware there are some references/sites that are horribly outdated, blatantly incorrect, filled with bad practices, or trying to dupe you into thinking they are some sort of official site when they aren't, and offering rubbish "certifications" that mean exactly two things; and Jack left town. Some -- like W3Schools -- are all of the above. Learning to separate the wheat from the chaff, and telling what's a scam and what isn't is as important a part of the learning process as the underlying languages themselves.


Watch out for bandwagon and other propaganda

Just because something is popular doesn't make it good, or right. This is the number one fallacy you'll come across in the learning process. There are those who will try to convince you to do something just because it's what everyone else is doing. That is NEVER sufficient justification for anything.

Likewise beware of card stacked "results". Sometimes things -- vue, react, and bootstrap for example -- will cherry pick corner cases, or use outright bad code to compare theirs to as justification for why they are "better". This is most always complete nonsense and is a warning flag you should learn to recognize.

The glittering generality of saying something is "easier" without saying "WHY?!?" has become painfully common in the industry, and like all the other propaganda techniques it's more meant to make you feel instead of actually thinking.

There are seven propaganda techniques:

• Bandwagon
• Card Stacking
• Glittering Generalities
• Name Calling
• Plain Folks
• Testimonial
• Transfer

Learn them, recognize them when they are used, and then try to figure out the intent of why they are being used. When you're doing something new, the wolves are out there and they will use these techniques to try and take advantage of you.


There is no end to the learning

A lot of people will try to treat programming as a "learn it once and you're set for life"; or worse teach it as such. This is another fallacy. As a dearly departed friend of mine once said:

The day you stop learning is the day the rest of the world leaves you behind.

There is always a new technology, a new trend, changes to the security landscape, improvements in technique, and just plain better ways of doing things. If you try to coast at any point on your existing knowledge, you might as well just stop altogether.

I've been programming for near-on four decades, and of the knowledge I had just a decade ago I'd say a third belongs on the trash heap and forgotten. That is just the nature of the beast. Get used to it. If you do not have that deep-rooted love of learning, this is not the field for you.

See how much use I'm getting out of my mastery of ADA at the moment. That was sarcasm.

It is to that end -- the ever changing nature of coding practices -- that if you aren't disgusted with your own code of just a year past, you might want to re-evaluate your skills and go do some research.

The best developers I've ever known have been the ones who can evolve, change, and adapt with the ever-changing technologies. Computers are a field where on the hardware side 3 years is obsolete, five years is the scrap-heap. AT BEST you can only expect about double those numbers on the software side.


So... hopefully someone finds this helpful. It's not the stuff usually discussed but I really feel it's an important starting place for all developers to have this base notion of what's really involved... Much less where things can go pear-shaped.

[John_Betong]

Please refrain from disrespecting the w3.org html validation tools because I believe a lot of prior thought has gone into the validation error results. No doubt there are reasons currently not apparent which may be for use in the future.

Create shortcuts to validation tools and call frequently and especially just not at the end of a project,

PHP7, another interpretated language has introduced validation declarations and function type specifications which "fail fast" rather than late on a Friday afternoon Learn how to use these tools.

Lint is also another tool available in most languages and also worth studying the error results because they can be very informative.

[Jason Knight]

Please refrain from disrespecting the w3.org html validation tools because I believe a lot of prior thought has gone into the validation error results. No doubt there are reasons currently not apparent which may be for use in the future.

If we were talking about HTML 4 Strict, I'd agree with you 100%, but with the pure derpitude that counts for more than half of HTML 5, I have lost all confidence in the W3C as a standards body... and I used to be a stickler saying "there's no excuse for invalid markup" under 4 strict. But they've gone so far off the deep end with 5, I've had to 180 on that opinion.

The validation tool greatly reflects this, allowing outmoded trash like EMBED, but getting its panties in a knot if I use a media target that isn't on their special list? Since when are media targets ANY of the HTML specification's business. The whole idea was for VENDORS to be able to make them so we could plan for the future. Limiting it to an approved set UNDOES that progress! Not that the vast majority of developers have any clue what a media target is, as evidenced by all the stylesheet <link> LACKING even just media="screen" resulting in broken delivery, or  the nutters sending media="all" which is the same as having none! See another reason why the folks who made and maintain bootstrap are unqualified to build websites, much less tell others how to do so.

It's like AUDIO and VIDEO creating vendor lock-in to whatever codecs and containers browser makers feel like implementing, and for what? To fight vendor lock in? Sounds skeezy, you'd almost think the 1000 pound gorilla's at the W3C are Microsoft and Apple, companies who lost the formats war. Don't even get me started about AUDIO, VIDEO, EMBED, and even IMG being redundant to OBJECT, and how OBJECT was supposed to be sandboxed from day one, or how they keep adding pointlessly redundant tags for no reason other than "well nobody uses semantics anyways, so oh well."

The W3C is borderline toothless, and have from an HTML standpoint become nothing more than a rubber stamp for whatever the WhatWG vomits up. This is disturbing given how the WhatWG clearly was NOT qualified to create HTML 4 Stricts successor since it is painfully obvious they based in on 4 Tranny. Transitional literally meaning "in transition from 1997 to 1998 development practices". Just look at tags like HGROUP which the W3C thankfully killed off, as proof that the folks creating HTML 5 didn't even understand what numbered headings were for!

Which is why for all the genuine improvements in HTML 5 -- manifests, the new input types and attributes, data- attributes, the reduced footprint inside <head> -- there are double that number of pointless idiotic redundancies (aria roles, allegedly structural tags), bad practices, and things that have made the HTML validation tool as broken and useless as CSS validation has been for twenty years.

It's very easy to take the advice of such tools as the gospel when it's all theoretical. In production use their flaws become very noticeable and more often than not do more harm than good.

See linters -- ESPECIALLY JavaScript ones... where the lint writers personal preferences that have nothing to do with the language standard or good coding are the norm. I'm sorry, but when they started throwing warnings/errors about unary operators, functional evaluation, assignments as evaluation, case dropthrough, and dozens of other core features of a C syntax language, they lost me. To use a JS linter and have anything I would consider good code pass, I basically have to disable every last one of their pointless checks to the point I get better feedback just trying to run the code with the console open.

Because if this:

Code: [Select]

switch (++myVar) {
case 3:
secondaryCounter++;
case 2:
primaryCounter += 5;
break;
default:
console.log(secondaryCounter, ':', primaryCounter);
}
Is enough to make a linter "out of the box" vomit up ten or more errors, Linting tools in JavaScript can go take a flying leap!

It's tools that were once useful, going right off the deep end of stupidity. It's almost like the bait and switch Google pulled with "pagespeed insights" a few years back, where they built it up as a useful tool, then turned it into a marketing scam that's nearly useless today and riddled with bad advice. Like slopping <style> into your markup. /FAIL/ at web development!

We're seeing that with far too many things of late; where anyone knowledgeable should be screaming "And who thought this was a good idea?"

If thought was put it, it was flawed in the extreme. From where I sit the current HTML "specification" is anything but, it's documentative nature making anyone with an engineering background laugh in disgust at the unmitigated gall it takes to even use the word "Specification" in reference to it.

They lost me when they went from telling us how to do things with good practices, to just blindly documenting what was possible and taking the Cave Johnson approach to feature management.

[mmerlinn]

You can't remember every little detail, use a quality reference!

Oftentimes it is impossible to find a quality reference. And if one does find one it is either gobble-de-gook or incomplete.

When I need info about a command or whatever, I find what I can, THEN OFTEN REWRITE IT so as to make it understandable and more complete, then save those notes in a subdirectory of the applicable programming language on my computer. If I need an answer about how to use a particular command, I first check my notes just in case I have been bitten before.

[goto10]

A computer language is like any other language - the worst part of the learning curve is right at the beginning when you're starting from scratch.

I think giving rules to absolute beginners is a great way to kill people's passion and bury them under the anxiety that they're "doing it wrong".

If you look at how kids learn a 2nd language (or even a first), they just jump in, make horrendous mistakes and hack around until they get the job done.

Because the job is getting their point across, just like a programmer's job is running code.

If you look at how adults (some with years of book study under their belts) try to speak a 2nd language most often you'll see a sweaty, stuttering mess, silently racking their brains for the correct conjugation of the verb while the person that they're talking to patiently waits.... and waits...

My advice to beginners? Find a project that you're passionate about and figure out how to make it. Start at the beginning and just don't stop. Get some little part working early on and take time to stand back often to see how you're progressing.

Worry about "the rules" later. Once you know enough to start applying them you'll see that approx. 50% of other people's advice is BS, at least to your circumstances.   

[Jason Knight]

I think giving rules to absolute beginners is a great way to kill people's passion and bury them under the anxiety that they're "doing it wrong".

See, I find that utterly nonsensical. Rules make it easier, because rules tell you how to do it. What you are saying is akin to teaching a child the word "cat" without any explanation of what a cat is, and then letting them throw that word at everything for the rest of their lives.

Londo Mollari: But this…this, this, this is like… being nibbled to death by, uh…Pah! What are those Earth creatures called? Feathers, long bill, webbed feet…go "quack".

Vir Cotto: Cats.

Londo: Cats! I'm being nibbled to death by cats.

If you're going to give them a word, teach them what the word means. "The cow goes moo". That's what the semantic meaning of tags are... and with what you're suggesting, well it's hardly a shock people are throwing P around lone images and/or fragments, or numbered headings around just because they want fonts in different weights and sizes -- something that has little to nothing to do with why a numbered heading should be used in a document.

Rules tell you how to do it. Clear, simple rules make life EASIER so long as they're well thought out, simple, and fair.

That's the problem right now with HTML, in undoing everything 4 Strict was trying to accomplish, we've just gotten further into the sinkhole of beginners confused out of their gourd, and "experts" who've worked a decade or more in the field but know less than most beginners.

... and this whole topic isn't rocket science. Honestly I think anyone could program well if the tools and choices of the industry didn't seem carefully crafted to make things harder than they need to be. See C syntax, the majority of frameworks, documentative texts masquerading as "specifications", etc, etc.

But what do I know? I consider ADA the pinnacle of programming language development.

[tracknut]

Editors, wizards, frameworks, and anything that "does the work for you"

The entire evolution of the computer industry is based on "things that do the work for you", so I'm curious how you rationalize the position. I remember (back in the dark ages) when I was learning C, thinking of people's questions "this dude has no idea how a computer works!". They hadn't learned assembly language first, and thus things like use of register variables and pointer math was confusing to them. There was some engineer saying the same about me, when I was learning assembly and confused about how I/O and interrupts worked.

So while I agree with the general points of "know how stuff works" and "know how to do it right", I don't believe it can be extended to "don't use tools that do the work for you". Finding those tools that actually help versus all the issues you describe, should be the focus.

n.b. I'm actually a bit surprised you refer to html and css development as "programming". I've always called them "scripting", but maybe that's just the pedant in me.

[Jason Knight]

The entire evolution of the computer industry is based on "things that do the work for you", so I'm curious how you rationalize the position.

Because...

1) this is about learning... if it does it for you what exactly have you learned. It's like having people do your homework for you in school.

2) MOST of these tools exist more as a tissue of lies than actual help, because how they work is typically the antithesis of good practice, results in harder to maintain code, and hobbles the skillsets of developer who learned "only the tool".

They cause more harm than good, end up making MORE work, lower quality work, etc, etc. No matter how many people run around blindly parroting how "easy" it is, or how much "better" it is for collaboration, or any other such malarkey. "For people who know nothing about development, BY people who know nothing about development" is NOT a recipe for success. EVER!

Just look at the train wrecks of ignorance, ineptitude, and incompetence created by the likes of John Resig or Otto & Thornton.

n.b. I'm actually a bit surprised you refer to html and css development as "programming". I've always called them "scripting", but maybe that's just the pedant in me.

Scripting is programming. Programming is creating sets of instructions to process data for users or to turn data into something useful for users. As such HTML/CSS is programming, and the sooner we treat it as programming requiring the SAME levels of skill, understanding, and learning as any other language, the sooner we'll stop having these bloated nuclear disasters of websites that tell users, search engines, and just about everyone else to go plow themselves.

... and the easier it will be to learn. Far too many don't take HTML/CSS seriously or act dismissive of concepts like separation of presentation from content, semantics, etc, etc... and all that does is make everyone's life harder.