Live data from Hacker News

Learning to Code vs Learning Computer Science

shkspr.mobi

81–90 of 116 posts

Re: Learning to Code vs Learning Computer Science

#81
You typically find this idea of teaching abstract advanced concepts first in anyone who believes in a constructivist theory of education, which this article smacks of quite a bit. The problem with constructivism is that it really only works with beginners who stumble onto a natural talent that gave them these foundational skills, or whose parents were wealthy and educated enough to have them and teach them to their kids. Constructivism's lie is that it claims to want to teach everyone, but then is only successful with natural talent.

If instead you teach basic skills in the best way, through fairly rote learning combined with application, then later abstract concepts are possible and can be discussed. The idea that you have to do one (abstract concepts) without the other (basic skills) is simply an attempt to limit the types of people who can succeed at an activity to only those people exactly like the teacher.

In other words, attempts to teach abstract concepts first as if basic skills are pointless are simply attempts to weed out undesirable people, which is what this article's proposal would do.

Re: Learning to Code vs Learning Computer Science

#82
post #7

Computer science is to programming as physics is to civil engineering.

No, that's not even remotely an accurate analogy. Computer science is a branch of applied mathematics; not a physical science. Engineers need to have a basic understanding of core physics principles in order to do good work. That analogy doesn't hold with respect to programming and CS. A better analogy is that CS is to programming as number theory is to arithmetic: a person doesn't have to know what a "field" is in o…

Mathematics is a branch of applied Computer Science

Re: Learning to Code vs Learning Computer Science

#83
post #67
post #59

Earlier quoted context omitted.

> While it may be perfectly acceptable to ignore the lower-level details when first learning some new technology, or even when using it for personal use only, that sort of ignorance is not acceptable when working on systems that are meant to be used seriously. I'm a self-taught web developer. While I have probably picked up some programming fundamentals/best practices through experience I have very little interest in…

I think you've benefited very heavily (a lot more than you may realize) from the work of people who did have more formal training, and who used that knowledge to build the systems that you in turn have built upon. You're right, it does take much less effort and skill to run moderately high-traffic WordPress-based web site these days. That wasn't always true, though. In the 1990s and even into the early 2000s, it did…

> I think you've benefited very heavily (a lot more than you may realize) from the work of people who did have more formal training, and who used that knowledge to build the systems that you in turn have built upon.

And your point is? Am I supposed to create a shrine to the people who built the first microprocessor?

> You're right, it does take much less effort and skill to run moderately high-traffic WordPress-based web site these days. That wasn't always true, though. In the 1990s and even into the early 2000s, it did take skill to get the most out of web servers with clockrates below 200 MHz, maybe 16 MB of RAM if lucky, very limited storage, and limited network connectivity. Specialists were needed in cases like that.

I'm sorry but it's not 1999. I can't imagine anyone winning a potential client over today by saying "You couldn't do in 1999 what you're doing without someone like me" or "I will architect your website so that it can run smoothly on a server with 32MB of RAM."

> What you seem to consider "ignorance" is usually just considered "forethought" and "planning ahead" by those involved.

So struggling to hire (because you're looking for overqualified candidates a lot of whom don't want to work on a simple website with less than 100,000 visits per month) and increasing your burn rate by paying $140,000/year fully loaded for web developers you can call "engineers" is "forethought" and "planning ahead"?

I know enough people who have worked at typical VC backed startups to know that most of them never grow big enough to have the kind of scalability and performance challenges they'd all like to believe they're going to have. And as a practical matter, if you look at the great companies that have emerged in the past decade (think Facebook, Twitter, etc.) and how their systems have evolved as they scaled, it's pretty clear that if you become a massive success, you're going to need to substantially rewrite your code base anyway and by that time you won't have to hunt for the highly technical engineers you need. They will be knocking on your door.

The biggest risk to just about every new startup is not having a developer who is a little too friendly with an ORM and who might have to turn to StackOverflow for help with a complex SQL query. It's getting a good enough product launched before you miss your market window and/or run out of cash.

Re: Learning to Code vs Learning Computer Science

#84
post #81

You typically find this idea of teaching abstract advanced concepts first in anyone who believes in a constructivist theory of education, which this article smacks of quite a bit. The problem with constructivism is that it really only works with beginners who stumble onto a natural talent that gave them these foundational skills, or whose parents were wealthy and educated enough to have them and teach them to their k…

I agree with you. People learn best when they can see the relationships between what they're learning and the real world. Abstract theory should be learned only after there's something for the learner to latch onto and apply it to.

