
Things I Wish Someone Had Told Me When I Was Learning How to Code - iamtechaddict
https://medium.com/learning-to-code/565fc9dcb329
======
edw519
Nice post. A few more of my own:

1\. There is no substitute for the hours spent coding. Sure, you can waste a
lot of time, but there's a high correlation between hours spent and skill
attained.

2\. You can do almost anything with almost any tool. The energy spent debating
tools would probably be better spent building something.

3\. One of the biggest differentiators between a good coder and a poser is the
willingness and ability to go several levels down. Deep understanding comes
from deep diving.

4\. One of the best ways to deep dive is to benchmark. The milliseconds gained
will be a byproduct. The real benefit is your understanding of what goes on
under the hood.

5\. Write a framework. You may never use it, but you'll never be the same
programmer either.

6\. Almost everything you do will take longer than you expect, no matter how
experienced you get or how good you get at estimating. If it doesn't, then
you're not taking on challenging enough work.

7\. Once you regularly deliver great value to others, you will often feel like
an imposter. The compliments will exceed what you think you deserve based upon
how hard it was for you to build. That's OK. Accept it and enjoy it. It's
payback for all those hours you slaved away and no one knew what you were
doing.

8\. If you maintain a sense of wonder and delight every time you get something
new working, you will probably never get burnt out. Don't let anyone tell you
otherwise.

9\. When you look at your old code, most of it will suck. That means you're
always getting better. But some of it will still amaze you. Embrace and
harness that energy. Try to recreate the conditions under which you wrote it.

10\. Name your variables properly. That will always be half the battle.

~~~
sly010
Here are my two cents:

11\. Learn to read, navigate and understand code! Unless you are working alone
(but even then) you will spend a lot of time "uploading" code to your brain.
Code is read more than written.

12\. Algorithms are not nearly as important as some people make it look like.
I can't really remember if I ever wrote a sorting routine that is used in
production and I am still waiting for the moment A* will be useful. And when
that moment comes, I will just need to _read_ it on wikipedia.

~~~
ohashi
Re 12: It happens (sometimes? eventually?). It took me 15 years though until
that point came. And the answer was just looking at Wikipedia and other code
samples in other languages to get some understanding of it. I also implemented
it wrong and it kind of worked (not as well, but well enough) and only
realized my mistake months later.

------
Spearchucker
Biggest lesson after my 29 years of programming is the difference between the
best solution, and a successful solution. I.e. getting familiar with _system_
patterns (architecture) that work for your chosen stack/area of interest.

There are a million resources for specifics, like doing a server redirect or
creating a jump list for Windows Phone, but precious little on the end-to-end
implementation semantics of, say, a smartphone app that syncs content to a
server that scales out and up. Also, adding security, monitoring hooks, and
exception and configuration management. The realisation that open standards
are far, far more important than open source.

Similarly, the web is full of people _telling_ you to use Mongo, but again
hardly anything about being able to reference indexes in a document, or that
partition tolerance and availability come at the expense of consistency.

Get these things right and suddenly even using GOTOs, or the differences
between closed and open source, become non-issues because if your solution
_works_ , and is _successful_ , any ciritics of such semantics can go to hell.

~~~
erichocean
_a smartphone app that syncs content to a server that scales out and up_

This made me chuckle. I recently designed an entirely new way of doing just
that (to me, at least), and it's probably the 20th or more end-to-end approach
I've developed over the last seven years on that specific problem.

I don't know why scalable sync interests me, but it does. :)

~~~
Spearchucker
I'm in _exactly_ the same place.

------
stickhandle
A key for learning anything is being _curious_ and _exposed_ , in combination.
A great way to get that as a beginner (in coding or in a new environment) is
to take on bug fixes and CRs. While not always everyone's favourite it forces
you to dig into others code, see things you like/dislike, grok new concepts,
and challenge the inner-you with doing what's right vs. what is faster.
Perfection vs pragmatism - knowing what to side with and when is a key to a
long career.

~~~
sopooneo
What are CRs?

~~~
lgieron
Change Requests?

------
vezzy-fnord
Any particular reason for linking to a primer on C++ pointers, instead of C
pointers?

