
Tales of coding from a beginner - ollipp
https://medium.com/@meandvan/how-i-learned-to-stop-worrying-and-love-the-code-af1a809457c7
======
chestnut-tree
_" 3\. Equals is a lie: = ≠ ="_

This is why languages like Pascal (and it's descendents) use := as assignment.

There are contradictory opinions about sytnax among programmers. Many
programmers don't like the example assignment syntax above, but then many
programmers also say that syntax is a relatively minor aspect of learning a
language (even though the syntax of a language shapes the way you think about
solving problems).

And many programmers do avoid certain languages precisely because they dislike
the sytnax.

Nikalus Wirth, who created Pascal, Modula-2 and Oberon, had this to say about
using the equal sign for assignment:

 _" A notorious example for a bad idea was the choice of the equal sign to
denote assignment. It goes back to Fortran in 1957[a] and has blindly been
copied by armies of language designers. Why is it a bad idea? Because it
overthrows a century old tradition to let “=” denote a comparison for
equality, a predicate which is either true or false. But Fortran made it to
mean assignment, the enforcing of equality. In this case, the operands are on
unequal footing: The left operand (a variable) is to be made equal to the
right operand (an expression). x = y does not mean the same thing as y = x."_

~~~
YeGoblynQueenne
The funny thing is that there is a mathematical symbol for assignment, the
left-arrow, "<-". At least it's used widely in algorithmic notation to show
assignment- and also in R.

~~~
mojoe
I program a decent amount in R, and this left-arrow assignment operator is
incredibly annoying. I believe it's a holdout from the days when there was a
single key that would input '<-'.

~~~
enf
Yes, in ASCII-1963, there was a left-arrow instead of underscore.

------
PuffinBlue
Just what the doctor ordered!

I'm just starting out[1] and recognise all of these points, especially number
4 even though on first glance it might seem the wrong attitude.

Every time I run into something new I feel the need to 'fully' understand it
before moving on. With such a vast corpus of information out there and a
lifetimes worth of skill development in just one particular branch (database
admin anyone?) I have certainly felt that sinking feeling when yet another new
thing pops up.

Learning part time has not helped this as it becomes easy to say 'oh I'll
catch up on that later but I won't start anything new yet'. That leads to a 6
month gap of getting anything appreciable done, at least for me!

Tomorrow I start full time in this learning endeavour (very lucky I know) and
these 8 points probably won't be far from my mind when trying to actually get
stuff done.

[1]
[http://josharcher.uk/categories/odin/](http://josharcher.uk/categories/odin/)

~~~
captn3m0
Take a look at rawgit for demoing your github work:
[https://rawgit.com/](https://rawgit.com/). Your google clone becomes:
[https://cdn.rawgit.com/PuffinBlue/google-
homepage/master/ind...](https://cdn.rawgit.com/PuffinBlue/google-
homepage/master/index.html). Far more easy.

~~~
PuffinBlue
Thanks, that is easier. And I see the little microphone icon is misaligned now
on Chrome, it used to be correct!

------
theCricketer
Question: I'm curious to hear other people's experiences with "4\. Stop asking
questions". I ask questions quite a bit. It does slow me down. But I feel like
if I understand something, I can move faster in the longer term, besides the
value derived from just understanding how the system/abstraction works.

~~~
uoou
I think the point is not to get paralysed by the desire to know everything at
once.

Each question tends to just give rise to ten more. Which is fine for someone
who has a conceptual understanding of programming-in-general (whether from
studying it academically or just being more experienced/talented), enabling
them to contextualise all that information. But for the beginner who is trying
to self-tech (self-learn?), even if they understand the words, they don't
really _mean_ anything.

>Django is a application framework, written in Python, which follows the
model–view–controller (MVC) architectural pattern

I may know what all those words mean and thus understand that sentence. I may
know what MVC is (in that, again, I understand the words used to describe it).
But until I've done a bit of Python and implemented something following the
MVC pattern (and compared it to the alternatives) I don't really _get_ it. The
knowledge has to become practical to be useful.

It's better to only ask questions that go one level deep at a time, practise
what you learned until you actually understand it, then ask the next level of
questions.

For self-taught coders who are never going to be amazing at it but just want
to make stuff (like me), I think this is very good advice.

~~~
mmahemoff
To elaborate, the goal should be to move forward by cycling between asking
questions and doing something:

Ask question <\-------> Do something (ie bang out code)

The "do something" will never be perfect, so don't waste hours trying to
understand the theory perfectly. Use the coding time as a way to both test
your knowledge and drive further questions.

This is why it's helpful to pick a motivating project while learning to code.
It keeps you moving ahead and makes sure the "question time" is truly filling
in the knowledge gaps you need to fill in.

~~~
uoou
>This is why it's helpful to pick a motivating project while learning to code.

Very much the case for me, yeah. I've tried learning from tutorials and books
and I just get bored. But if I come up with an idea and try to make it, I
_love_ it, learning the bits I need as I need them.

Should note that I think that if one is _capable_ of learning the academic
way, that's probably a better approach. Understanding programming in the
general and thus being able to apply it to the specific. You'll certainly make
better code that way.

But for me, for whom learning that way is never going to work, the ad-hoc way
is fine. It doesn't really matter if my code is scrappy so long as it works
and doesn't do harm.

------
Rifu
Personally, I've always read '=' as meaning the left hand side was equal to
the right. So if I see

x = 5

then I'm already assigning the value of 5 to x, because they're equal! Does
that make sense? Curious to see what others think, because before reading this
article, I didn't even realize that was a particular tripping point for anyone
looking to start programming.

~~~
xorcist
Then you read it as assignment. It's a bit unfortunate that it means something
else in mathematics. Pascal used := as the assignment operator, and used = as
the equal test. It could also do 1-based indexing of arrays, which is another
classic pain point when you start programming with just a tiny bit too much
knowledge.

------
zwetan
When a good friend of mine started to ask about learning programming I
answered that

“be ready to do it every day, be ready to learn for the next 10 years”

asked him to seriously think about that and we’ll talk again in a week

there is much more to it, but imho those are the 2 points that I’ve seen
somehow valid for the last 20 years or so

and when I read “I’ve been on again off again with it” I thought “first
mistake”, really if I would have 2 quick advices to give

do it everyday: because it test how much you can take, if you feel programming
2 days in a row is “too much” that’s probably a good sign “it’s not for you”

be ready to do it for 10 years: search “Teach Yourself Programming in Ten
Years” by Peter Norvig and you will understand why.

A lot of ppl when it come to “learn how to program” underestimate very basic
stuff like the involvement and the time it take, I saw ppl give up just
because it took too much time or because they thought they would be good at it
much sooner.

So yeah staying in front of a computer for hours, for days, solving problems
with code, it may not fit everyone, but to me the longer you can keep at it,
or if you forgot to eat, to sleep while doing it, are in general good signs of
“you can do it”.

All the 8 points are very valid, even if some could be argued, I personally
remember the fear, back in the 90s for a full month I was paralysed because of
the fear to do wrong, the fear to break stuff.

If it was not for this older guy who kept encouraging and reassuring me I
would have probably gave up, so I would say try to get a mentor.

But the opposite advice would work too: don’t get a mentor and try to
understand everything by yourself, or in another context: resist the urge to
go ask your question on stack overflow and try to solve as much of it by
yourself. Solved it? then keep not asking questions on stack overflow as long
as you can.

IMHO there are many ways to learn programming, some advices would not fit
everyone, there are no best ways to do it.

~~~
harianus
I think I'm going to use this comment for friends asking if they should start
programming. Especially the do it every day think is quite important I
believe. Thanks for sharing this.

------
dankohn1
One of the reasons I love Hartl's Rails Tutorial
<[https://www.railstutorial.org/book>](https://www.railstutorial.org/book>) is
because he integrated a completely free c9.io account which (with the commands
he gives you) is guaranteed to setup Rails and a shell environment identical
to what the book expects. I have seen so many aspiring programmers stymied by
things like installing a text editor, let alone the right version of Ruby or
incompatible gems. And, people with less money are more likely to have a cheap
Windows laptop, which makes configuration even more difficult. By contrast,
anyone with a computer or even an Internet cafe should be able to get an up-
to-date browser, and c9 is plenty good enough for getting started.

I've started taking my 9-year-old son through the book, and though it's crazy
how large a vocabulary you need if you really wanted to understand everything,
that's not actually necessary and he's able to follow the directions and make
progress.

------
dpc_pw
> Getting things installed and set up is where 70% of your time goes when
> you’re starting out. (...) I remember whole days dedicated to just
> installing a damn module. This is normal.

It's not normal to struggle with installing modules / libraries. It's just
Python sucking. Normal programming languages rarely give you this kind of
headache.

------
wes-k
I absolutely agree about the words 'just' and 'obviously'. I've been trying to
cut them out of my vocabulary. The word 'just' has this feeling of being short
with someone. And that they are a fool for not knowing what to do already.

"Just put the book down over there". "You just need to..."

------
jimkri
#2 The Fear. This is what I have struggled the most with. During all of my
programming classes I worried that I was not cut out for it, because I am
business student minoring in comp sci in the world of students who live for
programming. But after a while I really learned that everyone in class always
struggled with the same problems that I had, everyone was just to proud in a
way to ask each other for help. Eventually everyone broke down and that was
when the most fun happened in class, and with the programming. It was really
cool struggling with other programmers.

By the end of all my programming classes my fear was not that bad, but I still
fear doing any hack-a-thons or anything like that, because I shoot myself
down.

I am working on getting over that fear, but its good to know I am not the only
one.

------
psibi
> Equals is a lie: = ≠ =

This has occurred opposite to me while learning Mathematics. As a programmer,
who has been learning fundamental mathematics from the past year, the whole
assignment/equivalence thing screwed me up so many times.

~~~
danidiaz
In pure functional programming, = = = (bindings are unmodifiable, and it's
easier to substitute equals for equals).

The assignment operator should have been <\- or something other than = from
the beginning. I wonder if there was some discussion about that, back in the
day?

~~~
talaketu
as it was in algol day. :=

~~~
gaius
Or in many functional languages you might say something like

    
    
        a <- 5
    

Which is quite intuitive.

------
chrismcb
Catch up? Catch up to whom? You will never really catch up to the people with
a ton of experience today. If course at some point you might know something
more in depth than them. And you will be ahead of people who start after you.
Don't worry about catching up, worry about learning what your you are doing.
That is all you can really do.

------
Widdershin
This is an excellent collection of insight, thanks for sharing.

------
lordnacho
I went from basically zero (a week of C in college) to where I am now by
working on it pretty much every day. And the only way that was possible was
because I actually like programming. She should say something about how her
motivation levels are doing.

In terms of development as a coder, I think there's a number of plateaus. It's
easy to recognize those below you, hard to see those above. So here are those
I came across:

\- Able to make simple modifications to other people's code. Everyone starts
here. If you see backgroundcolor = red, what happens if you make it blue? You
have no idea of what the platform is, how the codes executes, what slightly
unusual syntax means, etc. At some point, you will exhaust the places where
your guesswork works, because there aren't that many straight replacements in
most code.

\- Able to implement your own functions. Some Excel spreadsheet doesn't have a
function that you want. You type it out and testing is a few times will
uncover some corner cases that you can fix. Still no idea of how to organise
things, especially since the trading floor mentality is that time is money. So
you have an ungodly amount of VBA functions, all over the place. There's an
enormous number of guys in finance at this level. I went to see some guys from
a well known bank running several billion dollars of funds with this kind of
spaghetti.

\- Realised that Excel is a crappy way to organize code. Discovered you can
write your own standalone programs without knowing everything about how the
screen is drawn (and I still don't know the nitty gritty of it). When you
realise a great deal of code is already written for you, that's massive. Of
course I take the screen pixels as an example, but it's true in just about
everything that you write. For the most part, you are glueing things together
that already exist. So now I could write VB6 programs and .NET as well.
Realised there was a lot I didn't know that was already working out of the
box. I wrote a poker probability calculator back during the poker boom to help
me give money away more efficiently (guess what, it's not just the odds that
matter).

\- Spent ages learning about SQL and databases. Looks easy from a distance,
rows go in, rows comes out. But why does it take so long? What's an index?
etc.

\- Started to realise there's a whole load of interesting ways to organize
code. Object oriented of course sticks out, and you can't avoid it. It will
take a while to write classes that are not just oddly collected functions.
Maybe run into the GoF patterns. At this point, a large rewrite might occur as
various Eureka moments happen. Also you may be doing a LOT of backtracking,
because OO isn't all that obvious. Maybe look at functional, or at least
figure out what first-class functions means.

\- Started to look at performance. The vast bulk of code up to now needed zero
performance optimization, despite being inefficient. At some point, you wonder
why a calculation that can be explained in a few sentences can take a non-
neglible amount of time. Queue big-O notation. Memory profilers, timers.
Threading issues. Cache coherence. Network stack.

\- Started to look outside of finance. Web, apps, etc. You realise there's a
value to being polyglot. Also that if the foundations are there, switching
between technologies is not hard. Looked again at architecture for scale.

Anyway, I could write a book about this journey. Or I could just continue
coding.

------
cdubzzz
> Setting up is something that fully fledged developers still battle with.

Amen to that. I have made a perfectly successful, 10+ year career of
development in PHP with some JS sprinkled in there. But I still do it in
FileZilla and Notepad++. Lately, I have been trying to learn about newer
technologies so I have taken up learning JS more seriously using WebStrom and
Python using PyCharm. I've been picking up all kinds of things bit by bit, but
in the last few days in particular I have taken up a small project and gone
down a road of:

* Python

* PyCharm (and IDEs in general - anything beyond syntax highlighting)

* React

* Node

* npm

* Babel

* Git

* Github

* Gulp

* Browserify

* File watchers in PyCharm

* Bootstrap

* React-bootstrap

* sqlite

* Database integration in PyCharm

* jQuery (the only thing on this list I have any previous experience with)

* Moment.js

In the time it has taken me just to understand how all these things work
together and the way I need to use them, I would've been able to fully
complete the project I am working on if I were just using PHP and FileZilla,
hah. As it stands, I'd say I'm about 5% in to it.

Absolutely worth it though. I've made many revelations along the way and am
definitely seeing how amazingly useful these tools (the IDEs in particular)
can be once you have a grasp on them.

~~~
gopowerranger
I started getting trapped into what you're complaining about, and now say it's
worth it, but what happens when something better comes along or something gets
abandoned? What happens if three of those things on your list become a
problem? Is it a house of cards?

My company always followed this statement I made up years ago, "Everything
should be as simple as possible", but we started bending to large contracts
that insisted we use "just one thing", some framework or library or tool, that
they used which we found no use for. That made it "easier" for the next client
to say, "Well, since you use that, you can use this", and all of a sudden
we're getting bogged down wondering which tool is the best, learning those
tools, keeping track of the latest changes, dealing with incompatibilities,
integrating and interfacing, and on and on.

All of a sudden I realized we had a list of things we never worked with
before, or even needed, for our small $2.x million web dev company but it felt
like we spent far too much time dealing with them.

So we were in a meeting, a meeting we put together just to solve the problems
of updating and integrating problems when it hit me what was going on and I
yelled, "STOP!". It was a "wtf are we doing?" moment.

We had lost our direction. We had almost gotten to the point where we couldn't
nail two pieces of wood together cause we didn't have an air hose for our
pneumatic nail gun.

(I just realized I"m writing a book here so I'll get to the end.)

We went back to the fundamentals. We're a web dev company and we use ONE
programming language, ONE source control, with HTML/CSS/Javascript. Almost
always the tools we need are available on FreeBSD/*nix. We're more relaxed,
faster, quick to adapt, and if a customer really insists on using something we
don't, then it's either on them to deal with it or we hire a freelancer but
then treat him as a black box interface to that with no contact otherwise.

And now I'm bored writing about this.

~~~
cdubzzz
Agree totally on the struggle being worth it. I'm not really complaining (at
this moment, anyway, hah.

It is amazing how fragile it makes everything seem. I think a lot of those
tools are safe, but yeah seemingly at any moment something could be abandoned
or there could be some other drastic change in the chain.

Example: I can't even remember the specifies of this, but somewhere along the
line I was having a hard time working with some npm module and while searching
for answers I discovered multiple sources saying the module was "blacklisted".
This eventually led me to an easy working replacement, but I still have no
idea what the "blacklisting" means - it was still available on npmjs.com.

Also, building my Gulpfile.js was very interesting (and time consuming!).
Seemingly so many different ways to approach it and I'm honestly not even
_quite_ clear on how I got it to work right so hopefully that doesn't break on
me.

The only part of all this I expect to act on at my actual work, for now, is
the IDE. I think I could really benefit from getting myself up and running on
PHPStorm instead of Notepad++/FileZilla.

------
gaius
9\. Learn to call it programming, not "coding". It's like a professional chef
referring to what they do as "chopping".

~~~
morokhovets
For me, "software engineering" is even better term.

~~~
kawera
"Software engineering" certanly feels better but I think generally our work is
closer to a craft than an engineering practice; imagine if we built bridges,
tunnels and planes as we build software - catastrophes every day!

~~~
antod
As someone who learnt to code as a kid, then studied and worked in
civil/structural engineering, then ended up later on back in software, I do
find comparisons (somehow always involving bridge analogies) between software
engineering and 'traditional' engineering to always be off somehow.

Most traditional engineering projects are not magical bastions of rigor and
certainty. It is really only in very large budget or critical projects that a
lot of analysis or rigour comes into play to create that certainty.

At least in the civil/structural world you'd be surprised how much comes down
to just gut feel by experienced engineers who then throw down some very quick
calculations (budgets don't allow for much more than that) to back up their
choices. Most numbers are looked up in tables. They then hopefully get run
past another experienced engineers gut feel for validation then get signed
off. And most of the time the public agency will just accept that uncritically
- as they no longer have the resources to double check designs themselves.

The main difference with software as I see it, is that software is binary and
the real world is analogue. Civil/structural engineering standards have
factors of safety for materials and loading codes etc to cope with
inconsistencies or minor mistakes/oversights or unforeseen circumstances etc.
Even most failures are not catastrophic and can be detected and fixed before a
catastrophic failure eg things can yield or crack rather than snap.

Software being binary though means for a certain set of circumstances it
either works or it doesn't. You don't have the luxury of factors of safety and
just overspeccing components to be sure.

~~~
kawera
Thanks. You are right, the comparison is off probably on both sides.

As with critical civil/structural engineering projects, there are software
development projects built with correctness in mind. I've worked on a few of
those, mostly in aerospace and VLSI simulation in the late 70s til the early
90s, and the level of engineering was very high.

Fast forward two decades to the world of web development and corporate IT and,
wow, the lack of rigour is simply abysmal. I can imagine the same been true in
the housing/building sector.

------
InfiniteEntropy
Lesson One: Don't go on ##java@freenode and ask homework questions.

~~~
voltagex_
Probably not. Are there any welcoming IRC channels? I know of #phpmentors but
what about for other languages?

~~~
exDM69
Asking for mentoring and asking someone to do your homework are two different
things. There's always been and there always will be freshmen who attempt to
short cut their way through classes by trying to make someone else do solve
their homework. It is and should be frowned upon.

Politely asking smart questions about how to progress in your homework, on the
other hand, is just fine.

