I’ve noticed an interesting debate emerge as of late, revolving around how best to lean to code. Some people claim you should start with a general computer science foundation, and then move into specific languages and their respective syntaxes from there. This more generalized understanding is essential, some would argue, in order to see the forest for the (virtual) trees.
People on the other side of the argument suggest you’re better off getting your hands dirty by actually building stuff (even if you’re only first doing so by following other people’s directions via tutorials). The people on this side of the debate argue that, if you do this, the big picture will form in time, and that it’ll be more grounded by the time it does.
Interesting. On the surface these seem like quite different approaches. So… who’s right?
You see, while one might at first assume programming languages are quite different, in reality they’re all trying to accomplish the same set of generally agreed-upon tasks – they’re just going about it in slightly different ways; with slightly different packages of gives-and-takes. Once you realize this, the idea of choosing your first language becomes less daunting. Why? Because you can rest assured that once you’ve learned one, many of the concepts will carry over for the others as well.
The other side of the argument goes like this: generalized concepts are a little too abstract if you haven’t actually seen code in action. And secondly, even if the abstract ideas do make sense, that alone won’t help you build anything. I mean, one can understand human communication conceptually, that doesn’t mean that you’ll be able to converse with someone in German or French, right? Right. Yes, there’s a certain value to this reasoning too, for sure.
Seen from another perspective, it’s sometimes only once you know what you’re trying to do that it begins to make sense to think about it conceptually. There is the whole “learn by trial and error” coming into play here. Often something clicks on a much deeper level if you find, through actual experience, that one approach is much simpler – or, as we say in the coding community – much more “elegant”, than another. This is the real advantage to just opening up your favored text editor and getting it done.
So, again, on the surface, these are quite different approaches. So who’s dealing out the real goods?
Well, like anyone else, all I can do is offer my personal opinion based on my own personal experience – mixed in with stories I’ve heard from other people as well.
What I’ve learned is that you really do need a little of both. Either approach, taken in the extreme, can create huge gaps; potentially catastrophic gaps, really.
You see, there really are people who have PHDs in computer science who can’t build an app that a high schooler just pulled off. Seriously. These are not myths. This happens. It’s great to have a big picture view on how to get humans and machines to interact in the most efficient manner possible. And these big picture perspectives sometimes lead to breakthroughs in approach. However, left alone, without “on the ground” experience with actual coding, these abstract principles can leave much to be desired.
Likewise, there are people who taught themselves to code, and have pulled off some pretty cool stuff, but have also picked up some glaringly bad habits along the way; habits that can prove difficult to break in the long run. This is where big picture concepts are so helpful – they offer up the “why” rather than just the “how”. While you might be able to code in an inelegant fashion and technically get an app to do what you want, you might be writing way more code than you need to, or ruthlessly hammering your database over and over again in the process.
And in the big leagues, this cascade of little inefficiencies can and really does add up; enough to potentially tank a project in the long run. So, yes, learning the right way really does matter, too.
So the old adage about moderation comes to mind here. Don’t follow either extreme. Instead, endeavor to gain from both approaches. And pay attention to your own learning style – and serve it. Just be equally careful not to continually avoid what you’re not good at yet, or what you don’t yet “resonate” with, because those oversights can prove costly in the long run – especially if the goal is becoming a well-rounded web developer.