I've been in tech long enough to have made most of the avoidable mistakes and to have watched other people make them too. What follows is not motivational. It is specific. These are the things I would tell myself if I could go back to the beginning of my career with what I know now.

The first thing: your job title is not your career. The instinct early in a career is to optimise for the title on the business card — to get to "senior" as fast as possible, to accumulate the credentials that signal progress. This instinct is understandable and mostly counterproductive.

What actually determines your career trajectory is the quality and variety of problems you've been responsible for solving, and the depth of understanding you developed in solving them. A junior engineer who spent three years genuinely owning hard problems — being the person accountable for production incidents, for architectural decisions that mattered, for features that real users depended on — is a fundamentally different professional from one who spent three years executing well-specified tickets. The title might be the same. The capability is not.

Seek out responsibility early, even when it's uncomfortable. The discomfort is the learning.

The second thing: learn to write clearly before you worry about presenting well. There is enormous emphasis in tech career advice on communication skills, and most of it points at presenting — public speaking, demos, stakeholder presentations. These matter. But they are built on a foundation of written clarity that most advice ignores.

The ability to write a clear, concise technical document — a design proposal, a postmortem, an architecture decision record — is used every day in a way that presentation skills are not. And the discipline of writing forces a clarity of thinking that no other medium demands in the same way. If you cannot explain a technical decision in writing without ambiguity, you do not fully understand the decision yet.

Write more. Write things nobody asked you to write. Write postmortems for incidents even when you weren't required to. Write down what you learned from every hard problem. The habit pays off in ways that compound.

The third thing: the size of your team and the scale of your infrastructure matter for your development in ways that are hard to replicate through learning alone.

There are things about how software systems behave at scale that you cannot learn from tutorials, courses, or personal projects. You can only learn them by being responsible for systems that are actually at scale — where the failure modes are real, the consequences are real, and the pressure to understand and fix things quickly is real.

This is not an argument against learning through courses and projects — those are valuable and often the right starting point. It is an argument for being deliberate about where you work and what problems you're exposed to. The engineer who spent two years at a startup with real users and real infrastructure at a meaningful scale has learned things that are hard to get any other way.

The fourth thing - and this is the one I most wish I'd understood earlier - is that your network is not built by networking. It is built by doing good work in public, helping people generously and without expectation of return, and showing up consistently in the communities where the people you want to know are already gathered.

The transactional approach to networking - meeting people because you want something from them - produces shallow connections that don't compound. The generous approach - being genuinely useful to people, sharing what you know, engaging seriously with other people's work - produces the kind of relationships that result in opportunities finding you rather than you chasing them.

Start contributing. Start sharing. Start being useful to people who are where you want to be. The returns are slow and then they are not slow at all.

visit - vector skill academy for more