Wanna learn to code? Maybe you're going at it the wrong way

Today I needed to find a very old, personal document, which I thought to be forever lost. I knew finding it would be hell, but I had no choice. I needed it. So I put on my big boy pants and went on one of those dreaded quests where you battle the contents of that one drawer (I know you got one too), looking for that Schr?dinger`s cat-like piece of paper, which may or may not be alive. Obviously, I found all kinds of things, which made me seriously question some life decisions, like "yeah, I'll definitely need this receipt of two beers I had at an oktoberfest 10 years ago", and while at it, I promised myself for the thousandth time that I would most definitely come up with a system to organize my documents and forget about it 5 minutes later.

Among this bunch of nostalgia-filled, nonsensical pieces of paper I found (I kid you know, I even found the movie ticket slips for the lord of the rings movies), I found one of my first programming assignments in college, back when I thought I’d major in Physics (nerd reference above explained). It was dated from 2007, and the assignment was for me to write an algorithm which would take in two bidimensional arrays and multiply them, yielding the resulting array in return. At that moment I obviously already had some experience with programming, but this was from my first ever code class, so that experience was very limited. This chair aimed to teach us the basics of the basics, in C.?

I won’t go into details about the dreadful code I wrote, which I could break today in a couple tries, but I’ll mention this: writing a visual matrix representation on a console involved a lot of ridiculous code, with print functions all over the place, which is funny to look at it, at least.

But finding this assignment, along with a few others (even a few code snippets from the time I wrote a version of tetris, also in C), made me think about my journey so far. It basically means that I’ve been wrestling with code since 2007. That’s 15 years, at the time of writing. And, in hindsight, thinking about what I learned and how I learned it, I guess I picked up a thing or two along the way.

On all those years, I’ve seen (almost) it all: I built great software and I built really crappy software. From working for really small companies to working with companies that are real life behemoths, I've seen people that knew what they were doing as well as people who were completely lost. I worked with people on the top of their fields that struggled with how the digital transformation of the world is happening. I worked with people that excel at the art of crafting software and are light years ahead of me. I worked with people that were willing to teach, as well as with people that thought that a need-to-know basis kind of workplace is the way to go. I freelanced a lot, but I’ll talk about that in a while. I participated in several discussions about the way software is created, maintained and replaced. I spoke in conferences and poked some bears while defending some rather (allegedly) unconventional points of view. I dedicated a lot of time to studying agile methodologies and all that come with it, the whys and hows of software development and mostly: why we do things the way we do them, and why we should change most of them. My point: I learned from all of this.

I see almost everyday on LinkedIn junior developers struggling to find jobs, or people trying to get in the field and having a tough time deciding on how to start, and having had all the experience I mentioned above, I thought I could give my two cents on a couple of things, and maybe help some folks along the way.

But before we dive in, a disclaimer: I, in no way, claim to be the top expert, herald of truth kind of guy that is a know-it-all and whatever I say, goes. These are just my opinions as an individual, in no way related to any of the companies I've been doing business with over the years. These are just opiniated observations based on things I saw over the years. If I say something you don’t agree with, let's talk about it. I actually have a weird taste for people making me change my mind. That means I learned something new.

So, without further ado, let’s talk about 10 things I wish I knew before I started:

1. If you're not a native speaker, like me (English is not my mother tongue), learn English. I won’t even justify this one. You probably already figured that one out. English is the lingua franca of the computing world and there's no way around it. But try and see English as a language (which it is), not only as a tool you’re going to use at your job. Things are going to get easier, and you might end up having some fun while at it.
2. Explore multiple (programming) languages with an open mind: I had a friend who wanted to learn how to create a simple game, so he learned C# to then learn Unity. Solid plan. But eventually he wandered off the game plan (get it?) and decided to learn something closer to data science, like Python and R. Cool. But his mistake was thinking that he’d have to learn it all over again, because he thought C# and Python were two completely different things. So he bought a “python for beginners” course. Granted, those are two different languages, with different use-cases, but the underlying logic is not so different. Looping through a list is pretty much the same thing in Python, C#, Java, Javascript and almost every language out there. The syntax changes, and some languages have unique features, but understanding concepts like syntax and semantics will help you advance much faster in the broader spectrum that is programming than trying to learn a different language from scratch all the time. Fiddle with different languages, find the ones you love and the ones you hate, but understand that, apart from some funky things like Lisp or Elixir, or even the low level stuff like assembly, languages are obviously different, but very much alike.
3. Learn theory. Thinking about object orientation, basic concepts like hierarchy, polimorfism, inheritance and the like won't change from one language to another. You’re obviously using a different syntax when writing an abstract class in Java or in C#, or when dealing with dependency injection, but the concepts are the same. Learn the basics and try to understand how they apply to different languages, and which one works best for what you’re trying to do. Things like SOLID, KISS, DRY also are “commandments” that can be followed regardless of the language you’re writing in.
4. Don’t get married to one language. If you master C# and dotnet, for example, don’t try to solve every problem ahead with it. Consider your options. It may be the case that you’ll have a simple problem that could be easily solved if you wrote a routine in a different language. Every job has its tool. You can always hammer down a nail to a wall with your head, and it’s likely to work, but maybe using a hammer is a better idea.
5. Learn version control (and all things devops). I can't tell how many times I’ve seen great programmers struggle because their version control is fishy. Having a solid way of controlling what comes and goes saves you a lot of time in the long run. Learn Git, from the basics to concepts like rebasing and squashing strategies. Learn how to automate things. If you do a one time thing for a second time, the only thing you can be certain of is that it’s going to happen a third time. Automate what you can, have the machines do the heavy lifting (like linting, deployments, test runs) and focus on more important things.
6. Learn rubber duck debugging. It seems foolish, but trust me, it works.
7. Learn to collaborate remotely (the future is here), pair-program and socialize with your team whenever you can. There are literaly thousands of tools out there to help you with it. Remote is here to stay, and we gotta be prepared to handle whatever curve balls it can throw our way. Professionally and personally, after all, taking care of our psychological well being is also good.
8. Do code reviews. I can’t stress this one enough. I once heard from a manager that code reviews were a waste of time, because why would we have one person stop what they’re doing to look at the work that’s already been completed, when they could be writing more code? Peer review is a great way of leveling the knowledge base of your team and also catching issues while they’re still young. There is a concept called “cost of change curve” that categorically states that, the longer you take to fix something, the more trouble (financial and otherwise) you’re going to have.
9. Write crappy code: Like I did with my dreadful matrix multiplier algorithm back in the day. Go ahead and get your hands dirty. That’s the best, if not the only, way of learning how to write code. Apply concepts that you learn, and refactor often, and don’t be afraid to show your code to other people. Take constructive feedback as a tool to improve, and if somebody gives you a hard time with weird comments like “how come you can’t do this?”, ask them how they learned it and if they could give you any pointers. Showing kindness to aggressive feedback normally has the power of defusing situations in a very effective way. And then, after a while, look at you crappy code and have some fun.
10. Freelance. Put yourself out there. There are tons of people needing help out there, and the work sometimes is easier than what we expect. Pick a skill, like front-end, and look for small jobs that pay you small money. That’s a great way to build up your confidence and catalise your learning process.

And here’s a freebie: know your keyboard shortcuts. Trust me.?

Programming is easy. Programming with elegance and creating software that stands the test of time is something else, and that will only come with practice. Come up with a plan and follow it, but always keep in mind that progress comes with patience and practice.?

What about you? Is there something you wish you knew before you started too? Leave a comment below, or send me an angry private message, I don’t mind.

P.S.: I still haven’t found my document. Please send help.