These sort of lists seem to be very popular —and some are actually quite good!—, so I figured I would add my own two cents. Without further ado:

1. Don’t use your colleagues as a replacement for effort

Learning when to ask your colleagues versus trying something out yourself is a skill you will have to learn. I think most of us, depending on the environment, our upbringing, and our natural inclinations, have a predisposition towards asking too much or not enough.

Too often I see people asking questions to other colleagues, only to watch these other colleagues open up Google/documentation, searching for the answer and forwarding it to them. This is a terribly inefficient use of everyone’s time.

On the other side, in most organisations (and this starts happening at a much earlier time than one might expect) there is some internal or ‘tacit knowledge ’ that you will not find, no matter how much you search. Some of it you may be able to figure out yourself from first principles or trial and error, and this can be a great learning opportunity, but for the most part you will need other people to guide you through it.

Find out when to ask and when to try is key, and the sooner you start practising the earlier you will figure it out.

Another thing I would suggest: as a general rule you should strive to only ask a question once. By which I mean that it’s on you to remember the answer. Or, because we’re humans and we forget, to figure out a way to retain the information. Get better at searching for things in Slack, start a personal wiki/pkm system /notebook, improve your company’s documentation…

2. Don’t use Google/LLMs as a replacement for understanding

Search engines and AIs are wonderful, but you need to make sure you are the one using the tool, and never the other way around. There is a lot of knowledge to be learned from StackOverflow, random blog posts and Large Language Models. But I have seen people using it as a replacement for actual learning and understanding why you are doing something. We all copy code from other people, but it is imperative to understand it first.

3. Learn your fundamentals

By fundamentals I refer to the underlying set of theory and technology that underpines the rest of your knowledge. For example, having a good understanding of the shell, bash and Docker will instantly ground your CI pipeline knowledge. This marks the difference between understanding what you’re doing and copy-pasting examples from all over the place in the hope that something will work.

There are fundamentals to all we do, and nobody will ever get all the way to the floor. This is to say, there are diminishing returns to focusing on fundamental skills instead of directly applicable things, but in my experience most people lack the former. You will likely produce better code after getting a vague understanding of CPU caching, but having deep understanding of the electronics that make it possible is not going to make much of a difference.

4. Learn your tools

In a similar way, there are a number of tools you use in order to get work done. For most programmers, the obvious one will be your editor. There is really no good excuse for not learning how to use it better.

Sadly, a lot of this knowledge is hard to get, there aren’t that many resources on how to use your editor to its fullest extent. The basic way to go about it is to play around with the menus and settings of any tool you use. Log in to the AWS Console and start clicking around until you get ‘Access denied’, for example. Go through the menus of your editor. Become proficient in your tools of work.

5. Bite more than you can chew

The easiest way to learn —and learning is your priority as a junior engineer— is to do. A lot of companies will cuddle you with trainings, constant pair programming, and other security measures. Perhaps controversially, I believe you should resist that. Take on something that is just a bit out of your skill level.

The first issue with that is you may not know enough to know what your skill level is. And you almost certainly won’t know enough to know what skill level most open tasks at your company require. The great thing is, as a junior, you’re expected not to know. If you aim too high someone will let you know. And if you can’t quite crack it, you can show someone what you have so far and (1) they will likely be impressed (2) they will point you in the right direction from there.

Ambition pays.

6. Just ask

I was at a conference at some point, listening in to a executive leadership coach talking to some people after his session. He was surprised at how often people kept asking him things they should be asking their colleagues. “How can I know if my 1-2-1s are productive?” “How about you ask the people you’re having 1-2-1s with?”

Here are some that you might run into at some point:

  • Am I making good progress in my development?
  • Is this ticket a good fit for me to tackle by myself?
  • Should I be working on something specific?
  • How does this even work?
  • What did he just spend the last 30 minutes talking about?
  • …

All those are things you can just ask. Your team lead, your colleagues, anyone. People will not be offended. They will find some time to answer.

7. Stay open

Learn within your company, but try to keep up with what is happening elsewhere. Some of it will make you a better engineer. Some of it will teach you things you wouldn’t have learned at your current company. This is actually good for your company, as you could bring some fresh ideas and best practices to improve current processes. But it’s also good for you: this type of knowledge could get you hired to a better position elsewhere. So never stop learning!

Here are a couple of resources to get you started: