Dear new (and not so new) developers

#programming #tipsandtricks

I understand not everyone has or will have the privileges of good mentors, internet access, or even knowing how to read and understand English, but for those who have them, is that I want to share these bites of wisdom that have helped me advance my career over 17 years now.

Let me give you a bit of context about me. I graduated from CS 15 years ago, in a small university at my home town (Puebla, Mexico); and paid most of it by working in a small computer repair store near my home. Most of what I know today I either learned it from great mentors I have had over the years, because of someone answering my question in some form of online platform, or self thought.

When you start learning something, a programming language, a library you want to use, heck, even a new code editor, you will have that feeling of uncertainty and that is OK, do not run away from it, embrace it. If you know how to channel this feeling into questions and searches, you will go far. There is nothing more exciting and intimidating that start a new project, in an empty folder, with an empty file; so many possibilities but where and how do I start?

You do not have to define a bullet-proof, future-proof architecture from day 1, that is impossible. Yes, there are many companies out there with great ideas, but those ideas that worked for them will not necessarily work for you; even those big companies change direction 180º every so often, so why should you not? Just follow the Unix philosophy, take a big problem and break it in small manageable problems, solve those small problems, and eventually your big problem won’t be so big, and will be simple to solve.

Do you want to build a web site from scratch? There is absolutely no need to start with Docker on day one. You don’t need Webpack to start your project. Don’t waste your time thinking if TailwindCSS or Redux are your best options. Start small, start with a plain HTML file and as you progress you will eventually find what you need and what you don’t.

Asking a question is hard, asking good question is even harder

At some point you will find a blocker. Not a small one, a big one. One of those that stop your progress for hours, or even days. But there is nothing to fear about it. It is ok to not know the answer to your problem. It is ok even to not understand your problem. We are not geniuses (at least I am not) so stop thinking you have to know everything. You don’t. One of the best skills you will learn and master over the years is how to ask a good question, and not just to your friends or coworkers, but also to one of the many search engines out there.

You might be tempted to just copy and paste your errors in the search engine, or dump a big chunk of code on a forum or chat window and wait for someone to magically understand it, fix it, and send it back to you. I can tell you this might work one or two times, but it will eventually wear-off and those who were willing to help you will start ignoring you. Instead, follow again the Unix philosophy, start breaking your problem in smaller ones. Remove complexities, remove unnecessary details until you end up with the bare minimum, and then give it a try one more time.

Having issues fixing or adding a new style to an existing element in a webpage? Remove all styles from the element and try to get yours working. Something in your JavaScript code not working? Isolating the problem by doing something similar in a blank playground works wonders, be it a CodePen, or just a new HTML and JS file on your computer. If after isolating it you still can’t figure out what the problem is, then you have a good, clean example to ask (politely) someone else.

If your problem or your question is too generic, or on the contrary, too specific, be prepared to answer some questions you will get back to you. A good way to know if you are headed on the right direction to receive help is if the person who is helping you is asking you things, context is everything! If they are just throwing random “solutions” at you, most of the time is someone who only cares about “giving an answer” first, not actually solving your problem. Our problems are many times as unique as we are, so trying to solve someone’s problem requires most times a good chunk of time and a conversation to fully understand what you need to do and why.

Understand your problem, understand your solution

In cases where you feel in a rush or specially when starting with new projects or technologies you might be tempted to ask for a how-to or tutorial, more so if you feel like you are running in circles or you are running out of time, but believe me, a tutorial or a how-to will hurt you more than it will help you. Why? Because a tutorial or a how-to is tailored to a very specific use case, with a very specific goal in mind. Stop rushing yourself and start reading more. I know, not all projects have great documentation, but it will pay forward to read the official documentation to understand what you are doing instead of just blindly following someone’s “Ho to build a To Do with X and Y” guide. Don’t get me wrong, this is not a RTFM, you do not need to read the whole thing from back to back, but at the very least take the time to read and understand the functionality you are trying to use.

If you get some generic advice or links instead of a tutorial teaching you exactly what you are doing, give that person an honest Thank You and take the time to read whatever was shared with you. That person wants you to learn by giving you the right direction instead of just spitting out the first thing that crossed their mind that may or may not work at all for you.

Do not ask someone to solve your problem, ask them to explain you what you do not understand and point you in the right direction so you can solve your problem yourself.

This was slightly longer than I anticipated, but believe me, I have been there more than a handful of times in my 17 years of professional experience. To summarize: