Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Early vs. Beginning Coders

zedshaw.com

Post reply on HN
Print view View original

51–60 of 178 posts

Re: Early vs. Beginning Coders

#51

Post by jerf »

MrDosu wrote: post #30
jerf wrote: post #10

Earlier quoted context omitted.

No, there's definitely an underlying substrate of significant commonality between the various programming languages and technologies. If you're at 10 years in and you still feel like a beginner, you're doing something wrong. Obviously I can't expect to pick up a brand new technology and instantly expect to be a wizard, but I do expect that I can pick up a new technology and be functioning at a high level in a week or…

If you pick up a new tech and it's " just a respelling/reskinning of some technology I've used before" you are doing something very silly or are not using new tech at all. If it's basically the same there is no reason to switch.

Don't tell me... tell the people who keep pushing old ideas in new guises on me!

"Oh, look, the JS community has discovered $TECHNIQUE. Ah, yes, I remember playing with this in 2003. Does any of them remember the ways in which it went bad and never took off, or are they just spouting hype? Ah, I see they've opted for hype. Well, this ends predictably."

Not that $TECHNIQUE is necessarily bad, mind you, it's just that none of these ideas are new and it would be nice to see one of these frameworks pop out every so often written by someone who up-front acknowledges the previous weaknesses of $TECHNIQUE and tries to address them, even if only through user education, somehow.

(And while no language community is immune to this, the last two years of JS has been noticeably worse about this than any other community I know.)

Re: Early vs. Beginning Coders

#52

Post by marktangotango »

orbitur wrote: post #38
lmm wrote: post #31

Earlier quoted context omitted.

That's only "basics" if you've got the wrong idea. There are millions of possible mistakes, no beginners' guide can explicitly address every one. People told you to just use the string - wasn't that a good enough answer?

> People told you to just use the string - wasn't that a good enough answer? "Don't do that" isn't a sufficient answer without explaining exactly why, though. And if you aren't asking the right question, then the explanation might even seem obtuse.

I can relate, in this case the op was actually hindered because he knew there are bytes behind the string. A key insight into why you shouldn't simply get the bytes is the .net char size is actually 2 byte, and the internal encoding is utf-16. Thus encoding/decoding is required, and if you haven't worked with encoding before, can be a bit confusing imo.

Re: Early vs. Beginning Coders

#53

Post by danso »

ZanyProgrammer wrote: post #44
danso wrote: post #36

Earlier quoted context omitted.

Uh...the reasons can vary quite wildly...so I'll stick to one scope: Why does production code suck even when it's been written by competent programmers? I would argue that in a non-trivial system, it becomes difficult to program components that reliably interact with each other. If one team changes the interface to their component, that is not as "deterministic" from your perspective, if the production workflow doesn…

As someone who was a beginning, community college CS 101 coder at one time, I think focusing on the mechanical, "this code won't compile unless every i is dotted and t is crossed" way of thinking is only half the story. Getting code to compile, after about the 2nd week of class, isn't too hard. Figuring out why your code doesn't give the right result, even when it compiles and runs, is by far a harder skill for new c…

Oh I agree, completely -- silent failures can confuse even experienced programmers. But it's very hard to get to the higher-level reasoning, i.e. does this code actually work...if you are continually tripping up on syntax. Moreover, a failure to understand the implications of the syntax can limit your ability to code.

For example, for beginners, it is not immediately evident that the two following code snippets are equivalent:

    a = "Hello world"
    b = a.lower()
    print(b)
and:

    print("Hello world".lower())
This isn't just a problem of recognizing the simple logic...but that when you're new to code, it takes more mental energy -- at first -- to pick apart the symbols and process them efficiently. And that mental energy is largely from the same reservoir that is used to process the higher-level concepts.

Re: Early vs. Beginning Coders

#54

Post by jordanpg »

loup-vaillant wrote: post #48
jordanpg wrote: post #39

The only important trait I see that matters for either of these groups is a willingness to try things, push buttons, see what happens. A beginner worries about breaking the computer and doesn't yet understand that any question they have can be typed into a search engine verbatim and will probably be answered with 20 SO posts and 50 blogs posts. And early programmer is stumbling down this road. I don't know that this…

> I would also recommend that beginners/early programmers learn 1 programming language really well That's a dangerous approach. The first language is very hard to learn, because, well, it's your first. And when you stick to one language, you easily conflate the syntax and the semantics. So when you learn a second language, you have to unlearn the syntax of the first, in addition to learn the genuinely different conce…

I just don't see it. No one would ever recommend learning Spanish and Mandarin at the same time, for any reason.

All of the things you said are true, and yet the beginner has only so much time, so much patience, so much learning to do in one day.

Given this, I see larger advantages to spending all of that time and energy in one ecosystem. There are many perspectives on, say, Java coding styles, patterns, and idioms. One need not go outside a language to do that.

And I would further argue that you simply cannot (usefully) see the global commonalities and idioms among languages until you've been doing this for a while. Years.

As for experienced programmers, I've not known any "experts" at 20 languages, ever. My point was really that this idea is simply the result of run-of-the-mill internet hyperbole.

Re: Early vs. Beginning Coders

#55

Post by someguy2948 »

jerf wrote: post #51
MrDosu wrote: post #30

Earlier quoted context omitted.

If you pick up a new tech and it's " just a respelling/reskinning of some technology I've used before" you are doing something very silly or are not using new tech at all. If it's basically the same there is no reason to switch.

