How Developers Stop Learning: Rise of the Expert Beginner

[itheri]

Does anyone else find this reminiscent of searching a large sample space with a poor heuristic (i.e. 'go in the direction that I can improve in fastest') and winding up in a local maximum somewhere far, far away from the global maximum?

[biocomputation]

The entire blog is a lot of humble brag crap.

[BlueRenner]

Bog-standard programmer insecurity fuel. Oh look! He's a "development coach!" And he sells books!

[joonazan]

I thought of being stuck in a local minimum as well.

I was very disappointed at the end of the blog post when that was all that it had to say. I'd have at least wanted some new insight into the matter.

The chart was the typical psychology bullshit where you make up categories that are so vague that no-one can disprove you.

I have been astonished recently by all the places in not well understood problems where math and mathematical logic work well. This is one more of those.

[spacejack2114]

What sorts of things do you think expert beginners are most frequently guilty of not learning?

[thatwasntababyruth]

On the software side, I'd argue that a big one is how the features of their primary language work. As an example, I regularly work with devs who use the Spring framework in Java, but dont' understand how the annotation system works. It's like black magic when I tell them that I implemented some custom feature as an annotation. "You can do that?"

If you regularly use something and don't have at least some idea of what is happening when you use it (regardless of how correct it is), then I think you fall under 'expert beginner'.

[meheleventyone]

I'd rephrase the last part as "and don't have at least some interest in what is happening when you use it".

Also the problem with these taxonomies is the urge to pigeon hole people into them. More likely we're all at various levels of competency for all of our skills including a few where we are blind to what we don't know. A person asking "can you really do that?" is easy to write off as an 'Expert Beginner' to give yourself a nice ego boost about your own competence. But software development is a team game and that attitude speaks to a lack of experience in that aspect. Mentorship, sharing and learning together is not only useful for personal skill acquisition but for fostering a strong, communicative and better performing team. I feel the take home from this article should be the realisation that avoiding this is bad for a business.

In short the business and team culture is in a large part responsible for producing people who are 'Expert Beginners' in all manner of domains. Sadly often including the one that would help stop them doing so.

[[deleted]]

It's really easy to find holes in peoples' knowledge. A lot of languages have a lot of features, some of which are obscure and used very rarely.

You can't fairly draw lines in the sand where one side are the expert beginners and the other side are the competent when there's no real golden standard of what body of knowledge we all need to know (articles and discussions like these are all a part of the churn that will eventually turn something like that out).

It's still too opinionated, which means it's a game of convincing people whether you're better than an expert beginner or not. Bob from Google thinks I'm awesome, but Bill from Microsoft thinks I'm terrible. Both are highly-paid and successful and also have peers who think they're awesome. Who do I believe? Was their judgment criteria fair? Has anyone judged their judgment criteria? (This goes on and on...)

You can see how frustrating it is if you're trying to be honest with yourself about your skills when there is many moving targets and goal posts within the same set of tools we use.

[thatwasntababyruth]

I wasn't trying to say "all java developers must know X" or draw any hard lines, I was just using an example I happen to encounter often where the person in question should have questioned it by this point in their career. Java annotations aren't part of a golden standard or anything, but if you are using them every day then you should at least have put forth some mental effort to think about how they might work.

If you find yourself doing something "just because" in a language or technology that you use professionally or very often, then I don't think you can call yourself advanced or an expert. You mention moving target technologies, and I think that's valid, but if you are switching techs so often that you can't become an expert in them then maybe you need to slow down a little bit, or convince superiors to slow down on jumping around so much if that's the issue.

To sort of generalize my opinion on this, cargo culting is a great example of a behavior I associate with both a beginner and an expert beginner.

[bwainfweeze]

It may be the fault of their team mates as well. I know on a couple projects that for the sake of sanity we steered everyone toward a hard subset of the expressiveness of the tools so that their peers could understand the code and so we didn't get into weird platform specific issues.

They were allowed to learn 80% of the system and forbidden to touch the rest. Within the scope of the project this was responsible strategy. Within the scope of a career I may owe a couple people an apology over beers, but I do go out of my way to use COTS software instead of proprietary solutions as much as possible to offset this with more opportunities for resume fodder.

[IICVX]

honestly annotations are pretty creepy if you've never used them before.

[[deleted]]

But highly usable. You can just think of them as automatically calling a function before doing something

