How I think when I think about programming(alicemaz.com)
alicemaz.com
How I think when I think about programming
https://www.alicemaz.com/writing/program.html
24 comments
There is a lot of rants in this article (more towards the end). It's great to be self reflective about how you do things, how you think, etc, and what choices you make and why, but this started to get preachy and state absolutes that other people should follow or take heed of. I've been doing software for 40+ years, and one observation I've made and it's something that keeps happening is people giving very definitive rules and advice, some of these end up becoming peoples guiding principles/values (things that are good, things that are bad) and mostly it just serves to put blinkers (blinders in the US?) on people and slows down exploring other ways of thinking about software. I get why we do this, and I get why someone wants to preach to newcomers (as this article states) and why we want to try and take our experiences and encode them into guiding principles, but it is easy to forget you only have the tiniest of windows on the world of software development. I think it's much more important to tell our stories, explain our reasoning, reflect on how we could do better and what we would do with 20/20 hindsight. Luckily on HN we see a lot of this style of writing.
I agree. 40+ years of programming experience as well. I have learned the hard way that programming is a huge area and you will only experience a very small part of it even after 40+ years of experience. I have also learned the hard way that we are all different and think/learn differently. So what works well for you is not automatically likely to work well for anybody else. So I recommend trying out different ideas/styles/methods/languages until you learn what works best for you.
I sincerely wish her luck in her endeavors. She seems to be a creative individual, and I look forward to her work, as she progresses.
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.
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.
The longer I’m around the more I realize programming is like the trades - there are theoretically perfect ways to build things but when things are actually getting built you sometimes have to bend.
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.
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 enjoyed reading your comment.
maybe it's pedantic but I don't want to read an article that can't properly capitalize sentences.
The author is likely using the enlightened coder capitalization rules, which informally are: "don't capitalize stuff". But, for reasons of insecurity and sometimes clarity, it often becomes: "only capitalize proper nouns, acronyms, and 'I'".
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.
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.
It’s not enlightened to apply programming semantics to the long form writing. It’s just ignorant that your readers have to suffer.
> general realization
That’s not a general realization, and historical anomalies don’t matter to the reader
> general realization
That’s not a general realization, and historical anomalies don’t matter to the reader
> 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.
I can't tell, is this sarcasm?
I can't tell, is this sarcasm?
I assume it’s pathname stuff - do you do hn.com/the-file-name or hn.com/the_file_name
Of course the correct answer is “the file name” and let God sort ‘em out - or superchad and use Unicode non breaking spaces.
Of course the correct answer is “the file name” and let God sort ‘em out - or superchad and use Unicode non breaking spaces.
[deleted]
I feel like i wrote this
This writing actually resonated with me. I, like the author, stumbled into programming, and I've been enjoying the journey so far. In a way, it feels like reading my future self a couple years from now. I think this article would be best for those who have an intermediate understanding of programming in a single high-level language but want to "look under the hood" so to speak. (I think this just means learning C). So it may not be for you, but it was for me.
If you've not programmed before, and you match Alice's way of thinking, then you can get to know what programing entails, and how to get started, in the roughest approximation.
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.
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.
I kept expecting to finally get to the part where this persons way of thinking about programming diverges from mine but never did. It just ended. Is any of this different from how other people think about programming? It all seemed pretty conventional.
What makes programming unique is that(Assuming you are a basic "code monkey" level web dev or entry level embedded like me), you don't usually "learn" to code.
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.
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 agree with most of what you wrote, but disagree with the part about programming not being a craft, or that algorithms are not useful to understand. There is definitely a great deal of skill involved and certain parts of it can be mastered. as an art/science/profession there’s so much we don’t yet understand about software. there hasn’t been enough time to establish comprehensive standards and best practices. But that doesn’t mean anything goes.
I know that’s not exactly what you were getting at, but just wanted to add my 2c ;)
I know that’s not exactly what you were getting at, but just wanted to add my 2c ;)
Playing a guitar is not 1000x harder than programming.
Maybe that's an exaggeration but t definitely seems like a whole order of magnitude extra difficulty.
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.
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.
As someone who programs, plays guitar and has worked as a cashier, being a cashier is by far the easiest. A month or two of working as a cashier with some focused attention to efficiency and memorization will put you ahead of 90% of working cashiers.
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.
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.
I've been trying to get better at guitar on and off for more than a decade, and almost all my jobs have had lots of incidental noncode work.
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.
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.
I think she should learn Haskell, she would appreciate the lack of punctuation and the consistent use of case in identifiers. It also makes you think.. a lot.