It's rare that you'll need to use pointers that much in C++ (compared to C
where they're definitive and essential), and type casting is stricter in C++.

I also laughed a little at the Joel Spolsky bit. But overall, sound advice. It
beats most of the empty fluff that the "learn to code" movement is producing.

~~~
joshguthrie
Lack of pointers in C++ has been the bane of my C++ experience.

~~~
bloodorange
What do you mean by "Lack of pointers in C++"? C++ has most of the pointer
stuff from C (except for some unsafe casts).

~~~
pantalaimon
You should avoid it though.

------
rmchugh
Nice piece. This definitely resonates:

"Braces should go on the next line. Braces should go on the same line. Use
tabs to indent. But tabs are evil. You should use stored procedures, but
actually you shouldn’t use them. You should always comment your code. But good
code doesn’t need comments."

~~~
mattmanser
Apart from some of them _are_ the wrong way.

Work on an over-commented code base and come back and tell me commenting
everything is good.

Work on a large crud app where it's 'SPs only' and come back and tell me SPs
are good. Worse still that particular debate is _dead_. The parametrized
queries not only won, they blew SPs out of the park with ORMs. Hence the
articles linked are 7-8 years old. And yet I still come across the occasional
programmer who uses SPs (who will generally think ORMs are evil rather than
massive time savers).

As for commenting, new coders _need_ to comment because they forget what they
did. New programmers can't read code properly, they need help from comments.
So it's good general advice to tell newbies to comment while they're learning.
But not in production code.

New coders also tend to get a revelation when they go back to some of the
first code they wrote and can't understand it. The revelation is 'I should
have commented it all!'. But the revelation is false, there are two reasons
they can't understand it. Firstly, it's crap code because it's their first
code. Secondly, they can't read code properly. But they can't admit it to
themselves because they think that _now_ they're good coders.

I've seen this time and time again, programmers with less than 2 or 3 years
experience often won't try to read the code and figure out the logic when
something goes wrong. Be it their own code or a bug in someone else's they've
been asked to fix. They start changing random variables or commenting out
lines. And yet they honestly think they are good coders.

Many time I have sat down with them to help, read the code and then pointed at
a line and said 'Hmmm, that looks wrong'. And that will be the bug. 5 min fix,
if you can read code. It's just part of the learning process and now I'm older
I can see the Dunning–Kruger effect as stupefyingly obvious in programmers. I
don't begrudge it, I don't think they're stupid or unskilled, it's just a
stage every programmer seems to need to go through. The stage where they still
haven't realized they can actually read the code to figure out what it does.

What's funny is that I can see _I_ suffered from it constantly in my early
years and was a right arrogant idiot.

~~~
girvo
I disagree with some of your points, and I have experienced what you pointed
out should be needed to bring that conclusion. This stuff isn't cut and dried,
so i just go with whatever the project is already using. Seems easier that way
:)

------
rmk2
> Before you learn to code, think about _what_ you want to code

This is and always has been my problem. I like to look at what other people
do, and I like coding in theory. But the little I need for myself isn't enough
to keep pushing myself. I don't work anywhere near programming, and I don't
particularly want to, either. Because of that, though, I haven't progressed
very far into SICP, my finished Scheme programs can be counted on one hand,
and most of my shell scripts are simple <1h (including looking things up) hack
jobs.

I only really script for personal use, and my personal usage patterns are
either not terribly demanding or too complex for me to satisfy.

~~~
a3n
Try automating some of your work. Pick one simple thing that you do a lot, and
write a small script or program to automate it: getting a handful of files
from somewhere; putting a handful of files somewhere; opening one or a handful
of files; creating the skeleton of a file that you will later flesh out.

I'm guessing you probably work in Windows because most people do at work;
their shells are either too simplistic and awkward (cmd) or nuclear-capable
(psh). Install cygwin and use the bash shell. Or do everything in
Scheme/Racket and don't worry about a shell.

Automate something today, something almost too simple to automate. Repeat.

~~~
rmk2
openSUSE & zsh all the way! ;) In all seriousness, though, my setup is a wee
bit unusual for somebody who _isn 't_ a programmer, since I work exclusively
in emacs via LaTeX & org-mode, stuffing all of it into git, on a openSUSE
system, zsh as my standard shell, i3 as my window manager etc.

The thing is, I do have a script for example to push the current git project
to various remote repositories or to create a new empty remote repository on
those servers, set it up locally etc. But there are few other things that need
to be scripted. I'm sure some of my things violate all kinds of sensible
programming standards, but they do work (e.g. looping through shell arguments
and then using case "$1" instead of using getopts, because it only allows long
arguments in a hackish way).

The problem, essentially, is that of the plateau. If I wanted to do something
that pushes things further, I'd need a _real_ project, not the odd, occasional
shell script. But for that, I lack the motivation, since, after all, it's not
really what I should be doing. It's a bit of a circular problem.

edit: My "job" is studying literature.

~~~
NAFV_P
> _edit: My "job" is studying literature._

I thought someone in your position might use regex fairly frequently.

