71–80 of 203 posts
Earlier quoted context omitted.
My impression is that most people can't be good at it because they have no interest in it, and no willingness to spend time on it, learning and practising.
I see it even more simply. Most people can't handle something being so stupid and frustrating. And the bigger their delusions on how smart computers are the less possible it is.
One of the main differences I see on the road to learning to code has nothing to do with the tools; it’s the thought process. A major hurdle is trying to get the business people to coherently express what they want. They seem to have a general sense of how something should go, but can’t actually put it down on paper. Or when they do, it looks different than what they imagined (simply because the required logic doesn’…
One of the best programmers I know is a philosophy major, who thinks of code like poetry, with consistent readable concision as the goal.
There are many paths.
What programming does require is a vivid imagination, to form a mental picture of the machine you are building and what is happening as information flows through it and is transformed.
Even more than that, it helps to be a systems-thinker, and to be able to zoom out and ask “what are we really trying to accomplish here.” Most of the time the elegant software solutions come not from writing brilliant code, but from reframing the problem so that simple code can solve it.
One of the main differences I see on the road to learning to code has nothing to do with the tools; it’s the thought process. A major hurdle is trying to get the business people to coherently express what they want. They seem to have a general sense of how something should go, but can’t actually put it down on paper. Or when they do, it looks different than what they imagined (simply because the required logic doesn’…
depending on the amount of computation needed/task executed the number of record to update can make things very different. updating 1 million or 10 000 records that need very heavy computation and communication to other systems under some duration or latency constraints is very different from updating 10 of them.
you may need to optimize and/or rewrite your whole systems to handle such things.
I can't think of many other social trends that would be more beneficial for increasing general support for user agency, data interoperability, sideloading/modding, etc... we should applaud every single attempt to democratize coding and lower barriers of entry.
It's not about whether or not someone can replace your job or whether or not they take something that's a hobby project or an occasional side-task at their job and turn it into a professional career. It's not about whether or not the things they make are any good. It's about giving them a little bit more agency in how they interact with devices/software, and about reinforcing to them that as a user they should have agency over their devices/software.
We don't need everyone in the world to be an engineer, and we don't need everyone to write good code. The goal is not to make everyone into a programmer, or to elevate engineering as some kind of universal subject that everyone has to embrace. But it is good for average people who aren't engineers to be embracing a philosophy about computers that says, "I should be able to arbitrarily describe to this thing what to do, even if its designers didn't think about my use case, and it should do the thing I tell it to".
Well, this makes me feel old. It's no revolution, but a reversion. It was the norm, not that long ago, that anyone could do minor programming. The era of Lotus Notes and the like. You would still hire a programmer for the big stuff, but office workers would build little scripts, or look under the covers when something goes wrong.
Programming is too important to be left to programmers . -- apologies to Clemenceau I think it's possible to make productive use of programming without claiming to be developing software by which I mean, programs that are expected to be placed into long term or widespread use. That's what we did with programming in BASIC, 40 years ago. As a scientist, I use programming for things like modeling, data analysis, lab aut…
What an ego shattering revelation it would be if it turned out just about everyone can be good at coding. Being able to code is what qualifies us to know everything about everything!
My impression is that most people can't be good at it because they have no interest in it, and no willingness to spend time on it, learning and practising.
One of the main differences I see on the road to learning to code has nothing to do with the tools; it’s the thought process. A major hurdle is trying to get the business people to coherently express what they want. They seem to have a general sense of how something should go, but can’t actually put it down on paper. Or when they do, it looks different than what they imagined (simply because the required logic doesn’…
I don’t think that having a knack for math necessarily matters for making a good programmer. I’ve known many good engineers who were drawn to programming because math was hard for them and they wanted to learn how to get the computer to do it for them. Ironically, coming to understand programming can be a way to understand math better. One of the best programmers I know is a philosophy major, who thinks of code like…
the part that would be useful in programming is a little bit of logical reasoning, the symbolic reasoning and modeling of problems through abstraction.
coincidentally these are also the part of math that get thought and used in philosophy so I'm guessing that your colleague is somewhat familiar with them since their most probably are required core courses in getting a philosophy degree.
Earlier quoted context omitted.
I've done embedded systems for 35 years. I've done quite a bit. Never needed recursion. (Not much use for it in the embedded world...) Now pointers... yeah. I use those a fair amount.
:-) If you've written a while loop you've used recursion. Not saying you need to understand the inner beauty of a fixed point combinator . . . it's just there, to be noticed, if you choose. You might (meaning if it caught your eye) study some recursion and notice some properties that give you some insight into how your algorithm performs or how induction over your datatypes works. Often when writing some Scheme or Ju…
But "while (true)" is also equivalent to a goto :-)
While both of those are true, I'm not sure that understanding either of them is relevant to dmitrigr's claim that you have to understand both recursion and pointers in order to amount to anything as a programmer.
One of the main differences I see on the road to learning to code has nothing to do with the tools; it’s the thought process. A major hurdle is trying to get the business people to coherently express what they want. They seem to have a general sense of how something should go, but can’t actually put it down on paper. Or when they do, it looks different than what they imagined (simply because the required logic doesn’…
I agree with all what you said, except the part about 10 records vs 10 000, that I think need better clarification. depending on the amount of computation needed/task executed the number of record to update can make things very different. updating 1 million or 10 000 records that need very heavy computation and communication to other systems under some duration or latency constraints is very different from updating 1…
The vast majority of business records are not being sent through machine learning algorithms or being used to factor prime numbers, they’re simply lists of basic things like names, addresses, phone numbers, etc. In all of those cases, the difference between 10s or 1000s is trivial. These are the types of things people use Excel for daily.
In cases where the data processing is actually significant, then sure, bring in your data scientist.
Earlier quoted context omitted.
If learning your first programming language doesn't require patience, I don't know what the word means. I've never met anyone who wasn't frustrated for at least the first few months trying to get even basic programs working. The syntax is orders of magnitude less tolerance of mistakes than any other subject.
Not sure a doctor would agree with that last sentence. Or even a carpenter really. Cut that bit off at the wrong angle and it's not something you're coming back from. Cut a line of code wrong and the test fails, and you try again, and again and again.
What I do think coders need to know is that they are building on quick sand. That bit is the only thing I think we do that other trades don't. We can never rest, because as soon as we stop for a breath we start to sink and fall behind.