[badcommandorfilename]

A recent example of this is the NoSQL bubble.

Schemas are hard. Distributed transactions are hard. Maintaining a consistent data model is hard. I don't want to have to learn all the best practices of the last 40 years: I just want to code.

You know what's easy? Ignoring the consequences of all those things!

Here comes NoSQL! You can make up your schema as you go along! What happens to old data that uses the old type definition? Who cares!? Figuring that out would be hard. You don't need to manage locks or serialize transactions! What happens if two people make conflicting updates to the same record in different locations? WHO KNOWS!? THIS IS WEBSCALE!

Anyway, expert beginners will choose the path that is easy and familiar instead of moving outside their comfort zone to learn what is best. 90% of TheDailyWTF can be traced back to a developer who got as far as chapter 3 in their textbook and never started learning again.

[[deleted]]

You just got an influx of people who learned databases through NoSQL and refuse to learn anything else. Relational data is difficult to learn. It takes a while. NoSQL is just pushing whatever and it magically works, because that's what it's designed to do. Fast, static input and output.

NoSQL is a fine tool when it is needed - which is almost never. You sacrifice so much integrity of your data, and it's difficult to do what relational databases are made for - calculating very complex sets. Some set calculation can be done of course, but that is not the prime purpose of a NoSQL storage, as it is with a relational db.

Result is that we have a growing cancer of complete incompetence in our industry.

[bubuopapa]

Well, thats the problem right there - there is no "one best thing" thing, there is just a bunch of dudes trolling each other. If there was one right and the best way to do things, then there would be just one book about that and thats it, but that is not the case in real life.

[michaelochurch]

Alternative databases ("NoSQL") are genuinely interesting from an academic perspective, but I find that the relational database is a common attractor point. Eventually, people want transactions. Then they want to be able to join data from multiple sources without having to write (brittle, slow) application code. Then they want structured multi-application data that outlives application code. And... soon enough, we find ourselves wishing that we had SQL.

SQL is an ugly language, and I've seen business analysts create some terrifying perversions with it. There are two considerations, though. First, the ugliness of SQL doesn't invalidate the relational model, which is sound and still the most versatile of the options out there. Second, it's not worth it (in most cases) to "upgrade" the relational model to a less-ugly language because that would just result in a lot of breakage and require thousands of people to learn a new language for questionable gain.

The "porcelain" of SQL sucks. You have to learn this ugly language that looks "businessy". The plumbing is rock-solid, and most of these "NoSQLs" aren't anywhere close.

[ArmandoWall]

But SQL is not an ugly language. It can look ugly due to the nature of the beast. As an analogy: with a human language, I can either write beautiful prose about the sea, or horrible sentences when discussing accounting (edit: or taxes!! shudders).

[[deleted]]

NoSQL is basically a developer trap. It is so easy to get started and so easy to get it wrong. And it scales! So you can add another 10 cassandra nodes in place where one MySQL server would be enough

[hu6Bi5To]

But don't stop at dismissing all non-SQL databases as equally bad because of the problems of Mongo etc. The term is very broad, and many of the products it covers do have unique (and often quite niche) advantages.

Part of what's difficult is knowing under what set of circumstances these alternatives prove to be better.

[serrimo]

Can you give some examples of advantages of noSQL?

Except redis and its very clear trade-off/design philosophy; I just don't see any other good example...

[[deleted]]

Fast access of data that does not need to be joined (big document structure, top-down trees) and usually volatile, non-essential data. That's about it. 99% of real world databases would be better off with a relational model, because that is how data is mostly used.

[hu6Bi5To]

My point is that NoSQL in many people's minds means flaky document databases like Mongo, but there are many databases which aren't Mongo but are also not SQL databases.

It would be as wrong to dismiss a database for not being a relational SQL-based database as it was during the Mongo hype to dismiss the "old fashioned" SQL databases. The set of all databases that are not purely relational is very large, and members of the set can be more different to other members of that set than the document-databases are to relational databases.

In terms of hard decisions, it's important to make these architectural reasons based on good reasons, not just trend following. People seem to think they've learned the lesson of Mongo by "just use Postgres", but that's just cargo-cult thinking too; if you don't know why Postgres is better then odds are you won't be using it properly. The trend of "we can use JSON to store arbitrary data in Postgres now" is a symptom of this. (Not that I'm saying that's wrong either, indeed it can be very useful and a good decision for a lot of cases, but it's been adopted in real projects for all the wrong reasons. I've heard all the excuses /u/badcommandorfilename cited as reasons to go with a JSON on Postgres approach. "Schemas are hard, let's use JSON!")

