Things I Wish I Knew Starting Out in Tech
Ever felt like you weren't good enough to make it in this industry? Ever felt like everyone else just had it so much more together? This articles for you!
When I first started out in tech, I remember there were so many things that I found scary. Everyone around me seemed to know more than me, I had no idea what I was doing on a daily basis, and I remember feeling overwhelmed every day.
I almost quit being a software developer so many times, in fact I did for a couple years because I had convinced myself I wasn’t technical enough and that I couldn’t hack it as an engineer. I went into product ownership and business analysis, believing that I would never be seen as technical enough in the engineering space.
If I could go back in time, these are the things I wish I could tell myself.
It’s okay to not know
I remember the paralysing fear when I had no idea what I was doing. I’d stare at my screen blank, unsure what my next steps were.
The details on the tickets were non-existent and the acceptance criteria didn’t make any sense. I would give myself such a hard time for not understanding it.
Surely I should know how to do this? Surely these tickets should have the appropriate amount of detail and I’m just not understanding clearly. Surely this is all me.
When you’re in your first one or two jobs, you don’t always know what good looks like, and so this might be a normality for you. It took me a while to realise, maybe it wasn’t me that was the problem, but instead it was the lack of detail and assumptions that others was making about your knowledge.
Realising this was a revelation for me, I no longer blamed myself for not knowing something, and saw that actually it was a miscommunication between me and others. A complete misunderstanding.
In actual fact, there was no possible way I would know some of the things that were in my colleagues brains, a lot of it was domain and context specific or only known because of previous mistakes. This showed me how important it was to add details onto tickets when refining them, it showed me the importance of being as clear as possible to the junior staff on my team.
Not knowing is normal. The more you let your team mates know you don’t understand something, the more you get to pick their brains and knowledge. Make sure you write it down in whichever way you need to so that you can learn it for the future.
Learning gets easier
When I first started learning programming there was so much to remember. When starting my degree and learning about the differences between TCP and UDP, what a REST API and SOAP API were, what was functional programming, what was object-oriented programming, as well as learning three different languages.
There was so much information to learn within three years, and it felt like I was never going learn any of it properly.
But you do learn it, bit by bit you slowly start understanding the foundations more and more, and before you know it you can’t picture a world where you never didn’t understand how dependency injection works.
The beauty of this is that once you learn those fundamental concepts, learning other things does get easier. Now you can take those core concepts you’ve learned and when you pick up a new language, low and behold they pretty much work the exact same way and all you have you really learn is syntax and nuances.
I’m currently learning how to work with Databricks, Jupiter Notebooks and Pyspark, and I’m not going to lie it’s a completely different way of working that I would usually do… But because I already understand how pipelines work, because I already understand SQL, because I already understand python, it makes the whole process of learning something new easier.
Starting small
When you’re starting out it can be tempting to look at professional websites, which are using the latest technologies, various types of caching and complex data querying and you feel like you need to compete with that.
News flash, you won’t.
You see, in order to get to the point where you can design and implement the best systems, you need to be able to start small.
For example, you can first start with building a simple CRUD website.
Learn how to:
build it from scratch
write good tests
connect it to a database
write a separate API
deploy it
And once you can do that, then you can increment on top of that.
What you shouldn’t do is jump straight to the end goal, because that’s going to quickly demotivate you when you’re struggling to get there.
A great analogy I like to think about is my writing and videos, I can see them slowly getting better, but they were awful at the start. They’re still not at the end goal I want them to be at, but I can see visible progress each and every week that I know is getting me closer to the quality I want.
Coding is the same.
Be consistent, iterate and improve.
Everyone’s winging it
I used to think everyone had it together, that I was the only one struggling. I think that’s what drove me to nearly quitting so many times, thinking that it wasn’t a normal feeling.
As my technical skills have developed, I’ve realised that a lot of that is a façade. In fact, when your skills develop you’ll quickly start realising that a lot of comments from other’s are quite surface level, or might be something they have quickly read of the internet and doing your due diligence is key.
This isn’t a bad thing, a big part of this industry is learning new information constantly and keeping up with the latest trends. That means that you have to be able to learn quickly, but it may not always be right, and what others say may not always be right either.
Which leads me to my next point…
Confidence is key
It’s not just about what you say, but about how you say it.
Think about when you’re hearing someone speak, and there’s a lot of ‘umms’ and pauses in what they are saying, are they coming across as sure of what they are saying? I say this as someone who is also terrible at doing this myself and as someone who has been working a lot on trying to improve it.
The reason it makes a difference is because it makes you seem unsure of what you are saying, and if you sound like you don’t believe what you’re saying, then how is anyone else going to believe you?
When I think back to discussions I’ve had with colleagues, the ones who get the most buy in are the ones who can hold what they are saying with conviction and with confidence. They believe in what they are saying and they will say so confidently.
Work on building up your confidence, it will open up so many doors.
Embrace failures
One of the most important things I’ve learned from this industry is that the best way to learn is to fail fast and fail constantly.
I don’t mean fail constantly at the same things, that would be the definition of insanity… But you have to be comfortable constantly trying new things out and a lot of them being failures.
As someone who does a lot of research and development as part of my role, this is something second nature to me now, but there was once a time that I would have really struggled with this.
When first starting out I used to be terrified of failures, I would spend days avoiding pushing my code until it was perfect because I was terrified of it being wrong. I wanted to make sure that it was right on the first try and so I would spend way more hours on it than needed so that it would be ‘faultless’.
I now realise I would have learned more had I pushed my first draft and got instant feedback, I would have learned more from my seniors and I would have spent less time on it.
Now, I often show my code as soon as I have a working copy, or I pair program so others can see what I’m writing, and I learn so much faster, so much quicker. I communicate what I’m doing and I communicate when things aren’t going well either, this allows me to get insights from other members of the team who can give me suggestions on things to try.
Failures make you harder, better, faster stronger.
Failures make you learn next time.
And there you have it!
These are some of the things that I think would have really helped me when starting out.
If you found this useful please don’t forget to give it a like and restack and check the video out here:
Also, here are some of my favourite articles from other top authors that I’ve read this week: