These are the things I wish someone had told me when I started in IT.

Not tools. Not languages. The things that actually changed how I work and how my career progressed.

Code is only a small part of the job

Code is a small part of the job. A surprisingly small part.

You will spend most of your time understanding how things fit together. Reading diagrams. Talking to stakeholders. Figuring out what people actually mean when they describe a requirement, and what matters more to them: style or function.

You will run into project managers who do not understand technical constraints, architects who design systems without fully understanding the technologies, and requirements that do not make sense as written.

At the same time, you need to support those same people. You need to help shape decisions, not just push back on them.

Systems are often built quickly. Getting the design right is what takes time.

Focus on the fundamentals

This is one thing I got right early.

I focused on fundamentals that apply across languages and frameworks. How databases work. How memory works. How systems are structured.

While everything around me was chasing the next big thing, I focused on what did not change.

That paid off later. Once you understand the underlying concepts, learning a new language is not starting from zero.

A list is a list. An array is an array. They may look similar, but they behave differently. Once you understand why, adapting becomes much easier.

Do not ignore fads completely

This is something I got wrong.

I ignored JavaScript completely for a long time. I did not see the point. It felt messy and constantly changing.

But if something is moving that fast and getting that much attention, it is probably not going away.

You do not need to chase every new framework. But you should at least understand the basics of what is happening and why.

If I had spent more time on JavaScript basics earlier, picking up the frameworks that actually lasted would have been much easier.

Do not be afraid to branch out

Do not stay only in your lane.

Your job becomes much easier if you understand how other roles think. Product owners, scrum masters, analysts, managers. They all operate under different constraints.

If you understand those constraints, you will spend less time being frustrated and more time working with them. You do not need to go to the extremes like I did. My resume ended up looking like I was trying everything, which helped in some ways but also made things harder at times.

It also helps you communicate better. You stop arguing past people and start solving the same problem.

Be honest

Do not position yourself as something you are not.

That does not mean saying "I cannot do this". It means saying "I have not done this before, but I can figure it out".

This sets expectations correctly and gives you room to learn.

I have been in situations where I said yes to something I could not deliver, thinking I could work my way through it. That did not work.

What would have worked is flagging it early.

Problems raised three months before a deadline can be managed. Problems raised three days before cannot.

Be ambitious

You will run into things you have never seen before. Step up when that happens.

If your fundamentals are solid, you can get further than you think.

Even if you only get part of the way there, that is still progress. The next time, you will get further. This is how I ended up being able to pick up anything from Engineering to Management.

Most growth comes from taking on things you are not fully ready for.

Be nice to recruiters

If the recruiter has done their homework, and you would be a good fit but you're not insterested in swapping jobs.

Be respectful, say thank you - they are giving you a compliment with reaching out. If you know someone else that might fit the bill (and is looking for a job), reach out to that person and connect them.

You don't have to do their job for them, but if you can help them, when you need them - they will help you.

Enjoy your free time

It is easy to spend all your time on code. Especially early on.

Do not.

At some point you will get tired of it. When that happens, it helps to have something else to switch to. I did not do this early on, and it eventually pushed me to step away from the field for a while.

Find something that has nothing to do with computers. Exercise. Cooking. Music. Anything.

You will come back to work with more energy, and you are less likely to burn out.

Most systems are simpler than they look

The first time I encountered the Joomla framework, I was taken aback thinking this was my Everest.

I took my time, read the documentation, and started experimenting. All of a sudden I understood it. If you learn the logic, things will fall into place.

Something that is extremely powerful for this that exists now is LLMs, they are extraordinarily good in summing up documentation, and help you get to a working example.

You are paid to solve problems, not create software

Any system you will ever work on is there to solve someone's problem. No one will hire you to do exactly what you want and when you want to. I can tell you I did not want to build most of the systems I worked on, but the end result was cooler than I thought.

Keeping this in mind, it becomes easier to stay on target and bite through things. Even if you think that "you're not doing anything valuable" - it is very valuable to someone.

Learn Debugging strategies

Here I do not mean "learn how to press F5 and add breakpoints". But learn a way for you to strategically hone in on the problem and avoid red herrings.

I cannot state how many times I said a silent thank you to the University Lecturer that taught me how to approach debugging with a strategy at hand. This is one area where a good mentor can make a big difference.

You will never know everything

You will continue to learn during your entire career. One thing that I would heavily recommend is finding a mentor (formal or informal), it doesn't have to be another engineer.

A good mentor is about the personal match and what you can learn together. They might not know your favourite framework, but they will have seen many frameworks rise and fall, and can help you think through problems differently.

A good mentor is worth their weight in RAM.

Also if you get the chance to, make sure that you act as a mentor to someone. You will learn more by teaching than you will ever learn from a book.