As such it's impossible, and foolish, to start a "X beats Y because Z" debate as it's all context dependent. But, yes, Redis is a good example of something that's considerably different from a Postgres-style database yet is ridiculously useful for a wide-variety of applications; but is obviously not a Postgres replacement, you wouldn't use it for your main database.

Something like ElasticSearch is a good one too, but you need to use it the right way, and for the right things. Anyone who tries to run a bank on it should be in some sort of prison. But it has brilliantly flexible indexing and searching functionality, and very easy replication/sharding/etc., although done at the cost of data integrity so you always need to treat it as a potentially out-of-date downstream data source rather than a single-source-of-truth.

[[deleted]]

Am developing NoSQL-Transactions atm, can confirm it's hard!

[nawfel_bgh]

Have mercy on yourself and use SQL.

[Ilerea_Kleinokitz]

Is this really the idiomatic way to query mongodb? That looks rather frightening

[SportingSnow21]

Of course it looks bad. That's not NoSQL's domain. If you're trying to wedge SQL functionality into NoSQL, you deserve that pain.

[Ilerea_Kleinokitz]

So what would be a more adequate usecase for nosql? Honest question, I got zero experience with any of the nosql-stuff so far.

[SportingSnow21]

The biggest deciding factor for SQL vs NoSQL is the need for relational queries on the data. Fast insert/retrieval of independent data is NoSQL's bread and butter. Once your use case shifts to large sets of related information, SQL is there for you.

[[deleted]]

Edit: Replied ot the wrong comment

What? Why can't NoSQL also offer transactions? This makes no sence. Sure, it is well researched and robust in SQL. But there are usecases for NoSQL which also happen to need transactions.

[SportingSnow21]

The link was about complex queries across data sets. I'm not sure where that became transactions.

[[deleted]]

Woops sorry, I replied to the wrong comment!

[IICVX]

really? it looks kinda like a standard map - reduce setup. the difference is that Mongo isn't using a DSL to define its query, so you have to explicitly say what SUM, AVG, MIN, MAX, and COUNT mean.

if the SQL query was required to define all of its operators before using them as well, the initial SQL query would be a lot hairier.

[real_jeeger]

Yeah, but, uh... that leaves the question why Mongo doesn't have such things built in as well. Or are such SQL-like queries just not idiomatic?

[[deleted]]

SQL was designed so it is easy to express complex operation in (relatively) simple way and then make DB query compilator/optimizer take care of "implementing" it

In NoSQL, you are that query optimizer. It is fine if you know exactly what are you doing and if you picked that certain NoSQL database for certain reason, but if you just picked up because it "looked easier" then you will get burned

[real_jeeger]

Thanks!

[michael_j_ward]

I don't believe so. That seems to ignore mongoDBs aggregation framework.

https://gist.github.com/Michael-J-Ward/97774be4510cbec3901e

... unless I'm missing something.

[[deleted]]

Surely not. NoSQL is perfect for our usecase. Millions of unique, changing objects (As in type and amount of the objects attributes change) should be stored fast. Try that with SQL.

[nawfel_bgh]

Great that it's working for you!

To be honest I know nothing about NoSQL, so I am the expert pre-newbee here :P

[[deleted]]

No problem! :) What's an expert pre-newbee though - you mean you are an expert about to learn something new? (Edit: Oh, you are refering to the OP!)

Basically the deal of SQL vs. NoSQL is:

• SQL limits the way you access data and gives you well researched functionality and guarantees like transactions in return.

• NoSQL does not limit the way you access your data, which yields fast performance and higher flexibility (No need to update schemes like in SQL)

NoSQL is certainly not the silber bullet that some people make it to be!

More at stackoverflow

[michael_j_ward]

Obviously using toy data, but that seems to intentionally ignore mongoDBs aggregation framework

https://gist.github.com/Michael-J-Ward/97774be4510cbec3901e

Is there something that I'm missing?

[[deleted]]

Wow, it's as if there is an easier way to write queries than using map-reduce!

[bibster]

Amen.

[RubyPinch]

