For beginner posts, I'll assume you have no background in computers other than general use. Therefore I'll briefly explain a lot of terms that may be familiar to those with more experience. For intermediate and advanced posts, that won't be necessary.
There are lots of other "learn to code" resources available already, and I encourage you to use them. It's always good to learn from multiple source, because each one has a slightly different emphasis and take on the material.
The main difference here is that I'm going to teach multiple different languages at once. In fact, I'm going to cover 8 languages. That's my particular take on the material.
What?!? 8 Languages? Isn't that crazy? Won't that be confusing?
Yes, that's certainly ambitious and risks confusion. But I'll take advantage of the fact that there are a lot of common concepts between languages. I'll show you how to apply those concepts in the different languages, taking pains to point out the commonality and the differences.
Why multiple languages? The real secret to a long career is versatility. If you only know how to do one thing, the hot technology of the day, that's great until it's no longer the hot technology of the day. But if you know how to do multiple things, in multiple different ways, you can roll with it and adapt.
That will also help teach you how to acquire a new language. As I said in my welcome post to this blog, the most important skill you can develop is the ability to learn new skills.
There's another very practical reason. As a software developer, you often need to work in multiple different languages at once. Different parts of what you do will be in different environments, where different languages are in use.
Here are the languages:
- C
- C++
- Java
- Javascript
- Go
- Python
- Bash
- Pseudocode (not a real language, useful for sketching out designs)
On a daily basis in my job, I may work on some C or C++ for one of our embedded devices, some C++ for one of our backend servers, some Python to analyze frames in a video file or automate data retrieval from AWS, or some Bash to automate build steps or file management activities.
I may have to read someone else's Javascript for another backend server or Java for a mobile app. I'm constantly scribbling stuff in pseudocode as I work through my thoughts.
It doesn't stop there. I may have to update some Ruby to handle cloud deployment, or work on some Lisp for Emacs macros.
My facility with each language varies. I'm barely functional with Ruby or Lisp. But a little Googling around and experimentation allows me to get the job done. My experience with other languages helps me out, despite significant differences in them. That's how versatility increases my ability to tackle different problems.
In the process of teaching you, I'll also learn Java, Javascript, and Go myself.
Hang on, didn't I just say I may have to read someone else's Java or Javascript code at work? Right, I can read it, based on the common characteristics it shares with the other languages, but I don't know it well enough to write it. Learning to do that means I'll be able to contribute more at work. And I want to learn Go because it's one of the hot technologies of the day, that I believe has a long life ahead of it.
But if I don't know those languages, how can I teach them? That's another point from my welcome post: teaching is a great way to learn something, because I have to work it out myself well enough to explain it to others, augmented by my experience. See one, do one, teach one.
How will I do all this? I'll jump right in and start showing you example code, then break those examples down and go through them. Realize that in some cases, the code is written in a particular way to illustrate a specific point. So some of it will be very simplistic. You have to walk before you can run.
But I'll move on from there into more advanced topics, including:
- Socket programming
- Synchronous vs. asynchronous programming
- Multithreaded programming
- Algorithms
I'll cover applying these in a number of real-world systems, ranging from personal computing to big iron to miniaturized devices:
- Desktop applications
- Web apps
- Mobile apps
- Server systems
- Embedded systems
I'll also touch on engineering process topics, including:
- Software development life cycle (SDLC)
- Requirements
- Architecture
- Design
- Testing (see Testing Is How You Avoid Looking Stupid for a discussion of testing)
- Source control
Why so much? Because I want to show you how to be a Real Practical Software Developer (RPSD), someone who can really get a job done, not just a Superficial Crappy Software Developer (SCSD).
An RPSD has depth. An SCSD just scratches the surface. An RPSD seeks understanding. An SCSD just seeks a quick fix.
These things are all important to know as an RPSD. Knowing how to code in the languages is just the first step. Making that code do real, useful things, working in a real software development environment, is where it really gets interesting.
I'll be introducing lots of terminology, indicated in italics as above. I may throw some terms out there before actually getting around to explaining them. Just remember that terminology can be slippery, having different meaning and usage to different people and in different contexts.
I'll also have some posts related to general programming knowledge and skills, like working with binary and hexadecimal numbers.
I'll use or refer to a number of online resources and books. The online resources are free, and include tutorials, programming tools, test platforms, and articles. Some of the books are also available as authorized downloadable PDF's that authors and publishers have generously made available for free (some PDF's are unauthorized pirated copies, so be careful what you download).
And let's make something perfectly clear from the start: there's nothing wrong with using Google or StackOverflow to find out how to do something, or as a reminder. As a student learning to code and later as a working RPSD, you'll get to know these as invaluable helpers, along with a few favorite tutorial sites.
I do that all the time, because I can't possibly know or remember everything. Why should I? I have computers to help me do that. They have a vastly larger store of knowledge than any single human.
When you look up something in a book or online, the key is not to just copy code blindly, but to take the time to understand what it's telling you, then adapt it to your situation. That's how you stand on the shoulders of others and increase your own store of knowledge.
I've been doing this for 35 years, and I love it. Building things and seeing other people put them to use gives me the greatest satisfaction. I hope you'll find this series useful as I share what I've learned.
Comments and Questions
I welcome comments here on the blog and emails at sdbranam at gmail dot com. Those might turn into good topics for further posts.
Note that I actively filter out comment spam. If you put a link in a comment, the comment must be directly relevant to the post, and the link must either refer to your personal online resources or to something directly relevant to the post. Otherwise I'll delete it.
(Continue to First Code)
No comments:
Post a Comment