Important Things to Remember When Coding | Hacker News Reader

Important Things to Remember When Coding

medium.com

91 pointsjj-abram21 comments

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.

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.

"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.

How do you make it out of Comp Sci 101 without that faith? But it is true that the notion can persist that maybe just throwing in one more condition or expression might be the fix, no matter why.

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!)

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.

I always learn better if I write things down. I also remember better if I wrote down what my code does as detailed as possible. Also improves the search-possibilities when I need to find something three years later :-)

"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.

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.

If you return to your code a couple weeks or months later, chances are you'll be in the 'others' category too. So by writing readable code, you're doing yourself a favor most of all.

And THIS is how all the someones that "will always tell you you’re doing it wrong" always start...

(but I'm not saying that it's not an important point)

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.

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

You are right about bootcamps. I think that the entry point to programming has lowered. Most everyone who goes to a decent CS program understands pointers, recursion and object oriented programming at least to some degree. (I have to admit that I needed to relearn pointers a few times) Folks who didn't start from CS programs came from Physics or Math, and picked up on the theory quickly. It's very hard to learn this stuff after college.

Today there are a lot of people "learning to code" from other backgrounds. There are Marketing majors who follow the HTML -> CSS -> JS -> Ruby path that you mention. Good for them to start the path. Picking up recursion is an advanced topic for them - and good for them. It's all relative to the starting point. And I hope many of these folks stick it out to get good, because Stanford and MIT aren't churning out enough people to satisfy the demand.

She did, however, dismiss them as being hardly important to what she does. This is the ever growing phenomenon of "I can too" that is growing in our culture. I love the fact that more people are becoming interested in programming! I am not so happy about the fact that people seem to shirk the fundamental need to learn that underpins programming (or computer science... however you want to label it). If a person has no interest in learning recursion and pointers, I am not so sure that they are doing their company or the people who have to work with their code a favor. Then again, there are a lot of know-it-all programmers out there whose personalities are so grating that talking to them is an absolute slog.

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.

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.

Well - I think this article is aimed at people that are discouraged with their progress in programming for whatever reason.

All of the bolded items seemed extremely accurate. Especially for people I've worked with, those early in their career can really struggle with them. I'd love it if they took these lessons to heart.

Thus the title/subtitle:

> Things I Wish Someone Had Told Me When I Was Learning How to Code; And what I’ve learned from teaching others

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 :)

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

Great post. Inspiring.

Reply on news.ycombinator.com