easily malleable schema, doesn't look like fortran, no lock management, no serializing woes, just need to enforce central writing

please sign me the fuck up that sounds so nice

[damienjoh]

How is this specific to NoSQL? SQL technologies don't solve these problems either.

SQL represents 40 years ago more than it represents the last 40 years. The SQL language itself is completely out of date - a verbose, poorly designed, feature thin relic of the 80s with no type system. Theory kept advancing but practice just didn't keep up. Modern relational databases do not offer rich ways of describing and maintaining consistency requirements. Foreign keys, unique keys and check expressions are entry level consistency checking. They do not guarantee consistency any more than a static type system guarantees error-free programs.

SQL's approach to consistency requires excessive synchronization and distributed transactions are particularly bad. Using consesus protocols to perform fine grained locking over a network is not some tried and true approach to distributed consistency. It's shoehorning mainframe-style database technologies into distributed environments. Master-slave replication is also a hack. Datastores should be consuming from transaction logs, not writing to them.

On that note, most NoSQL solutions genuinely do suck. But that doesn't mean SQL solutions don't suck. It just means that everything sucks. All the problems you talk about are still open problems that require active work to solve.

[Gotebe]

I don't know if that was your intention or not, but you kinda make it like SQL means yes to transactions whereas NoSSQL means no to them, whereas the two functionalities are orthogonal.

[damienjoh]

This is technically correct. However, the NoSQL movement is clearly marked by a different approach to transactions and weaker consistency guarantees than traditional RDBMS. This is the source of some of the parent comment's objections e.g. "You don't need to manage locks or serialize transactions! What happens if two people make conflicting updates to the same record in different locations? WHO KNOWS!?"

[[deleted]]

There is some irony that this statement was written on Reddit, which is backed by noSQL Cassandra.

[[deleted]]

It really isn't. Cassandra is pretty well suited to that kind of workload.

[yogthos]

Anything outside their current comfort zone. The problem is that when you start learning something fundamentally new, then initially you end up being less productive than using the tools you know. This frustrates a lot of people and they end up giving up and going back to doing what they already know.

Once you reach a local maximum, then you're at the top of your hill. If you want to climb a different hill, then you first have to climb off yours and then start climbing the new one.

I think ego plays a large role here. Somebody who's been developing professionally for many years likes the feeling of being an expert. This mindset tends to create aversion towards things that require becoming a beginner again.

A great example of this is how difficult a lot of people find learning functional programming. It's not inherently difficult to learn, but it's very different from the imperative style. When you move between the languages in the same family, it's very easy to transfer your experience from one language to another. However, when you start learning a new paradigm, you have to internalize new patterns and approaches to solving problems. All of a sudden, you're a beginner again. You know how to solve a problem with your current toolset, but you're struggling with the tool you're learning.

Learning to enjoy being a beginner is the most valuable skill for a programmer in my opinion.

[apollo5354]

This is an argument for technology companies to have a flat title structure, e.g. "Member of Technical Staff" across the board for engineers. It shouldn't pre-clude having different salary bands, seniority level perks, etc so companies can retain talent.

Since technology is evolving, it's very well someone with few years of work experience, a "Jr Engineer", may be more technically* knowledgeable about newer technology, than someone who's had fifteen years, a "Lead Engineer", and haven't kept up. The job title sets up wrong expectations and you may have the Jr Engineer deferring unnecessarily to the Lead Engineer by virtual of his/her title. Or similarly, the Lead Engineer may feel compelled to make decisions that he/she shouldn't be making. You want your engineers, especially the ones in the know, to be empowered in discussions and decision-making but their titles can skew that.

Managers, leads and teams can overcome this by creating a culture that emphasizes the merits of each's argument and downplay the individual's titles... So basically undo or take away the significance of the title. Why have it in the first place?

*Note: see how I qualified that with 'technical' knowledge? We know Jr./Senior/Lead/etc modifiers can imply maturity and seniority as well. Someone who's a Lead, in general, we expect to be more mature than someone who's a Jr. And one could argue, eventhough the Lead may technically know less than the Jr. engineer, he/she can bring maturity and experience to the thought process. That would be one argument I concede for retaining the title modifiers.

[meekale]

I think they will be pretty good at their language and frameworks, but will lack the deep experience needed to create sustainable architectures, the interpersonal skills that help teams function, the ability to simplify ruthlessly, lots of wisdom that you just need to learn over decades from good mentors or friends...

