Important 10 Things I Wish I’d Known Before I Started Coding
I know I am not the only person out there whose journey into software engineering was delayed because I just didn’t know where to start.
The plethora of resources provides an incredible opportunity but also can make embarking on the first steps intimidating. For those of you thinking of taking those first steps, or who are in those first steps, here are 10 things that I wish I had known before I began.
1. Choosing a Language is Important
There are a multitude of programming languages out there. Each language has its strengths, its weaknesses, and situations in which it is best suited.
While your first language will almost certainly be the hardest to learn and many of the most basic fundamentals will be similar across languages (variables, iteration, etc), it is worth the time and effort to do some research and decide which language you want to start with.
Ease of programming is something that should certainly be considered. Be honest with yourself about how confident or intimidated you are feeling. If picking a more complicated language will ultimately deter you from progressing with it, it may be better to pick one with which you can have and feel success more easily at first.
Another important factor is why you are learning software engineering. If you have an idea for an app you want to build, start by thinking through the logistics of that app in the early stages and at scale, and do your research as to which languages and technologies are best suited to your needs.
If you’re hoping to join a company as a software engineer, make a list of 10–20 companies that you’d love to join, find their job postings for software engineering roles, and note which languages they’re using.
2. Languages All Have Official Documentation
Languages are not just created and sent out into the ecosphere with the hopes they’ll be understood. Languages, frameworks, and libraries are thoroughly documented online, from the most basic concepts to the most complicated applications. I have listed the links to a few below so you can see what these look like:
3. Google is Your Friend, and You’ll Only Grow Closer
Every single software engineer uses Google when he or she is stuck. This is not something that is done just as a beginner, nor is it something that goes away. Odds are, you are not the first person to have received whatever weird error message or bug you are facing, and with any luck, those before you have taken to StackOverflow.com or somewhere similar to get feedback and solve their problems.
There are no points in software engineering for getting from A to B without Google and other resources. There are only points for getting to B efficiently using clean code, best practices, and scalable algorithms.
4. It’s Not Magic — It’s Problem-Solving, and It Can Be Learned
So many people look at web applications and feel like they’re just magic.
They’re not. They’re hundreds of thousands of lines of code all written with precision to perform individual functions and operate flawlessly within the whole.
Like anything, like any other language, it can be learned. It makes no sense at first — the same way that French or Chinese makes no sense to a nonnative speaker at first. But like these languages, little by little you learn how to represent your message using its syntax and diction and learn to communicate anything you want through it.
5. You’ll Never Know Everything
You’ll never, ever know everything there is to know about software engineering or even any one language.
This is in part because there’s simply way too much to know. But it’s also because what there is to know is always changing.
New versions of languages are regularly released with different functionality and updates. New frameworks and libraries come out that become the it framework of the moment, with everyone wanting to use it. Better practices are discovered to replace the current best practices.
The only constant of software engineering is that it’s always changing and evolving, and it’s best to become comfortable with this fact off of the bat.
6. GitHub is a Thing
GitHub is a remote version-control system that works with Git, a local version-control system.
You should have an account from the start and should become familiar and comfortable using both.
Throughout a project, there will very often be times that you need to tackle a problem but aren’t sure how to or just want to try something to see how it feels.
Git allows you to do just this without risking breaking your working code. It does this by allowing you to branch off of the master project, essentially creating a separate version of the code that you can toy with while leaving the master, working branch completely in tact and also by allowing you to choose what you actually commit to the project.
You can try this way and that way of solving a problem, and the file will save, but until you actually do a git commit, it won’t be saved in the master git branch.
GitHub is just a remote storage system for your local Git repositories (this also means that, yes, for each project, you need a local Git repo and a GitHub repo). Think of it like DropBox for code. This way if something happens to your computer, all of the precious code you’ve written won’t be lost.
7. HackerRank, LeetCode, and Codewars are Also Things
These three sites (and there are certainly others) have endless code challenges that allow you to hone your skills.
Once you are at the point where you feel like you can comfortably write even basic code, you can go to one or all three of these to start learning how to solve problems using code. They help to hone not just your knowledge of syntax and writing the language but also your problem-solving skills.
I personally love LeetCode because it gives you real feedback on the quality of your solution, not just whether or not you solved it. I use HackerRank a lot as well, though, just because I like the challenges that it offers.
8. Practice Makes Perfect—Or at Least an Able Software Engineer
You’ll never be perfect, and you’ll never know everything. But I cannot overemphasize the importance of practice, practice, practice.
Like anyone else, there have been times when I’ve felt like I am trying to learn something that is just simply not clicking. It can feel demoralizing and make you want to just give up and move on to the next. But I promise if you keep at it — keep practicing even if it feels like you’re getting nowhere with it — eventually you will have that moment where it does click. All of a sudden everything will make sense. It can be hard to get there, but it’s so worth it.
9. Languages Are Not the Same as Frameworks Which Are Not the Same as Libraries
You’ll hear the terms language, framework, and library using in extremely similar situations, but they’re not the same thing. A language is programming in its rawest form (aside from binary). It’s what eventually gets compiled into 1s and 0s. Examples of languages are Ruby, Java, Python, and JavaScript.
Libraries and frameworks are built on top of and using languages, but they are also not the same thing. They both abstract the language they’re built on to offer solutions to solve common problems. Often this is in the form of providing common methods so they don’t have to be written each time or a command line option for generating the bones of a new app. The main difference is who is in control.
Using a library, the software engineer remains in control and decides where he or she wants to use the library. He or she is in control of the flow of the application. Examples of libraries are React.js and Redux, which are both JavaScript libraries. With a framework, the flow of the application is predetermined. Rails is a common Ruby framework, as is Django for Python.
10. It Is So, So, So Much More Than Memorizing Syntax
Software engineering is so much more than just memorization and knowing syntax.
Coding, when it’s working as intended, is easy. It’s knowing how to debug when you could swear that the code you wrote is right. It’s solving a complicated problem. That’s the challenging and fun part.
To do this, you must understand not just that a + b = c, but also why a + b = c. If you don’t, one day you’re going to add up a and b and instead get d and have no idea why and no tools to figure out why.
The nuances of each language and how a line of code works is so, so important, because it will lead to unintended consequences sometimes.
Comments
Post a Comment