You are everything that makes people conflate enthusiasm for low level knowledge with gatekeeping.
This is honestly getting worse than gatekeeping, entering the realm of illusions of grandeur.
I actually can't reply directly anymore because everything I'm posting is being downvoted to hell, but it's fine, I know implying the unwashed masses blindly cutting and pasting SO answers are doing just fine for themselves is taboo in a place where people feel programmers should be taking PE certification exams
but anyways, here's my response:
-
> Now compare your experience to that of the hypothetical stockbroker who's diving into React native app programming without even really understanding what a loop is. He has decades to go before he understands what he's doing! What's NPM? What's a text editor? Is that different than a word processor? I screwed up my initial install... how can I start over? Insisting that programming is really easy and it's gatekeepers adding requirements that make it hard isn't doing him any favors; he's going to feel like a complete failure.
> _he's going to feel like a complete failure._
Why? You're casting this accusation on this hypothetical stock broker. Why are they going to feel like a complete failure?
How is this hypothetical stock broker any different than I was literally hitting random buttons in the programming menu of his father's calculator until he made some text appear?
> you started from the bottom/most concrete layer of abstraction
No, I didn't. I started from BASIC, I only learned C because assembler looked like greek and I heard you needed assembler if you wanted those fancy graphics all the best calculator games had and I learned that C let you write assembler somehow without writing assembler.
If I had quit because I didn't understand half of what I was doing (I didn't) I wouldn't be a programmer today.
I didn't feel like shit, I felt like a kid who had just found a candy shop, what great things were there for me to learn next?
Sure I had doubts, but they were easily drowned out by any modicum of progress I made, and soon enough I learned that it's ok because _no one_ knows all the fundamentals.
Out there there's someone who's scoffing at this talk of "knowing assembler lets you know how computers work", they're ready to bust out explanations of instruction pipelining, speculative execution (for now),
how memory controllers work, what the micro controller in your HDD and SDD is doing to let your assembler do any kind of useful IO without understanding how underlying media works.
-
And also, if the stock broker quits because they don't understand what they're doing, in what universe is telling them:
"Actually go and learn this other stuff, that's the fundamentals. Just realize has a much much MUCH longer feedback loop, there's orders of magnitude more surface area before you get back to the level you were working on and can produce something that you recognize as being on the path of making the app you wanted"
Going to get them to _not quit even faster_.
In my experience the best way to get people feeling empowered is to let them make something that they can envision being on the path to what they want to make.
Writing a hello world in assembler and having it show up in a command prompt is not going to get my stockbroker friend nearly as happy as writing a hello world in React and running it on his phone, because he sees a glimmer of how the latter gets him to his goal of an app.
You're ascribing individual behavior to a broad set of people because they don't agree with your approach to learning being in their best interests. That's what I have such a problem with.
Who cares if they don't know what NPM is, who cares if every time he screws up he opens App Copy (23) and deletes the current one.
If they're going to quit because they don't know what NPM is or what a text editor vs word processor, how is sitting them down and trying to get them to understand assembler going to ease their anxiety?
And if you feel that's hyperbole, even getting them to understand NPM past copy and pasting commands. You'd be amazed at the things people have built that help real human beings do useful things every day while never truly understanding how NPM works.
There's nothing wrong with embracing people having no idea what they're doing just running at the wall until it starts to stick. It's what I did, and I couldn't have done it any other way.
the only profession in the history of humanity that is simultaneously assumed by so many to be something you need only a cursory understanding of to be proficient at.
This can be traced to the 1970s.
Computer Science is only half of a field. Semi-arbitrarily splitting it off from EE harmed both fields. Instead of one complex field, there are two very shallow fields.
I still can't figure out how programming computers (the most complex task a human can undertake)
Neuroscience, making pizza (or most cooking, really), marketing, high-speed motorsport, psychology, most weapons development (outside of guns, which are fundamentally simple), writing mass-market books and drug development all seem to have programming beat in terms of complexity for what ninety-nine percent of professional programmers do.
Jobs worded it well in an interview at one point. Something along the lines of, "I knew there was a market for people who would never be able to design hardware or put a kit together but who still would love to write their own software," in the context of why the Apple II was successful. It works just as well to show why the field is the way it is.
Most computer programmers don't have a clue how the hardware works. That used to be an essential part of it. It's not any longer. The bar has gotten lower and lower, and that's not necessarily a bad thing. Python can be learned in an hour, so why not? They can still make useful things, so there's no problem with it.
Just like in any other field, the bar for "proficient" is low compared to average, but the bar for "exceptional" is high.
I wouldn't even say the bar has gotten lower.
The bar has multiplied into multiple bars all at the their own levels but in different dimensions.
You can have an innate understanding from a single transistor to how individual frames are handled by an ethernet PHY to how the packet scheduler will interact with your userspace app and be an "exceptional" developer.
But the moment someone asks you to write an Android app that hits and endpoint and displays the data with some formatting none of that matters if you've never written an Android app.
Nothing is exceptional in a vacuum, and "programming" is so vast with so much space between disciplines it might as well be a vacuum.
I think there are extremes here, and you and 'commandlinefan are on opposite sides of the extreme. I'm somewhere in the middle, in that I agree with neither of you.
Writing an Android application is not something that requires anyone to learn an entirely new skillset. At most, it's a programming language and a toolkit of difference for any experienced programmer.
...
How is learning a new programming language and new toolkit not learning a new skillset???
Even in a literal sense of the two words:
Skill: "a particular ability."
Tool: "a piece of software that carries out a particular function, typically creating or modifying another program."
How is learning "a piece of software that carries out a particular function" not "a particular ability."
-
In a non-literal sense, learning to write an Android App is a new skill if you didn't know how to do it before. Like you could happen to have Java experience so it's less new to you, but either you knew how to do it before, or you didn't and now you do... so you learned how to do it.
Are we literally at the point of gatekeeping what it means to learn how to do something??
How is learning a new programming language and new toolkit not learning a new skillset???
Riding a Mongoose bike is not substantially different from riding a Schwinn bike. Riding a pink bike is not substantially different from riding a green bike. Writing Java is not substantially different from writing any ALGOL-derivative.
It's like saying writing a program for FreeBSD requires a different skillset than doing so for NetBSD. It doesn't.
Not everything is gatekeeping, and it's disingenuous to claim so.
Haha oh god, in one fell swoop you’re acting like writing Android apps is just knowing how to write Java and writing Java is just like writing any Algol-like.
You literally reduced language design to changing colors on a bicycle.
Are you joking?
You have no idea what Android is if you think it’s development process vs Java (which Java? Embedded Java, desktop with JavaFX? Server side?) is like FreeBSD vs NetBSD.
Maybe more like FreeBSD vs Windows and you’re trying to write a UI application, but technically you can use C on both platforms so it’s the same right?
Thanks for the chuckle in these dreary times...
By the way do you actually think syntactic differences are all that separate languages so once you know the general syntax you pretty much know the language, or are you pretending to not know how programming in multiple languages actually works to prove a point?
Really it's about tone:
"It would serve everyone well to start at that level."
Backhanded way of saying the guy who only learned the Javascript keywords would have been better off spending their time trying to learn to program from first principles.
Which is extremely condescending if you think about it, for you to assume you know what's best for all these people who are already being productive technologists.
If that person takes the time they used to make software that helped in the lives of 1,000,000 users, to instead learn how to improve memory access patterns in their CRUD app, who is it better for? Your ego?
It is a form of gatekeeping, even in your comment you're being extremely condescending, like those programmers aren't "real" programmers until they learn algorithms and data structures, and implying they find programming computers simple because they're not really programming.
> you'll be a better programmer in any language if you understand assembler
Better by what measure? You can write code that takes one order of magnitude more for every single task it completes and still help more people and enable more productivity than the guy who dedicates his existence to hand unrolling loops and implementing obscure data structures hand picked from the Library of Alexandria for their perfect match to the current use case.
And this is all coming from a guy who taught himself programming starting with calculators in middle school by the way (TI-Basic => C via SDCC => Assembler on calculators and MCUs before I ever even touched programming for a desktop).
And since those days I've always found programming incredibly simple and intuitive. The computer does what you tell it to do, and that's that. How many professions in the world are there where your tool is nearly infallible in its ability to correctly execute your thoughts exactly as they're transcribed?
Can you be more productive by learning some deeper levels of knowledge? Sure.
But I don't advise anyone listen to someone who makes blanket statements about how all developers would benefit from "hand-assembling on pre-printed carbon sheets", or anyone who tries to defend that.
-
Oh Jesus, I just saw your other comment:
> I still can't figure out how programming computers (the most complex task a human can undertake) managed to become singled out as the only profession in the history of humanity that is simultaneously assumed by so many to be something you need only a cursory understanding of to be proficient at.
Is this a copy pasta? No, I'm on HN it's someone's genuine thoughts.
the most complex task a human can undertake
Yikes.
> they find programming computers simple because they're not really programming
Actually, the "learn javascript in 24 hours" crowd finds out the hard way that programming computers is orders of magnitude harder than they initially thought... but they still insist that it's because gatekeeping programmers are artificially making it harder than it has to be.
When I was a kid, I started with BASIC, but I thought of "real programming" as being compiled languages, particularly C and assembler. Then in college I had a course where we wrote microcode for an imaginary CPU. FPGAs weren't really a thing then, but I would have liked to take a course with those. Now after years of Perl and SQL, I've come full circle back to (Visual) Basic.
But I would say assembly language is generally easier than javascript. In most cases (maybe not x86) there's a limited number of operations you can perform, and straightforward conventions on how to do them. Everything is documented (yes I know you can quibble with that, but relatively speaking) and there aren't ten different ways to do something of which 9 are wrong. You aren't dealing with all the layers of abstraction that tend to leak through either.
Assembly may be easier, but programming in assembly is a lot more tedious. A simple expression like "y=7*x+5" is at least four instructions, assuming you have a MUL instruction. And string manipulation is just as bad, if not worse, than in C.
Two on Intel, assuming the values should go in registers:
imul rY, rX, 7
add rY, 5
I'm sorry but
> but they still insist that it's because gatekeeping programmers are artificially making it harder than it has to be.
What???????
I mean... what? You're saying that beginners find programming harder than they expected... and then say the reason it is harder is because programmers are artificially making it harder than it has to be?
Did you mistype this comment?
Wasn't your original point that they don't even bother with the stuff you're saying... gatekeeping programmers artificially make harder.
What even is this, you're slaving so hard to make "that crowd" seem like a bunch of misguided ingrates that you've ceased to even remain internally consistent to your own point.
My former business partner is in the boat you describe. He learns the bare minimum needed to do the task at hand and seems pleased with that. He still has the joy of discovery, but it's more about what he can do with the tech than any appreciation of the formalism. He's happily working as an indie game coder, and while he doesn't exactly have FU money, he's for the most part cleared the first milestone of making rent for the past few years.
I'm in the opposite boat. I've learned so much about the theory of computing that I almost can't program anymore because most of what we do today feels like a waste of time to me. It's all convention and application now, with so many barriers to entry that I feel like 95% of what I do on any given day is setup. The dreams I had for how computing might evolve and lead us to the endgame of AGI feel more distant to me now than ever before. It will likely happen through the biggest players, using whatever proprietary tech they come up with, and leave garage hackers in the dust. I don't have a good feeling about whatever artificial agents arise from that.
So there is a lot of survivor bias in programming today. I feel like Obi-Wan Kenobi, beat down by the industry, marooned on some distant planet. Meanwhile the youth subscribe to empire quickly, because all they see is glorious rewards. Seeing haggard old graybeards like me fall from such early potential makes them rightfully skeptical of the gatekeeping you describe, the adherence to the old religion of computer science.
Or I'm just full of it. I don't even know anymore. I wish I was part of something bigger again.
Its a strange field that doesn't have clear boundaries and constantly changes.
I keep getting back in my thoughts to an old carpenter who was making a truly wonderful kitchen in a strange corner of an old building. Non of the walls, ceiling or floor around it were straight and it had tons of weird niches. I ask him how he could attack such a problem with such confidence. I would have to spend days pulling my hairs just making a drawing. He said, carpentry is roughly 300 methods of which you only need 120 to 140 to do any job. The rest is just tricks that you don't really need but they are impressive to those who know the problem.
I keep thinking of that in programing context for some reason. Nowadays you just order a plug and play kitchen that fits exactly, a novice can ikea it into place, everything works and it looks fantastic. Programming will get there one day. Until it does it will just look really weird to the old carpenter. So you grind the wood down to Particle board, you glue plastic on it that looks like wood then it gets moist and you replace the entire kitchen? .....!
Yup. I feels you.
A few years into my dev career, I adapted to make maintainable stuff. Because I learned that in 6 months I'd have to fix my own bugs.
Now it seems most code is throwaway, one-off, write only.
I haven't been able to "let it go". I still obsess over making my code correct. No one else seems to care. They get rewarded for fixing their own bugs ("velocity!") which I mostly avoid. So my KPIs look terrible by comparison.
Things get better. Or, they did for me when I retired earlier this year :-)