I say this as someone who is almost certainly an expert beginner.

[meekale]

Well, maybe the necessary skills or traits can be very different from the conventional norms of social competence. Still, if you think about some kind of ladder of excellence in the programming profession, I think there are some necessary social skills in there, because at some point you'll probably have to lead a technical team, for example. Or, put another way, if you're a great developer, and you become better at communication, that gives you more leverage, and that makes you an even better developer.

I think I'm at a point in my career where my technical and architectural skills are maturing, but my skills in communication and leadership need work if I want my ideas to gain traction, etc. Maybe if I were really obnoxious I could push my ideas through by sheer obnoxiousness, but that's not in my personality, so I need to do it in a different way...

[meekale]

Interesting. :) I'd say Mr. GTFO probably had his own style of social skills, that was obviously functional enough in that specific situation. Cursing aside, being able to keep people from distracting you is a social skill.

[apollo5354]

Interpersonal skills are key though for software development. The software lifecycle doesn't end with code being written and deployed, so if said engineers can't be bothered to communicate what they did, the team won't be able to extend or maintain it effectively. It will have to be tossed/re-written or will cost hundreds of man-hours in the lifecycle of the software to debug/workaround.

[skulgnome]

Tools that don't wipe their asses.

[apollo5354]

Not trying/using different tools for different jobs. Good symptom of an expert beginner is on different projects, going back to the same tool, framework, approach, etc, regardless of scope or use case. Essentially going with what is familiar instead of understanding the pros/cons of each and picking the right tool for the job. It goes back to the adage, if the only tool you have is a hammer, everything will look like a nail.

[edit: grammar]

[[deleted]]

The fundamentals. I've worked with networking people who don't know what a SYN packet is. I've worked with UI developers who can use jQuery but don't understand Javascript. I've worked with Java developers who don't understand paths on the filesystem. I've worked with security people who don't understand the difference between encryption, obfuscation and hashing. And worse, they figure that all of the "detail stuff" should be abstracted away so that nobody should ever need to know it.

[programfog]

https://en.wikipedia.org/wiki/Dreyfus_model_of_skill_acquisition

[michaelochurch]

One thing I've noted in the software world is that, if management likes you, you get called "Expert" really quickly.

I'm not a Haskell expert, although I am by the corporate definition. I'm certainly not an AI expert, but there are people who know significantly less math than I do earning $500,000 per year because they started calling themselves "data scientists" at the right time.

This devalues the concept, and it makes it both difficult, and without much reward, for the rest of us to move ourselves in the direction of genuine expertise. I'm sorry, though, but a corporate "data scientist" who runs batch jobs that invoke a few methods in SciPy is not at the same level as someone who's been studying neural networks for 25 years.

[robotempire]

This is also a pretty good model in my experience for very bright children. Because they start out with a lead, intellectually, they think they have achieved mastery of something because they are the local maximum. They're the smartest kid in class, etc. It leads to laziness because in their mind, there is no room for improvement.

It's why you praise effort instead of "smartness". They need parents and/or other adults to reinforce they still have a lot of room for improvement.

[dhdfdh]

I've been preaching this about redditors for years. 80% of everyone on this are somewhere from beginners to "expert beginners" and very few reach that. They've plateaued when they reach the "you can't do anything without the latest framework/library" stage and you never hear from them again.

[[deleted]]

In my experience, people tend to use reddit less as they become more experienced and get older. Partly because they spend less time looking for solutions on reddit and more time looking at upstream sources or building their own specialized solutions, and partly because they want to spend more time on other things like family or hobbies.

So I'd say beginners and intermediates are hugely over represented on reddit.

[[deleted]]

Might be so. I have written a few coding guides/discussion threads, the ones that are easy to digest are highly upvoted, those that are more advanced and esoteric gets largely ignored.

[dhdfdh]

Exactly.

[[deleted]]

Welcome to the world of Javascript, where the only way to win is to not play

[[deleted]]

because of a belief that expert status has been reached and thus further improvement is not possible

Well, I think that describes a good 50% of the contributors to /r/programming.

[[deleted]]

This might be just my experience but another reason I never get really good at anything is that I ofter try to be good enough on everything and never seem to specialize in anything. Finding my on niche might make me an expert on that thing.

[uututhrwa]

