Unbelievably, it’s been six months since I started my first professional role in software development. It’s been incredible, and while some days I don’t think I’ve learned anything, there are definitely a few small lessons I’ve picked up along the way.
I work for a really large organisation, but I think most things in here are common experiences in smaller companies, startups, and even freelancing. Not everything in this list will apply to everyone, but these are the things I think of daily in my tech journey.
You will spend weeks, if not months, understanding a codebase. And that’s okay.
My colleagues and I, CS degree or not, are all in unanimous agreement that the hardest part of your first development job (or any new job, really) is feeling at home in the code. Our project at work involves nearly 400 files. I spent the first three months of my job writing very few lines of code and instead drawing a lot of diagrams.
It’s easy to worry that you’re not contributing or bringing value, but this is valuable learning time in the long-term. The more time you spend understanding a project’s design patterns and structure, the more productive you’ll be later down the line.
It’s okay to neglect your side projects.
Some people are really motivated and energised by their first role in tech. Personally, I found myself so exhausted that the last thing I wanted to do when I got home was to code or study more.
It can seem a little strange transitioning away from a bootcamp or self-taught lifestyle where you’re building projects daily or weekly. It might feel as if you’re not learning or contributing to your Github as much. All of that is perfectly normal. Take time to celebrate the wins you’re having at work, and don’t worry so much about the Github contribution grid or your portfolio. The energy will return, I promise.
Don’t underestimate your “softer” skills.
There is power in them, trust me. I vividly remember attending a UX meet up where many of the designers and researchers there had negative experiences with trying to talk to developers. And while I was sitting there thinking “Surely we’re not so different, are we?”, I realised the problem was one of communication. I’m sure there are misconceptions of each others personalities and roles on both sides, but communication, empathy and good listening skills are crucial to being part of a successful technology team. So it’s important to work at it.
The stereotype of the anti-social hacker is a misleading one. In most modern workplaces, you will have to liaise with fellow developers, product owners, management and designers. Try your best not to be that developer that people are afraid to approach to ask a question.
I’ve learned the most useful everyday skill is being able to explain my code in everyday language, even if I’m talking to fellow developers who uare familiar with the tech stack. We all code so differently that it can take a minute to understand what someone has written, even if it’s something as generic as parsing JSON. It saves so much time if you’re able to simplify your code through talking through it concisely.
Your value is in the different perspective that you bring. Take risks. Be vocal.
Say what you see. All the time. It could be a as simple as a line of code you think isn’t right, or a feature that hasn’t been thought through. It could also be something about company culture. You’re an individual with opinions and perspectives. Don’t repress them just because you think “that’s the way things are done around here.”
Also, an important side note: be vocal with positivity. If someone has done a good job, mention it to them. Development can be stressful and isolating. It’s nice to hear a compliment sometimes.
You don’t have to go it alone. Find your community.
This might seem a cliched piece of advice, bit I have to remind myself of it often.
There will come a point where you might think you shouldn’t need to ask for help; that you should be able to figure things out on your own. From experience, that’s the ideal time to ask. Nobody was born with programming skills. Take advantage of your colleagues’ experiences and knowledge to learn and develop.
There’s a less technical side to this too. I work, as many women (and particularly women of colour) do, in a very white, male office. Many of the men in my office went to the same universities and came up through the same graduate programme. I felt work was a pretty isolating place to work as a woman from the other side of the world, no matter how great my colleagues were at trying to make me feel included.
I’m lucky enough to work in the same office as two other amazing women who have similar non-technical backgrounds to mine. But I also found reaching out to vibrant, passionate online tech communities to be really rewarding. Sites like Tech Ladies, Elpha, Twitter and Dev.to have made me feel less isolated as a junior in the industry and in the company I’m in. Now at work, I’ve started sharing ideas and perspectives I’ve picked up online. it’s a small shift to company culture, but it’s a shift nonetheless.
If you’re in the unfortunate position at work where you lack a sense of community, take your search online. There’s plenty of connections and inspiration to be found.
Empathy isn’t requirement for the job, but you need to be able to listen to what your user wants.
There has been a lot of great things said recently on the value of empathy in tech. But it’s unrealistic to expect everyone who codes to have an innate ability to empathise with an end user they will very rarely interact with, if they even do at all.
The world of software development has become so big now that there are a plethora of different careers in UX alone. So it can be a daunting subject to broach if you’ve never really considered design your thing. It might seem easier to pass off a problem to a dedicated UX professional, but there are many small decisions to make on a day-to-day basis that have a direct effect on your users’ experience. There really is no way to get around the fact you have to know your end user well. At the very least, every development change you implement should start with “why?”
Work slow.
The greatest aspect to being a developer is that you’ll never be bored. There are an endless stream of new languages, frameworks and job titles for you to get stuck into. In my experience, this is also the most overwhelming part of being a developer. It makes me want to rush everything. It’s easy to think you have to know it all right now — or at least know way more than you do — to get ahead.
When I first started learning JavaScript for my role, I wanted to get through the fundamentals as quickly as possibly so I could start working on meaningful contributions to the project. I learned the hard lesson that I should have slowed down. This goes for your first bug fixes too. Don’t worry about the pace your colleagues are moving at. Focus on your own journey. If you only fix one small bug in a day, but you’ve taken the time to understand what went wrong and why, rather than seeking a quick fix, you’ll be a better developer because of it.
Prioritise sleep and regular breaks over coffee.
We all turn coffee into code, and that’s cool. But it’s not a replacement for taking care of yourself.
Regular breaks can be whatever you want them to be — not everyone loves a break every 90 minutes. If you’re someone who gets deep into the code for eight hours, that’s great! But make sure you’re putting a big chunk of your day aside to get away from the screen.
And honestly, get those eight hours. Your mind will be so much sharper for it.
Remember, the possibilities are endless.
You’ve got your foot in the door of a huge, exciting industry. Don’t be afraid to explore it. Take every opportunity you can to learn and grow. Just because you’re a frontend developer, it doesn’t mean you shouldn’t explore customer data or UX design or information architecture.
You’re not limited to the role you have, but you’re also not limited to the company or the clients you work for. The tech community is huge and the opportunities to have your voice heard are everywhere. Get amongst it.
Write down your motivation for becoming a developer. Refer to it when you’re having a bad day.
Most of us got here because we’re motivated, and that motivation will really help you out of a rough spot. There are so many days when I’ve felt useless, but been reenergised by remembering that someone like me could see my journey and think “hey, I can do that, too.”