~~~
rmk2
Mh, I don't really. There are few things that need to be changed all at once.
The only recent time I needed regex on a wider scale was when I botched org-
mode radio targets after a recent syntax change, which was a simple case of
replacing >> with >>> and << with <<< respectively, as well as extracting some
text from within square parenteses and put it on its own instead. But 1 to 2
lines of sed -i are not thaaat challenging! ;)

~~~
PeterisP
That poster probably meant things such as quantitative text analyis, comparing
language patterns used in literature, etc - which is mostly a question of
interpretation, but requires some skills in scripting for the initial data
gathering.

------
myopia
I agree with all of the points of the author. I'm currently in the process of
teaching myself iOS development (nathanmorgan1.wordpress.com - for anyone
who's interested) and have experienced some of the issues the author addresses
first hand. I'd like to say little on 'teach yourself to code' programs.

I often see these type of programs criticised here but personally, I can't say
enough good things about CodeAcademy and it's ilk. Even though I'm learning
iOS development its learn Javascript tutorials proved invaluable for me. It's
true, I wasn't building a 'real' project but the courses demonstrated to me
that I had an aptitude for coding and encouraged me to keep going with their
light-hearted approach and 'rewards'.

When I came to start learning iOS development, I had a range of transferable
skills and knowledge that I could call upon, for example I was comfortable
with loops, declaring variables and manipulating/defining objects.

So I think while these courses won't take you from beginner to employable or
experienced, they do serve their own purpose.

~~~
FLUX-YOU
>So I think while these courses won't take you from beginner to employable or
experienced, they do serve their own purpose.

This has been the deceptive part to me (and maybe it's only me). They're a
great way to get new syntax down, but as I've learned syntax from a few
languages now (Python, JavaScript, C), I really don't need these programs to
serve _this_ purpose. I learned how to learn new syntax from learning syntax.

Determining when you're employable can be difficult (entry-level at Google vs.
some LAMP web shop) and I'm sure that some portion of people trying these
programs are looking to switch careers. I found it easy to get the notion that
"If I learn through a bunch of courses and books and maybe do a few projects,
I can put these languages on my resume and get hired". That, unfortunately,
turned out to not be the case.

~~~
myopia
I agree with you, it is equally possible to learn syntax in other ways,
whether that's from a book or tutorial etc but I think these programs reach
people that may not otherwise have considered starting to code. They produce a
zero barrier to entry, needing zero expense and minimum effort to get started.

They also make the initial stages of learning to code 'fun' (I'm aware that's
a highly subjective term however) when learning syntax, often without having
grander goal in mind e.g. an app, can be a dry subject at best.

On your second point, are you referring specifically to people who complete
these courses or people who teach themselves to code and build a few projects?

EDIT:typo

------
tlarkworthy
The experienced programmer knows it won't work first time, and does not wait
until its finished before testing it. The time spend finding a bug is cubic in
the distance you have coded since last thorough testing. You test the
foundations are rock solid before building a cathedral on top of it. I find
the newer blood writes way too much code in one go.

------
drblast
I'm finally at a point where some programs I write work the first time. It's
very disconcerting.

~~~
gedrap
Oh familiar feeling. "There must be something wrong, it can't just WORK!"

------
Goladus
Good post. Though my experience with this one was slightly different:

 _Someone will always tell you you’re doing it wrong_

In my case, it wasn't that people were telling me I was doing it wrong, it's
that I saw all these people asserting the Right Way to do things and I was so
worried about doing it wrong that I would get bogged down worrying about tiny
irrelevant problems. But in the end what people cared about most was getting
things done, and usually didn't care as much about the methods as one would
believe reading the web.

The most common traits of all the best code I've worked with is _consistency_
and _thoroughness_.

------
burlyscudd
The executing process belongs to _you_ \- you should allow it no secrets in
its basic running.

First thing in any lang: learn the tools available for debugging and quickly
opening library code to trace execution. Set breakpoints; dive into stack
traces.

------
exo_duz
Like everything in life... Practice Practice Practice.... best advice to get
good at what you do.

------
xtracto
Well, HTML is not a programming language, given that it is not turing
complete. Hence, knowing how to write HTML doesn't make someone a programmer.

~~~
spacemanaki
A researcher in programming languages once told me that when she encounters
the "HTML isn't a programming language" meme she always thinks: Agda and Coq
aren't Turing complete, are they also not programming languages?

The point being, I think, that drawing this bright line at Turing completeness
doesn't hold up when you give it any thought, and so it's not very useful.
Aside from that, you've utterly missed the point of the OP.

~~~
acchow
How shall we define a programming language? At least as powerful/expressive as
a DFA? I kind of like that. (A bit off topic, but not really - writing out a
regex is sometimes harder for me than C++/Java/JavaScript. +1 for DFAs!)

