Hacker News new | ask | show | jobs
by albumedia 5028 days ago
Congrats on learning to code but the biggest mistakes new hackers are making is diving right into learning a specific lang.

Learning programming fundamentals is a better way to go. That way, you can jump from lang to lang.

Starting is hard so congrats again.

10 comments

I disagree. You didn't learn to talk by studying rhetoric. You imitated sounds and words that people made around you. Then you started being able to express your own ideas. Then, maybe, you learned how to say things well.

It's the same with computers. While some people may enjoy learning deductively about abstractions like algorithms and paradigms, studies have shown that most people learn inductively, by having something they want to do and figuring out what to do.

Human speech is a bad analogy. A better analogy would be grammar and spelling, which would make OP's argument stronger. The very argument you disagree with.

Truth is, you first learn the basics of speech communication. You understand sounds come from your mouth and given a specific cadence and tone you can form words to get what you want. This is no different than understanding the basic principals of computer programming. Principals all computer languages use. Specifics of the language (syntax, grammar, spelling) is something that can be mastered later, but without the principals, you're not going to master anything. This is a major reason why there are so many bad PHP examples out there. People don't learn to program, they learn to write PHP code poorly.

I find both of these analogies inadequate.

Spend more time around young children. They most definitely do not learn grammar before they can communicate. It is not a linear thing at all. People pick up parts of grammar like the Subject Verb Object syntax as they learn to mimmic diction and build vocabulary. They're constantly "wrong" and need to be corrected. With persistence and practice and, most importantly, interest, we acquire taste and style.

Communication is very much a trial and error kind of learning that is holistic rather than linear. "Learn x, then do y" versus "do y, then learn x" is a false dichotomy.

I disagree (at least that this is universal). If you start with just fundamentals but no specific language, you can't whip up anything to play with. The amount I was able to learn easily without doing anything was quite low, so I'd say start with a language with a responsive interactive shell so that you can quickly see what things do for yourself, and (crucially) see what happens when you make small changes to whatever examples you might be looking at.

But there's a bit of this I agree with: don't get focused on just one language. Once you can get basic stuff done in one language, it's worth learning how to do stuff in a different language. For me, the second language was almost as hard as the first, but after that it got a lot easier.

(Which is not to say that I don't think fundamentals are important: I'd suggest eventually hitting the core algorithms, data structures, computer architecture stuff—even if it doesn't seem immediately relevant—as well as playing around with more out-there stuff (Prolog was always a favorite of mine). But I don't think all that's going to be interesting at first to someone who's just getting started out of a practical, "I want to build something", not a "I want to learn all of this!", motivation.)

Agree.

Learning the fundamentals doesn't mean not doing actual programming at the same time. You have to code to have a better understanding on the fundamentals.

My personal experience is that after many years of programming, the fundamentals I learned in school still help me get better. There were many such moments that you were digging into some interesting technical topic and you suddenly realized that some fundamentals had another layer of meaning or application you didn't know or I didn't fully understand before.

Also, understanding different types of programming languages, like OOP, FP, logic programming, declarative programming, etc. help improving one's programming skills, no matter what programming you primarily use at work.

Agreed. I am largely self taught as well, and have found a lot of value in reading texts on CS / programming fundamentals :

  * Computer Architecture
  * Operating Systems
  * Algorithms
  * Data Structures
  * Database Fundamentals
  * etc.
In addition, more seminal-yet-not-directly-practical books such as SICP are quite valuable. I've been meaning to read TECS (a copy of which is staring at me as we speak), however I have not had the time to devote to its projects yet.

Edited to add :

In addition, reading up on web application architecture was quite helpful. This is increasingly important as modern frameworks may otherwise abstract away concepts to the point of making them very black-boxy.

That said, my goal was not to rush towards an MVP or prototype. I intend to be a competent developer first, and a founder second. If these were reversed, I might well have adopted the OP's approach instead.

Are these things that were helpful or got you started?

