

Important Things to Remember When Coding - jj-abram
https://medium.com/@cecilycarver/things-i-wish-someone-had-told-me-when-i-was-learning-how-to-code-565fc9dcb329

======
beebs93
Good article - it's funny how easy it is to forget these points.

"Worrying about “geek cred” will slowly kill you"

This one rang particularly true as I easily overlook any successes I've had
because they're rarely made public. The ones that make it to the light of day
are never what I consider my best work. I'll see more popular programmers,
lament my relative obscurity and then the whole Impostor Syndrome will flare
up and nearly stop me in my tracks.

It's such a fantastic feeling to have leaned to say "meh, fuck it" and focus
on what I love about my vocation.

------
dsego
This is my favourite statement, really hits home.

> I’ve found that a big difference between new coders and experienced coders
> is faith: faith that things are going wrong for a logical and discoverable
> reason, faith that problems are fixable, faith that there is a way to
> accomplish the goal. The path from “not working” to “working” might not be
> obvious, but with patience you can usually find it.

~~~
corysama
"It's always something." (as opposed to being mystically causeless) is a
catch-phrase of mine when assisting new coders. I usually pull it out again
_after_ we find the mystery bug to reinforce the memory that mystery bugs are
solvable.

In my many years of coding, I can't count the number of times that completely
baffling bugs have eventually been traced down to errors that were concrete,
understandable and usually embodied in just a tiny amount of erroneous code.
My many, many experiences with this outcome gives me the confidence to keep
digging even when I have no clue where to look. Without those experiences,
what I do every day would seem like an unending stream of hopeless situations.
That's why it's important to share that confidence with new coders --to help
prevent them from failing due to despair just long enough for them to succeed.

------
ralphos
If I wrote an article with the same title I would only include one thing to
remember when coding and that is to write code with the expectation that
others will have to read your code. (This of course assumes you're not an ass
who wants to make people's lives more difficult!)

~~~
kbenson
I find that statement to generally sound good, but there are lots of nasty
details that are often overlooked. Taken to it's extreme, it leads to overly
commented code that tries to explain to non-programmers what a program is
doing. I find my time better spent than doing that for all code I write. Then
there's the question of who the expected reader is? Some future version of
you? Some coworker or successor in the same field, expected to be at
relatively the same level in the relevant areas? Some beginner in those some
fields. A programmer without experience in the relevant areas, or not yet
comfortable in the chosen language and able to understand it's idiomatic
usage?

Don't get me wrong, I'm in favor of the concept, I just find that most people
seem to put very little thought into what it means in practice.

~~~
warcode
"Others will have to read your code"

Comments are not "code". Your code should, when written impossibly well,
explain itself through variables, function names and composition. Better code
equals less comments needed.

~~~
kbenson
I think this is exactly the sort of position that leads to problems later when
people find their implicit assumptions don't match with those of others.

I can write perfectly idiomatic code in Perl, using map, grep, simple
postconditionals, taking advantage of built in functions that topicalize,
knowledge of when items are passed by reference or copy (or a sort of alias),
and the code will be very succinct and readable to Perl programmers. Should I
forego some of that to make the code more readable to general programmers?
Doing so will necessarily make the code slightly less readable to those
expecting idiomatic Perl.

I'm not espousing one way over the other, just that it should be thought about
with regard to the purpose of the code, who owns it, and who will be looking
at it in the future. The exact answer may differ in different situations.

------
andrewchambers
I don't know, I kind of stopped reading when the author said that
understanding pointers and recursion makes someone gifted in programming.
Those are really just fundamentals.

~~~
yzzxy
First of all, the author did not say she believed that, she argued that Joel
Spolsky did. I'm going to respond to it anyway because I think a lot of people
do think pointers and recursion separate the boys from the men[0].

In an era of coding bootcamps that claim to compress a 4-year CS degree into
4-10 weeks of adrenaline-fueled CSS/HTML/JS/Ruby memorization, and deem their
graduates programmers, it seems like many people follow that sentiment.

I believe this kind of thinking is not so much harmful as laughable - in my
experience studying programming has been an exercise in learning about the
existence of more and more complex topics I don't understand yet. First it was
OOP, then design patterns, then functional programming, and now I'm glancing
over the horizon towards type theory, language theory, etc.

Getting pointers and recursion are very, very, early steps (though hard ones!)
on a long journey.

[0] s/boys/girls s/men/women

~~~
andrewchambers
Well I'm not from a web programming background, I started with game
programming in C. Maybe since web is so design heavy it doesn't matter if you
don't understand what I would consider fundamentals.

~~~
thaumaturgy
I worked with C, C++, and assembly -- and others -- before picking up web
programming. They're just different, but people still insist on getting their
egos involved anyway.

With OS and applications programming, you typically have to know a handful of
concepts, but you have to know them really well. With web programming, you
typically have to know _a lot_ \-- it can be an obnoxiously broad field of
practice -- but you don't have to know it all perfectly well. CSS or JS or PHP
or Python or Ruby or what-have-you generally immediately works or doesn't
work, you generally don't encounter those annoying null ptr situations.

I doubt there are a lot of C programmers that could do web development (front
and back end) very well. I doubt there are a lot of web developers that could
do OS development very well.

But it's all just programming.

All of software development would be a hell of a lot better environment if
people would quit waving their egos around.

------
baldajan
Some really cool points on getting started. Coding is hard and "coders" (like
me) take getting started for granted. Worse, for new coders, it can sometimes
feel like you need to jump to the top of the mountain rather than taking it
one step at a time.

In the past, I found the best methods of picking up coding or new languages is
to work on a small multi day/week project, and preferably with a friend that's
just as lost as you are. It's great cause you'll have a support system in
place and having two brains thinking about the same problems, which helps
tremendously when treading carefully - or spontaneously (up to you :)

------
ChrisArchitect
good post, the points are feel-good/inspiring. Suprised this didn't get posted
earlier (noticed it's a year old!) oh wait, it did 4 months ago but no one
noticed ..hmph

------
icypy
Great post. Inspiring.

