Was looking at the lazycoder blog and saw a post on Herding Code podcast, sounding cool, I saw he posted on a “Back to the Basics” episode. I just want to be clear as I start this. I am a beginnermediate (not quite a beginner, but definitely not an intermediate developer) developer. I look and listen in my world at that level and base my conclusions on my skill level. The purpose of this post is to show a bit of the discrepancy between what an advanced developer would consider basics and what a beginner would consider basics. I do agree these are all basics, but I believe there are levels to them that should be clarified.
Below, I have categorized things the podcast hit on as basics. I tried my best to put it in a linear fashion as what you should learn first to last. I have also included a short opinion on each of these.
This is defintely something a beginner _needs_ to know. Not necessarily every part, but have a good idea of what is going on.
This I agree is another thing to learn so you get a better idea of what is going with Memory Management.
Here is the gold of what a beginner needs to learn. If you don't know the requirements or can't translate those requirements to code then you will most likely fail as a developer.
Floating Point Math
This is one thing that should be learned and is important, but not quite as important as not knowing the above. This tends to be an extensive thing to figure out and to really grok so I put it in the beginnermediate area once you know the beginner level and the general basics of developing like: if, then, for, variables and the like.
This is one thing that is a basic to learn. However, it is HARD to learn for the real world. I learned OOP in a college class in one semester no problem. It has taken me well over a year to translate, effectively, that knowledge into real world applications, that aren’t games. This is a big must, but can be put on hold to learn whats above first.
To me this is kind of a debateable topic as when to learn. I think before you move to intermediate level programming level you should learn the basics of source control because it is at this point that you are going to be writing more sophisticated programs that are going to need Source Control.
Data Structures being an intermediate skill to learn is kind of misnomer. I think you should learn 2 to 3 basic data structures like an array or in .net generic List<>. Just something to get you by then later once you understand more and more go back and really learn other data structures. I believe this really would work out well because then you have probably coded quite a bit and will learn the data structures quicker and really know when and where to use them.
This is most definitely an intermediate skill to learn. Design patterns are important to writing smooth pretty and effective software, but until you learn OOP really well or a few other things you are stuck in the land of “please just work”. Understanding and using design patterns from what I have seen just takes time and writing quite a bit of code before they make sense. I saw this because I have yet to be able to use them effectively and really understand when and where.
I put this in intermediate because I still don’t know what it is and everytime I ask I just get confused which means it is something beyond my skill level so I am defaulting it to the top of the list. Because of the not understanding problem I personally don’t think this is a basic, but I will listen to those more experienced than me and consider it a basic.
I guess I mostly wanted to do this post to kind of come up with a way to organize what and when to learn the basics. From reading and research ALL of the above basics are things that are used daily and very important to know, but not all of it is easy and can be learned quickly so it is good to break it down. I really loved this podcast episode because it is honestly not often I get to hear pro’s talk about the basics. The basics are something I strive to help people understand because it isn’t taught a lot online usually and _most_ of the time not well.