Think of all the best teachers you've had in life. Did they teach by throwing you head first into the water to see if you could swim, or did they start by telling a story and then slowly peeling back the layers to reveal more complexity? Start with simple applications and concepts and then expand on them.

Re: Learning to Code vs Learning Computer Science

#85
It's important to capture the imagination of young people and encourage creativity. Projects like Scratch are a fantastic introduction to solving problems with computers, and young children actually enjoy using it. Kids are excited about building things and getting results. Think LEGO/KNEX, would these toys be as popular if you needed to study the composition of the plastic and physics of forces? Think how many minds have been inspired with simple toys like these.

Computer science and the intricacies of sorting algorithms are a really fucking boring thing to learn/teach. Why make coding in schools monotonous and irrelevant when it could be fun and inspiring? I agree that the fundamentals are important to study at some point but that can wait until a higher level of understanding is achieved.

I have worked with a lot of developers from different educational backgrounds I can tell you that knowing computer science and being able to code are two totally different things. Businesses are interested about getting shit done and seeing results, not how you did it. I don't think that a computer science degree properly prepares you for real life software engineering.

Make coding fun, inspiring and motivational! Teach kids what they want to know and help them to enjoy learning.

Re: Learning to Code vs Learning Computer Science

#86

When you're building a skyscraper, you are not going to design every brick. The basis of teaching children how to code is making them learn how to use code as a problem-solving tool. Like this, the sorting will not be important by itself, but as means to an end. As a way to achieve greater objectives. And besides this reasoning, we have another: in CS, something is generally built on top of others. If you write a hea…

"When I write my HTTP Applications I don't need to understand all the Network Layers beneath it." If you want your HTTP application to perform well, be secure, be scalable, work with a multitude of browsers in unusual conditions, and be able to troubleshoot weird errors, then yes, you will at some point need to know something about TLS and TCP and IP (v4 and v6) and even Ethernet and Wifi. Similarly, architects and e…

> Similarly, architects and engineers have to understand how the materials they're planning to use are made, what their capabilities and limits are, and how they can best be used to implement their vision for a building or a bridge. They can ignore how the bricks are made and how they perform, but their structure will not last.

Np, they don't. At least not to the degree that some people here think programmers and software engineers should know computer science topics and various levels of abstraction. As an electrical engineer, if I had a custom transformer I needed the spec sheet and evidence that the parts met said spec sheet. The spec sheet had basic electrical and physical parameters along with relevant composition information. I didn't care what exactly the core was made of unless it was specified; I certainly didn't care how the core was cast and milled, how the coils were wound, how the casing was added[1], or what the casing was made of[2]. I didn't care about the details of how out custom or off-the-shelf ASICs were made, only that they met the stated specs. I needed to know how they functioned in the circuit, how they interacted with each other, how the spec tolerance on different parts affected the overall operation. If I had a problem that looked like a lower-level issue, say an ASIC that may have switched manufacturing processes without the manufacturer telling us, I worked the issue at our system level and let an ASIC specialist handle the nitty-gritty details as necessary; the ASIC specialist similarly relied on me to handle the board-level issues.

I was going to give a civil engineering example with concrete, but I'll cut right to the chase. Computer science, misnomer that it is, is a very broad subject area. As it matures, it continues to get broader. At some point, we as an industry, and to some degree the academic community, need to realize that the subject area is too broad for everyone to know everything and that people need to specialize. If I want to build a radar system I need as a minimum: an RF engineer who understands the gory details of RF transmission and RF semiconductors; a power engineer who understands the gory details of DC power conversion and distribution; an electronics engineer who understands the gory details of mixed-signal board design; another electronics engineer who understands the gory details of high-speed digital board design; a firmware engineer who understands the gory details of FPGA and CPLD design; and an ASIC engineer who understands the gory details of analog and mixed-signal chip design.

Everyone I just mentioned will have one or more degrees that say "electrical engineering", and many may only have a bachelors. Each engineer certainly understands the basics of what the others are doing, but each is still a specialized engineer. They are NOT interchangeable. You cannot hire people for their generic "electrical engineering chops" the way Google and its cargo culters hire software engineers, even straight out degree programs. Every electrical engineer cannot know everything equally well, and once you start working and specializing through experience it just gets worse. The sooner this industry realizes that software engineering is not different and that complex software projects need specialist teams coordinated with proper systems engineering[3], the better. I firmly believe that most of the "talent shortage" right now is an artifact of companies looking for people like you describe, people who know everything and can move freely up and down the stack. That is increasingly impractical and not nearly as efficient as getting people to specialize and work together effectively in multidisciplinary teams.

