Hacker News new | ask | show | jobs
by drakaal 4406 days ago
Coding is easy. The problem is too many "teachers" expect you to have a larger vocabulary than you need.

I taught 3rd graders to code. I also taught 1st graders, but the 3rd graders it really clicked. They would come up with solutions to things I would not have thought were possible given the limited language we were working in.

We started in "Project Europa" it is object oriented, module based, and the vocabulary is very limited. But students built all sorts of virtual robots to do all sorts of interesting things.

When I learned to code I learned in RPG, and that doesn't stand for Role Playing Game. Then I moved on to Basic. Turbo Basic, and later QBasic. I wrote a 3D boxing game in QBasic. Yes. 3D graphics from QBasic.

To this day my vocabulary in any programming language is pretty limited. Those around me get upset because I'll use a While loop and increment a counter rather than a For loop and the Index of the thing I am looping through. It is not that I don't want to use the wider vocabulary, or that I have anything against Lambda's. I don't dislike Tuples. I have nothing against using a Class. But I don't usually need more than my 12 word vocabulary to build things. If I do, that is a performance optimization. What? Itertools and product will do the same thing I did with nested For Loops? So? I didn't know there was an itertools. I didn't know there was a product.

Someone said you need to develop a knack for asking the right question of google... Nah, sure StackOverflow has 90% of the answers you'd ever need to know, and they have a clever code snippet that I will admit comes in handy, but if you have to break thought to Google, you aren't breathing the code. It is like trying to learn Spanish by carrying the pocket guide with you rather than making do with the 12 words you know until you can learn 6 more, and then 12 more then 24 more words.

Take the training wheels off and suck it up. Machines are big and fast, large vocabularies are for people who want to speak concisely. A 3rd grader may not use the best choice of words, but he can still explain to you how to make a peanut butter sandwich, or build something in mine craft.

So don't let anyone tell you Programming is hard. Programming is easy. But there are a lot of ass hats who care if you should have built a function rather than copy and pasting the same code with minor variations 20 times. Or will say "you could have done that in one line with a lamba and a reciprocal function"

"Yeah, and Einstein had someone else do most of the math for his proofs because he kind of sucked at calculus. I'll get to optimizations after I have something that runs."

2 comments

> But there are a lot of ass hats who care if you should have built a function rather than copy and pasting the same code with minor variations 20 times.

That larger vocabulary you sneer at is much of what allows developers to be multiplicatively productive, allows them to do much more work and do it in a faster and less error-prone way.

Or, put another way: are they having to maintain your code when you get tired of it and move on or are they having to deal with second-order effects from your code being more brittle, less flexible, and slower to work on? 'Cause if so, they're not the asshat.

I looked at the nightly order-processing workflow for the regional retailer I worked for one time. I was gobsmacked to find that one section of it consisted of launching the same suite of 5-6 programs one time for each of our 25 locations. And "launching" meant setting a handful of run-time variables, executing the object, waiting for it to finish running, and examining the result.

It was fairly easy to see why this happened. That workflow was the heart and soul of the company's revenue processing, and no one wanted to touch it any more than absolutely necessary, to avoid breaking anything. So when they expanded from one warehouse to two, it made more sense to simply re-iterate the existing code with the new location id. When they added another location, re-iterate it again, and so forth.

I created a Launch subroutine, then replaced all those hundreds of lines of code with a for loop that simply called the Launch subroutine for each object needed. Then I went through the rest of the workflow and swapped in Launch calls where appropriate. Overnight, that workflow became much shorter, more readable, and most importantly, significantly more maintainable. Previously, if you wanted to change what programs were run per branch, you had to insert the launching logic in twenty-five separate spots. Now? Once.

That, my friends, is why we build functions, rather than copypasta-ing the same code over and over.

You might as well say "basketball is easy". Sure, dribbling a ball can be taught instantly, but your 3 pt percentage or rebounding skill can continually improve over the course of a career.

Just because you taught some 3rd graders a for loop doesn't make them coders and it certainly doesn't make them engineers.

The programming is easy myth is doubly bad: it sets a false expectation for the aspirants and belittles actual engineers' lifetimes of study.

Mastering anything is hard. But kids play basketball.

I can cook, but I'm not a master chef. That doesn't mean I don't do it. Nor does it mean "cooking is hard".

Riding a bicycle is a lot harder than basketball.

You pretty clearly have no conception of basketball at the level he's describing.