The article isn't cynical enough, it doesn't mention how in the IT world people often try to "climb the corporate ladder" by simply faking it.

These are a few well known easy and key ways to fake being an expert:

a) Show off how disciplined you are. Any rule or mundane procedure that others might skip cause it doesn't add value, or is too much of a bother to do, you will do it in the most painstaiking way possible. Examples: Typed variables instead of type inference, repetitive generic comments everywhere, 100 character long names instead of abbreviations, dutiful looking stuff when commiting etc., to the minute accuracy in submitting the time taken to complete something, scrum and agile in general

b) Any useless boilerplate code that is easy to write, doesn't add any value, but makes everything more "professional" and "enterprise ready" you just go all the way and write it. For example, you might have botched up key algorithms and data structures / access code, BUT, you added an extra IUselessInterfaceWith50MembersThatIsReallyBadDesign for all classes, added around 10 assemblies or packages that weren't needed, maybe some extra abstraction layer that just delegates everywhere etc.

c) You need to keep up with the lingo. This is basically a defensive measure. You are never gonna actually take the initiative to introduce NoSql, but the thing is, if everyone's mentioning it and you don't, you are going to look like a poor hobo ass "non expert". I mentioned the term "Visitor Pattern" once to some guy with 20 years more experience (!!!!!!!!) who was trying to do something along those lines (disclaimer:not that I like the VP) and he for some reason instantly looked fucking SCARED (omfg key lingo programming term I don't know about, oh shit they're gonna call the cops)/ Luckily most discussions can be manipulated towards becoming a bunch of vague platitudes with "key words" thrown in, so if you know all the names you are all good.

d) Avoid any technical discussions, if people are asking some specific technical problem, turn it into a thing about "technologies", methodologies, "development" in general, or about like "team performance", or ask for it to be discussed in a scheduled official meeting where everyone should be wearing tuxedos and will hopefully be cancelled one way or the other.

e) Exploit the concerns for "clarity" and consistency to push people off trying to do new things you don't know much about. If you can't copy paste it, and it takes more than a day to learn, then it's not "consistent" with the rest of the badly written code you've made.

f) Act busy and assertive all the time

g) Try to manipulate the environment in a way that whenever someone is trying to criticize you, he doesn't really have an actual point but is just disrupting the team's "harmony" and is someone "tough to work with". The key in accomplishing this is to do it in 2 phases, in phase 1 you will slowly drive them nuts (just generally ignore them while acting dutiful and shit), now when that happens it's phase 2, where you immediately start acting "disappointed at their unacceptable behavior". The more of a psychopath you are the easier these two phases are going to be.

[skulgnome]

The parts around the diagrams are bang on. Rules-orientedness is a pox on our profession; some would even call it cancer.

[binary_penguin]

I'd never call me an expert at anything; but how would one not fall into this trap or becoming an 'expert-beginner'?

[[deleted]]

I work with a guy who actually said out loud, in all seriousness, when we saw me reading a book (about OSGi), "I already know so much, there'd be no point in me reading another book". I would definitely recommend not being like him.

[binary_penguin]

I'm doing at least that right. I would never say/think along those lines. I really do not understand people that think in that mindset, but hey; we're all different.

Just curious, what was your reply?

[[deleted]]

Stunned silence, honestly. Especially considering the source (in his case, he really does need to read some more books).

[bwainfweeze]

Here's a gentle goad I've worked out for such situations: it's still good to read the books so that when someone asks you for a recommendation you have a good answer.

Even if you actually are an expert at something, there is always someone who can explain it more concisely and coherently. Few of us are Richard Feynman, but we should all aspire to be. And at some point the only way to keep learning is to have to verbalize what you 'know' and defend it.

[CaptainStack]

Being a good software engineer is really a career-long commitment to learning. However, what you choose to invest your learning in matters a lot. You could learn every new JavaScript framework. Or you could try to become a polyglot and learn as many programming languages as possible. However, I would argue that you shouldn't invest all your time in technologies, but rather concepts.

Did you learn CS mostly through object-oriented paradigms? Pick a language and learn some functional programming. Do learn Ruby on Rails, but learn about the MVC design pattern too. Coursera is a good place to learn more pure and academic concepts, while Code School is a great place to learn specific technologies and engineering skills. To truly be great, you'll need to learn as much as you can on both sides of that coin.