This isn’t for developers that have been in the industry for a long time, it’s for the junior that has just started and is feeling overwhelmed by the work or by the amount they need to know.
Mindset, it’s the most important thing
A lot of people will say “Keep learning, never stop” and that is true. But it doesn’t take into account the person behind it. If you don’t enjoy what you do, you’re not going to want to learn more and improve as much as possible. So look at the context. Find something that resonates with you, either in your own projects or in a company whose product you think you’d have the most enjoyment improving.
Managing yourself on projects
This is where planning comes in, now I don’t mean planning the project (that should already be done). Planning what you’re personally doing on the project is incredibly important. If there’s something you’ve never done before or a language you’ve never used before, find resources to learn from before the project starts. If you’re using a GCP product, read through the docs beforehand and build a small POC, not really for the project, but for yourself.
Test twice, code once.
When you're working in a team, other people are often going to need to add to your code. If the person working with your code isn't entirely familiar with it then any changes they make might unknowingly bring about bugs. Building unit tests into your system or application means that it can be edited by someone else and any changes they make that cause bugs will be picked up as soon as possible.
READ THE DAMN DOCS!
Reading the docs is getting the information straight from the horse's mouth. It’s all fun and games getting an obscure solution from StackOverflow, but the answers to most of your problems are usually in the docs. Rather do things the right way and give the docs a thorough read when you're using a new framework or application.
Reinventing the wheel
Building your own algorithm may be fun, but it’s also incredibly time-consuming. A lot of the time just finding a library that does it for you is a much more efficient way to get the job done - not to mention the time taken unit testing your new piece of code.
Asking questions
Before you ask the questions, do the research first, try to find the answer yourself. Most questions can be answered with a simple Google search.
But don’t waste your time. When your code breaks, a good rule of thumb is to try and find the problem yourself for the first hour. Then ask your senior, not for the answer, but for a line of thinking that could lead you to the problem, try for another hour, rinse and repeat a couple times.
If you can’t find a solution after that. You’ve either managed to find a problem that hasn't been solved yet - or your senior is messing with you.
Overconfidence
Just this.
Impostor syndrome
This one is more difficult. We’re surrounded by amazing people and technologies, from amazing AI that can beat a human in DOTA to the extraordinary tech behind Google BigQuery. It’s sometimes hard to feel like you’re good enough. Below is a quick discussion I had with Dan, one of the lead developers I go to when a problem has me stumped.
Me:
“How often do you Google really simple things?
Dan:
“I mean, I've probably run the tar zcf x.tar.gz directory command about 5000 times ...I Googled it this morning to make sure I got the flags right
Me:
“Do you mind if I just quote you verbatim with that one?”
Dan:
“Just let me check I got the flags right”
Probably the most important thing to learn though is to not be afraid to ask questions, give feedback or get involved in the broader dev community. If you have a question, whether it's about a career in dev or just a problem in your code, we've got a whole team who would be happy to help - reach out and drop us a message!