Don't tell me... tell the people who keep pushing old ideas in new guises on me! "Oh, look, the JS community has discovered $TECHNIQUE. Ah, yes, I remember playing with this in 2003. Does any of them remember the ways in which it went bad and never took off, or are they just spouting hype? Ah, I see they've opted for hype. Well, this ends predictably." Not that $TECHNIQUE is necessarily bad, mind you, it's just that…

I've been hearing for years about how the javascript community is constantly rehashing things from the mainframe world or the desktop world. I haven't really been programming long enough to see it happen, though, (my first programming book was along the lines of "how to AJAX").

Could you be so kind as to mention some examples of javascript libraries or techniques that are recycling failed concepts from past decades?

Re: Early vs. Beginning Coders

#56

Post by jordanpg »

natural219 wrote: post #41
jordanpg wrote: post #39

The only important trait I see that matters for either of these groups is a willingness to try things, push buttons, see what happens. A beginner worries about breaking the computer and doesn't yet understand that any question they have can be typed into a search engine verbatim and will probably be answered with 20 SO posts and 50 blogs posts. And early programmer is stumbling down this road. I don't know that this…

I disagree with this entirely. You can "push buttons and see what happens" for decades without guidance on what buttons you're pushing and why. In addition, newcomers absolutely cannot just "type [their question] into a search engine verbatim" -- this is actually a highly advanced skill that you get after years of learning the correct patterns, abstractions, and jargon you need to get an effective answer for what you…

I wasn't suggesting that beginners not use books (or other "guidance"). Only that there are personality traits that are more useful to a beginner than detailed explication in any piece of writing.

Re: Early vs. Beginning Coders

#57

Post by kstenerud »

lmm wrote: post #31
SCHiM wrote: post #14

This is good. I've had problems that were somewhat related to what the author talks about. When I was learning C# and was already quite fluent in C/C++. I had a big problem with the C# type system/management. I'd been reading guides that were in the first category the author mentions, eg. "not really a beginner, but new to this language". I was trying to retrieve the bytes that a certain string represented. I was loo…

That's only "basics" if you've got the wrong idea. There are millions of possible mistakes, no beginners' guide can explicitly address every one. People told you to just use the string - wasn't that a good enough answer?

No, because they haven't explained WHY.

This ties into another of my pet-peeves: people who answer my "how do I do this" question with "don't do that". Quite often I have very good reason for wanting to do that (getting around another bug, esoteric requirements, etc). Whenever I answer a question, I'll first tell them exactly how to do what they're asking for, and THEN explain why doing that is usually a bad idea, and THEN show some alternatives that will probably do what they want.

Re: Early vs. Beginning Coders

#58

Post by morganvachon »

I feel like I'm perpetually stuck between what the author describes as "beginner" and "early". I understand what programming is, I can write a bash script that does what I want it to (granted, I have to read a ton of man pages to make sure I understand what it is I want to accomplish), I can write simple programs in Visual Basic or Python or Javascript that do simple tasks. I understand program flow, logic, and all the basics of high-school level algebra.

The problem is, I can't wrap my head around many of the concepts I read about here in the HN comments and elsewhere on programming blogs and such. No matter how much I try to understand it (and by understand it, I mean fully grasp what the person is talking about without having to look up every other word or phrase), I can't seem to put it all together. Things like inverted trees, functional programming (I've heard of Haskell and I'd love to learn it, but I have no head for mathematics at that level), polymorphism, and so on.

Maybe I need to just practice more; maybe I need to pick something interesting from Github and dive into the code to try to understand it better (preferably something well documented of course). Or maybe I need to just stop, and accept that I can whip out a script or simple web thingy if I really need to, and stick to being a hardware guy, which I'm actually good at.

Re: Early vs. Beginning Coders

#59

Post by breadbox »

morganvachon wrote: post #58

I feel like I'm perpetually stuck between what the author describes as "beginner" and "early". I understand what programming is, I can write a bash script that does what I want it to (granted, I have to read a ton of man pages to make sure I understand what it is I want to accomplish), I can write simple programs in Visual Basic or Python or Javascript that do simple tasks. I understand program flow, logic, and all t…

Or maybe you need to set aside the shell scripting and start learning a different language? "Things like inverted trees, functional programming, [and] polymorphism" really have no analogue in a shell language. Start working in C++ or Java, for example, and I suspect these things will start making more sense.

Re: Early vs. Beginning Coders

#60

Post by schoen »

Is there a book somewhere that tries to set out all of the things that experts know about computing that they don't remember learning?

(In Zed Shaw's conception, this might correspond to "learn computing the hard way".)

I see his examples and other examples here in this discussion, and it makes me wonder about the value (or existence) of a very thorough reference.

I've also encountered this when working with lawyers who wanted to have a reference to cite to courts about very basic facts about computing and the Internet. In some cases, when we looked at the specifications for particular technologies or protocols, they didn't actually assert the facts that the lawyers wanted to cite to, because the authors thought they were obvious. I remember this happening with the BitTorrent spec, for example -- there was something or other that a lawyer wanted to claim about BitTorrent, and Bram didn't specifically say it was true in the BitTorrent spec because no BitTorrent implementer would have had any doubt or confusion about it. It would have been taken for granted by everyone. But the result is that you couldn't say "the BitTorrent spec says that" this is true.

Another example might be "if a field is included in a protocol and neither that layer nor a lower layer is encrypted with a key that you don't know, you can see the contents of the field by sniffing packets on the network segment". It might be challenging to find a citation for this claim!

So we could also wish for a "all our tacit knowledge about computing, programming, and computer networking, made explicit" kind of reference. (I'm not sure what kind of structure for this would be most helpful pedagogically.)

Post reply on HN