I don't think anyone is challenging the value of studying those topics. It just seems to be general consensus you don't start with them.

I suppose it depends on how started is defined, but yes - having an understanding of the topics I mentioned preceded working as a junior developer.
What was the order of learning for loop, function and class? Did those proceed architecture, algorithms, data structures, etc...?

Personally, the challenge of learning the more base knowledge and gaining a deeper understanding of computer science is that until you are really good at making things, you honestly cannot tell the difference.

We can certainly agree to disagree, but I don't think that being "really good at making things" is a pre-requisite to understanding some of the principles underlying said "things". In many ways they are related-yet-distinct disciplines (Computer Science vs. Software Engineering).

I readily admit that I may suffer from some bias in this regard, since I find more abstract topics to be a lot of fun. There are many roads to Rome, however this is one that I personally found to be useful.

I have some friends/colleagues like that, and they are a certainly a minority. All very deep thinkers and great to work with. I could see how learning all of the abstract material would help with that learning type, so I don't think we disagree. Everyone should use whatever approach works best for themselves. This is probably a better point than anything else.

I was focused on my own experience and the experience I've had with the majority. Generalization and such.

I agree to an extent, but this shouldn't be construed to mean what I think is a bigger mistake that new programmers[1] make: bounce around from language to language when you're still trying to learn how to program. I made the same mistake when I was learning. The language is (largely) irrelevant, so by trying to learn Ruby when you've barely learned C (vice-versa, whatever), all you're doing is overloading yourself with syntax, when you should be focusing on nailing down the syntax of some language, (essentially) any language, so that you can begin to focus on learning how to program and not what the asterisk means in that context.

[1] Tagent: am I the only one who hates "code" as a verb and "coder" as a noun? It makes it sound so rote, and reminds me of "code monkey." I'll take programmer/developer/hacker/engineer.

I agree and disagree...

Learning the fundamentals is important, but one must put the theories in to practice by learning a language, writing some code, making mistakes, correcting them, and learning how the fundamentals work in practice.

thats why cs courses has projects, to test the theories in to practice, the good thing about fundamentals is that it teaches you that the language its not an end for it self instead its just a tool to express yourself
True. I think there may be two camps though. It depends on if you want to learn and be able to master the fundamental theories that ground everything or have a more pragmatic approach where you accomplish things using tools you doesn't fully understand.

My example would be: when was the last time you implemented your own merge sort?

True that my knowledge of algorithms benefits me, but maybe all I need to know is that it sorts an unsorted array.

In the end, the best approach most likely depends on the person. Some people need to understand things fully, at the lowest level before they can build on them. Others need to see something in use and be able to play with it to wrap their minds around it. I know I'm personally a combination of the two.

Regardless of the type of person you are though, I think everyone is advocating that you do something to get the ball rolling.

Speaking only for myself, I "learned to code" six years before I got to college to study CS. CS taught me a bunch about what I was doing right and what I was doing wrong. My first paid programming job, as a senior/first-year master student taught me what all that meant when applied to what a business operation needs from its coders.

Learning to code, means being able to write a o(n^2) sort, not necessarily being able to tell why that algorithm is bad, or what O(n^2) means.

We all have different ways of learning. When it comes to programming, learning the fundamentals first can save a lot of time and frustration. Not everyone can pick a language and start learning right away.

I think a better way to start is by learning the fundamentals like: - variable declarations - if statements - loops - functions

Those fundamentals are the same whether you're doing backend coding or frontend javascript.

Remember, it's all syntax.

That might or might not be ideal theoretically - but it requires an enormous amount of self discipline and persistence if your're on your own.

But I think all self-taught programmers (of which I am one) should set aside some time for the fundamentals once productive in one language.

I would talk a more organic approach. Jump right in and when you come upon some bigger subject matter (sorting algorithms for instance), take a break and go study the subject a bit..
I don't know why you were downvoted but there is definitely something to be said for what you argue.