loading...
Cover image for Dear new (and not so new) developers

Dear new (and not so new) developers

eruizdechavez profile image Erick Ruiz de Chavez (he/him) ・5 min read

Photo by Annie Spratt on Unsplash

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 15 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-of 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 a 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 15 years of professional experience. To summarize:

  • Ask good questions
  • Read the official documentation
  • Divide your problems in smaller ones
  • Isolate your problems to remove external actors

If you made it all the way here, I owe you a big thank you. Thank you for reading all these, I honestly and from the bottom of my hearth hope these words take you as far as they have taken me today. See you in the #help and in the interwebs!

Posted on by:

eruizdechavez profile

Erick Ruiz de Chavez (he/him)

@eruizdechavez

Web Developer, Podcaster, Pragmatist, Minimalist.

Discussion

markdown guide
 

As a fellow 15-years xp comrade, I can only fully agree to all you admirably said!

The main skills you learn with more xp are not technical skills, it's just learning to deal more easily with problems.

Keep learning all along your career, get out of your comfort zone whenever you have time or interest in new techs/soft skills.

Stay humble and keep on learning!

(Oh and impostor syndrome never disappear, you just learn to deal with it ;) )

 

Totally keep humble and learn to deal with the impostor syndrome specially when you are on shower thinking that you worth nothing.

Great mention of Unix phillosophy and I want to add something: When you learn something, please help one who has struggle with it.

Very nice post man

 

Great idea! I'll keep it in mind for my next post whenever I get the inspiration to write it.

Thanks for taking the time to read it and for the nice comments!

 

Howdy comrade, thanks for your comments!

And yes, I definitely agree with that last point (dealing with impostor syndrome).

 

Understanding the problem, and the technology you're using, becomes particularly important when it comes to troubleshooting. If you don't have a basic understanding of how things work, you're basically reduced to what I've come to call 'diagnosis by random guess'. If you've got an understanding of how the tech you're dealing with works, you can use that knowledge to narrow down the likely problem area.

Unfortunately, you'll sometimes find yourself under a manager who doesn't have the detailed knowledge you have, but wants to push out a quick fix. This typically leads to a rapid barrage of 'diagnosis by random guess', which may keep you so busy checking out the guesses that you can't actually think about the problem. Sometimes he actually manages to stumble across the real problem. Other times, he's just delaying the chance to actually think about the problem.