[1] These were fully-encased transformers.

[2] Again, unless we specified something specific.

[3] http://www.incose.org/

Re: Learning to Code vs Learning Computer Science

#87
post #25

Earlier quoted context omitted.

While it may be perfectly acceptable to ignore the lower-level details when first learning some new technology, or even when using it for personal use only, that sort of ignorance is not acceptable when working on systems that are meant to be used seriously. At that point, you need to have at least a high-level understanding of each and every layer that you're building upon. If you don't, then it will come back to ha…

It's perfectly acceptable to not understand the low level details of seriously used systems. Isn't that what teams are for? You can trust the engineers developing infrastructure so that you don't have to worry about it. Sure, understanding the high level concepts can't hurt, but it isn't going to make a front-end developer any more productive.

The engineers can't really do that for all cases [1]. Understanding abstractly what's going on at least a few layers up and down your stack will definitely make a front-end developer more productive, if by productive you mean able to complete a finished product rather than just a buggy first draft.

[1] http://www.joelonsoftware.com/articles/LeakyAbstractions.htm...

Re: Learning to Code vs Learning Computer Science

#88
post #76

I'm not sure most of gets called computer science is actually science it terms of "a systematic enterprise that builds and organizes knowledge in the form of testable explanations and predictions about the universe" as wikipedia puts it. Mostly it would be better called software engineering. I think people tend to call it science because that sounds sexier. The stuff the writer of the article says he supports in the…

You have a good point. OP was trying to show how to pursue computer science by understanding the meaning behind programming. But he deviated it to the software engineering which is a different scope to chase for.

If you like to pursue computer science, you spend your time on improving algorithms, improving compilers, improving language and improving operating systems. When you like to pursue a different direction to write software applications, you focus more on the latter part OP mentioned.

There is no absolute line between the two. Understanding better in the low level will always help, especially for the new programmers. That's why we had the principle courses in colleges.

Re: Learning to Code vs Learning Computer Science

#89
I don't see it this way—that learning to code is in some way less elegant and less conceptual than learning computer science. That "it's not science" anymore. Rather, your idea of "learning to code" is just operating at a higher level of abstraction from your idea of "learning computer science."

When you start with primitives like array.sort(), you're implicitly bringing the organization of a program or system as a whole to the forefront, while abstracting way the mechanics of that sorting process. This is a good place to start understanding individual computer programs and systems.

When you start with primitives at the logical and mathematical level (i.e. theory), you're bringing the organization of lower-level concepts like data and control structures to the forefront. This is a good place to start when understanding the components that go into higher-level primitives like "sorting."

And you can go up and down in terms of the level of abstraction you want to view computer systems. Go higher, and you'll think more about the way multiple computer systems integrate (this is precisely what frameworks, APIs, and SDKs tackle). Go lower, and you'll think more about the way hardware interacts with machines (which, ironically, brings us back to electrical "engineering"—not science!).

To me, it's all just layers of abstraction, and the layer you choose should just be the one you find natural, interesting, and maybe useful. It's not a strict hierarchy; there are branches and perhaps cycles. But our understanding of the systems that run industry today, are only possible upon a complex system of abstractions that goes all the way down to the physics of the universe.

There are patterns and antipatterns to understand when "learning to code" (at the systems level), just like there are patterns and antipatterns to understand when "learning computer science" (at the theoretical level), but they just operate at different levels.

The term "computer science" implies that it is science, and not engineering. I think that the main reason theory is seen more as an "academic" pursuit as opposed to more abstracted understanding of computer systems is precisely because it has been so thoroughly abstracted, that trying to operate on a purely theoretical basis is just too inefficient to be particularly "useful" in an engineering setting, by some metric. It's not because of innate beauty or complexity; it's just where that arbitrary line is drawn.

Re: Learning to Code vs Learning Computer Science

#90
post #81

You typically find this idea of teaching abstract advanced concepts first in anyone who believes in a constructivist theory of education, which this article smacks of quite a bit. The problem with constructivism is that it really only works with beginners who stumble onto a natural talent that gave them these foundational skills, or whose parents were wealthy and educated enough to have them and teach them to their k…

Indeed my first programming was done in CECIL which is a simple teaching Assembler training language - just add sb and varios jump's

We had to send in our code on paper to be run on a time sharing system at a local college - BTW this was the CSE middle stream.

Post reply on HN