How I think when I think about programming
alicemaz.com
alicemaz.com
As someone else has pointed out about themselves, I'm a battle-scarred, wizened, grumpy old man, with over 35 years of coding behind me (and still going strong. My latest checkin was about five minutes ago. I'm taking a quick HN break, before tying a bow on the project for the evening).
I've come to learn that not all new stuff is good, and not all old stuff is bad. I still use techniques and habits that I picked up, in my very earliest, Devonian Dev days, but I also really like some of the newer stuff; much of it only available, because of the advances in tooling and teaching.
I've also learned not to give a rat's ass whether or not people are impressed by me. The ones that matter, are, and the ones that aren't, seldom matter.
A lot of my programming is a hideous chimera of techniques, mashed together, and simmered at a low boil. It's a scary place.
Works well, though.
So while there are very wrong things to do it’s hard to have a specific “one right way”, and trying to obtain that is a pipe dream for most real codebases.
If your code doesn’t have a part labeled “here be dragons” you probably just don’t know yet where to stick the label.
I think it's due to a general realization that letter casing was an ancient mistake that plagues writing and case-sensitive filesystems. Having psychologically struggled with it and having been on both sides of the issue, I'm still deeply conflicted about it. Same with using "-"s instead of "_"s.
> general realization
That’s not a general realization, and historical anomalies don’t matter to the reader
I can't tell, is this sarcasm?
Of course the correct answer is “the file name” and let God sort ‘em out - or superchad and use Unicode non breaking spaces.
For the most part, most skills I've learned are like this... learn the basic rules, master the basic rules, then learn when to break the rules, and make new ones.
I had access to cameras, and could have bought one for myself, for a fairly large chunk of my life. It wasn't until digital cameras showed up that I could afford, that I became interested in photography, at age 34. In a similar way, I can see that someone could take up an interest in programming from out of the blue.
Like my path with photography, it was just taking photos, and learning how to get better results that kept it interesting. Time went by, and I got better over time. Programming is the same way.
Cameras and techniques change, as do Compilers and accepted practices.
I'd be surprised if most competent programmers don't do this kind of thing on their own.
You get vaugely familar with it, memorize some patterns, and VS Code's autocomplete does most of the details.
Variables, objects, classes, take days or weeks to learn, but beyond that the "learning" isn't like anything else.
When you play guitar, you control every note with your hands in real time. Every mistake is immediately audible. There is no algorithm for playing the right notes. You either memorize them and can get your hand to do them accurately or you don't.
And you can't unplay a note.
Which makes it 1000x harder than programming.
Because of debuggers, unit tests, and the fact nobody expects it to work first try, it's iterative, interactive, and mutable.
There's no idea>implementation pipeline, every level including the idea is something you can debug iteratively with computer help.
Programming isn't just being an "IDE Operator", there's some actual skill involved, but "IDE Operator" is pretty much how it feels when compared to anything else.
If I find a library, and tell you about it, you will be able to use it in minutes. Your capabilities have greatly increased, yet all you learned was that FooLib exists, and two or three function names.
Design patterns and language features work roughly the same way.
Technology is the art of so arranging the world so that we don't have to experience it, says the quote. But that includes tech itself.
Learning a new tech is usually like learning to use a washing machine. There's often nothing you couldn't learn from a page or two long article.
The small percentage of things that do require actual learning are where most of the challenge comes from.
The level to which programming is more like being a machine operator is so extreme that a lot of people take years to UNlearn the habit of actually doing things by themselves.
Beginners reinvent the standard library all the time, and sometimes feel like they didn't really do anything if they just put 3 libs they don't understand together.
In any other activity, the more professional you get, the more unique things are, the more you do from scratch, the more deep understanding is needed.
In industry, the farther you get from hobby level the more standardized everything gets.
If someone really does deeply understand what they're doing, I'd call that computer science more than programming.
Programming is not craftsmanship. It is not martial arts or cooking or war. It's not philosophy or math or literature.
I don't do code katas, ever. Because unless you do Haskell or real CS level algorithms, there's... not that much to know about the fundamentals, and IDEs largely do away with a need to memorize specifics
All the actual skill is in structuring ultra complex projects, and in domain issues.
If your program involves math, the programming is probably trivial, an the reason it's hard is because of the math.
I know that’s not exactly what you were getting at, but just wanted to add my 2c ;)
If you play a wrong note, you can slow down and practice more. If you do it ten times and still get it wrong... all you can really do is... just practice more. How long will it take? Who knows?
It's like programming for a computer that randomly inserts errors on 1%-5% of lines.
With programming, there is near zero challenge to implement something. Once you know what the bug is, you almost always know how to fix it, and are able to do so.
And once it's fixed, it stays fixed. The whole industry has collectively worked for decades to move as much of the work out of the coder's head and onto the CPU.
With any other activity, understanding means basically nothing. You have to somehow get your hand to physically do it. And you have to be able to remember the whole thing.
You have to learn one part, and then learn the next part. But if you forget the first part you have to completely start over, and none of it goes anywhere unless you know it all at once.
With programming... I have no idea how the code I wrote a month ago works. I might not look at it for a year. It's done, I've moved on, no ability to put anything beyond the most vague overview in long term memory is required.
I have no idea how people do ANY real life activity to a professional level.
Programming seems like not a challenge at all compared to even normal everyday things, even grade school level math, or any other occupation.
Even being a cashier requires being able to see the number on the screen, figure out how many dimes and how many quarters that is, all in just a few seconds, then physically count them out, with close to zero error rate. You could be fired at 5% wrong change complaints.
An accountant could probably be in trouble if they wrote down the wrong number 0.5% of the time or less.
Programming is one of the only professions that has the ability to retry your basic mistakes.
Every other activity relies on some inherent capacity to practice and become reliable at something.
Between guitar and programming, I would say that guitar is easier to get a basic proficiency at, though much harder to do at a professional level. I think that is largely due to supply and demand. There are very few jobs available for guitarists who are merely proficient, while there plenty of jobs for proficient programmers.
The ability to try things and make mistakes without consequences definitely helps to make programming easier, but it will only get you so far. There just isn't enough time in the day to program purely through trial-and-error.
Even learning a simple 4 chord campfires song is on a level of difficulty with a small production ready app, and the incidental work
My favorite story about this is that one year I found that I had left my keys in the front door and gone inside. I made it my top priority to learn to not do this. I programmed by phone to play a voice reminder when i connected to wifi after getting home. Sometimes I'd get up at 3AM in a panic and run to check if i left them there.
After a few months of this, I did the same exact thing at work.
I never did find a way to gain that skill to a totally reliable degree, I just used lanyards and Tile tracking.
Non programming activities are almost 100% things like that. Stuff where you have nothing to rely on but your own brain and body, and if you hit a wall and find yourself unable to improve it takes months to make small gains.
Unless you're born with a natural talent for learning simple patterns reliably... that's where a lot of of the real challenge of life is.
You can't completely program by trial and error, but you can program 10% by trial and error and 90% by actually getting it right. There's no requirement for consistency.
Minor mistakes are just 10 minute delays, so if you make 3 or 4 typos a day and have to wait for a compile to spot them, you can still be an above average programmer.
If you mess up making change that often(Which you probably will, unless you can reliably count to 5 every time in a fast environment), you'll be fired.
If you mess up that often while driving or as a pharmacist, people will probably literally die.