Rule 11213: First person to mention "time" when linked article does not include the term "time" takes 1 step backward, 1 step forward, 2 steps backward, 1 step forward, 3 steps back. Back to the future.
Coding doesn't necessarily involve time deadlines, and maybe cooking doesn't either, although it seems to. I agree with the rest of what you said though.
I know, which is why I said '(for the most part)'. 80%+ there's some kind of tangible time limit on what you're trying to achieve. Be it self-imposed or otherwise.
I don't understand the distinction you raise in the first paragraph. Coding is programming. Just because everyone can divide doesn't mean everyone is trying to be a mathematician, but I think everyone should (at least have the opportunity to) learn long division. Programming may not be the fourth "R", but maybe "Research" is!
I think the important distinction would be how much additional knowledge you need to solve the problems you solve. I'm gonna call the "coding" "scripting" for now, and the "programming" "programming", because these are older and in my opinion better terms.
Scripting basically takes the problem and a language and directly transforms the problem into a working program. You don't need fancy algorithms, you don't need fancy background knowledge in programming topics, you need python, a python dictionary and directory access (for example). Or Excel and VB and a few arrays and a formula.
On the other hand, heavier programming would require more and more thought when actually implementing a solution to a problem. Efficiency might become a large concern earlier, you might need more complicated algorithms sooner and so on. Think about every occasion where you transformed a problem into a graph problem and applied some graph search, or graph coloring to this problem.
If I understand "coding" as "scripting" and "programming beyond coding" as "programming", the distinction makes sense, and it makes sense to call for more people with the ability to script simple things, because scripting is not too hard and saves a lot of time.
Being a programmer is really really really fun the first few years. Kinda like playing video game. However, it eventually become something that is can be unhealthy. It really undermine other sensory input from the body. And primarily focus on the mind and finger interaction.
However, given the current state of the world, where many things are in one way or another controlled by software. It would be a good idea to have a skill related to coding, just to know if something is possible with code. And understand that it is not just magic under the hood.
As opposed to a professional "coder"? (I also see "programmer" as a more distinguished title and I prefer it to "coder" (and even "software engineer"), but I don't understand any of these terms to have any generally-accepted definition; personally it is only a matter of taste.)
I'm not trying to be facetious, just misunderstanding whatever point original commenter is making. "Most people don't what programming even looks like"? I don't think that is true because most people can search for code samples if needed.
"If the mayor of NYC wants to learn to program in his spare time, why the hell not?"
I agree totally, not only would it be good for him but it sets a good example for his constituency (because as a basic competence it is good for anyone).
You seem to be a bit disconnected from reality. If I told any one of my friends who are not programmers by trade to look for code samples, they would either not understand what I'm talking about, or simply not know where to look.
Most people don't even have the slightest idea what kind of problems software can solve. Jeff Atwood seems to interpret "learn to code" as "learn to set the DYLD_LIBRARY_PATH variable". Others—myself included—think that having at least a bit of exposure to programming provides you with a better overall understanding of how computers operate.
I don't think it's necessary to have that understanding. But neither is speaking a second natural language. Apart from acquiring the skills themselves, learning any of those will teach you meaningful things about yourself and your environment, which seems to be worthwhile.
Most people don't even have the slightest idea what kind of problems software can solve.
I was once told by a good friend of mine in industry X[1] that people in that industry have money but they don't know whats possible - they don't know what could be automated or calculated with computers and so they don't do it, even though it would provide a lot of value to them.
[1] In general, I think the industry is irrelevant and this applies to most industries that don't already directly employ programmers. There are often already some high tech firms that do and they have a huge advantage over the masses that don't. In this particular case, the industry was the betting (horses) industry and there are actually plenty of firms that are high tech and hire programmers and mathematicians and such to create complex software, but I think his point is that there are still a lot of smaller firms and people who spend a lot of money that still don't know what is actually possible. He since moved to a much more high tech company, but he still does most (if not all) of his complex risk assessment modeling in excel.
You are very wrong about this - people who know how to "search for code samples" know what programming looks like, but they are far from the majority.
I, for one, wish more people understood what programming "looks like", so that I could actually talk to people about what I do without them being completely confused. People can visualize what nearly every other profession does day-to-day, but what programmers do is a complete mystery to most people. I tell people that I'm a writer for a language with a very structured grammar, but that's only part of the story.
> People can visualize what nearly every other profession does day-to-day
No they don't. They know an architect draws pictures of buildings. An engineer draws pictures of a bridge and hammers away at a calculator (actually the first thing most people think of with engineer is probably either boats or trains or Star Trek). A banker sits and acts like a total dick. What architects, engineers and bankers really do is a complete mystery to people.
When someone asks what you do and they do not have any domain specific knowledge, you say you write applications, you're a programmer. That's all they want to know, they don't care what the details of what you write are. They don't want to know the differences between languages. They don't want to know what a structured grammar is and why you care about it. Those are details of your job, that's not what they were asking.
"I'm a system administrator. I keep computers working." That is the maximum extent people want to know about what I do. They're being polite in asking, they don't really want to know details. And at the end of the day they still think that all I do is sit on my ass and look at a computer screen. Just like the way they visualize a programmer, and a banker and a ...
I don't buy it. An architect designs structures - most people don't know what the actual work of designing a structure looks like, but they know what a design of a structure looks like. An engineer figures out how to make a structure stand - most people don't know what the process of making a structure stand is, but they know what a standing structure looks like. A banker moves money around, people don't know how that is accomplished, but they know what a loan looks like. Most people I've met don't have any idea what a computer program looks like, not even that it involves text. I didn't say anything about the differences between languages, and I think you misunderstood my comment about "structured grammar". I didn't mean it as a specific feature of what I do, but as a generic feature of what a computer program is. I only meant that the closest analogy I've found to programming that most people can relate to is writing.
"I keep computers working" and "I write computer programs" are on opposite sides of a conceptual understanding chasm - most people have tried keeping computers working, even if they hated it and failed miserably, but most people haven't tried programming, and don't really know what the concept means.
I don't think you truly believe that though. Most people who hack daily have at least a basic working model of the computer. There's a compiler parsing, generating code, there's possibly a VM executing bytecode, an operating system managing memory, scheduling, network and other services, below that there's a CPU executing some representation of assembly code, it's in turn composed of some sort of a logic array, etc. etc. I'm not saying you know the inner workings of everything.
It's more along the lines of, we teach physics with the aim that people finishing high school should have a vague notion about at least newtonian physics, some electromagnetism and the scientific model. For computers, we teach how to open Word, check your e-mail etc. Stuff kids know. What they don't know is how this all ticks, and I think there is certainly value in helping kids construct a vague mental model of it all, and how to apply certain parts of it to a screen they'll probably interact with 4-16 hours per day for the rest of their lives.
"Can you explain to me how Michael Bloomberg would be better at his day to day job of leading the largest city in the USA if he woke up one morning as a crack Java coder?"
If anything should trickle down, it would be the joy and satisfaction of acquiring a basic competence.
This is nonsense. It's absurd for you to argue that the difficulty of writing "Hello world" on an Apple device is somehow a good thing for Apple or anyone else on the basis of a wishy-washy concept like "abstraction".
The Go compiler is largely implemented in C. However, unlike most modern languages, Go has explicitly been designed to be easy to compile into fast code.
It is possible to find the median in linear time (quickselect). Pivoting on the median makes quicksort optimal (O(n log(n))) while only using constant space. This is rarely used in practice because the overhead is large compared to the probability of being given a worst-case problem.
