DEV Community

Faith
Faith

Posted on

Six things I’ve learned in my first year as a Software Developer

Originally posted on Medium in March 2020

In July 2019, I took a leap of faith (no pun intended) and changed career, industry, and location to become a Software Developer. I had been working as a Data Analyst in the Civil Service for a couple of years and had felt like I needed more of an intellectual challenge: a job that would engage me more and provide me with a greater sense of purpose.

This potentially life-changing decision was made after amassing a grand total of six months of coding experience — yet I haven’t looked back. This article serves as a reflection of the things I’ve learnt about software development, about learning, and about myself as I approach my first anniversary as a Software Developer.

A picture of the author

1) An engineering journal is a beginner’s best friend

Author’s engineering journal template

My engineering journal is essentially an electronic notepad where I do three main things on a daily basis. Firstly, I document all my achievements, big or small, such as solving a complex bug, completing a tutorial, asking a pertinent question, making a new connection at work. I also write down all the new things that I learnt that day including any questions that I asked my colleagues and Google. Lastly, I write down a to-do list.

As simple as it is, taking the time to consolidate my thoughts at the end of the day is really therapeutic. I get to convert my written rushed scrawls into meaningful notes and also get to close down all my open StackOverflow tabs(!) Writing in my engineering journal has meant that my learning process has become more intentional and less ad hoc, and it also allows me to shut off from work at the end of the day without taking any stress home with me. You just have to remind yourself to make time for it. I try and complete mine in the last 30 minutes of the day, or first thing the next morning if I’ve been super busy.

Using applications like Notion or Bear means that you can create sophisticated journals that can be searched, and sorted allowing it to become a valuable resource that can be continually built upon. It’s sooooo much better than flicking back and forth through my written notepad trying to find where I jotted down a certain piece of info that I vaguely remember noting down a few weeks ago!

2) Ask questions, and then ask some more!

Question Mark Meme

As I don’t have a traditional tech background — everything is new to me. Although I’m distinctly aware of the cliched ‘there are no stupid questions’ and people always like to say ‘ask as many questions as you want’: so often I feel like I have too many questions. Like I’m a nagging child constantly asking ‘but whyyy?’

But do ask them. Ask Google, ask your peer, ask yourself, ask a senior colleague.

Ultimately tech is made by people, people who bring their own experiences and learnings to the codebase. And what I’ve realised is that the majority of my questions largely revolve around ‘why has this part of the codebase been written like that?’ or ‘why is this process like this?’. At the start of my developer journey I used to accept the codebase as the gospel, but it wasn’t until I started verbalising my questions that one of two things occurred. Either a more senior developer would end up pointing me in the direction of a new concept/syntax/technique (yay for expanding my learning), or there would be no real answer other than ‘it just works’.

Whilst the latter seems unhelpful, it has given me a lot of opportunity to improve the codebases I work on when I’ve identified that what’s currently there doesn’t read well, could be more efficient, or otherwise improved upon. It also reassures me that other developers are often winging it, just like I am, and keeps the imposter syndrome monster at bay.

So, ask your questions. If something is unclear there usually means that there’s an opportunity for improvement in your learning and if not, then an opportunity for improvement in the codebase, in the documentation, or even in your team’s working practices. Just make sure you write down the questions you ask and their answers in your engineering journals!

3) Sometimes you just need to work with where you’re at

As a developer you’re always learning regardless of how many years you’ve been in the industry and I learnt pretty early on to let go of mastering everything. It’s impossible — the technology and goalposts are ALWAYS changing. Yet there is still a burning urge inside of me to get better and to progress. But it is exhausting.

Instead I’m striving towards a healthy balance between learning brand new concepts and consolidating the knowledge that I already have. I’ve realised that I gain as much, if not more, by slowing the pace and choosing to build my confidence with my current knowledge rather than jumping from one new thing to the next. I’ve also learnt the art of judging whether some concepts are beyond my comprehension at this current point in time.

Focusing on all that I don’t know is overwhelming. However, focusing on what I do know and building from there is much more manageable and retainable.

4) The EUREKA moments occur when you take a break from your laptop

Picture this: you have been working on a new feature in a project for a day or two, it’s all slowly and gloriously coming together…except this one tiny thing that just won’t work. You try x and you try y, you try debugging, console logging, commenting out parts of the code. Still nothing. Hours go by. Then, for me at least, there comes the point where I eventually give up — I go to the gym, I go and lie down, I go and hunt down some comfort food.

This is a fairly typical scenario for me. And it’s always in these breaks, when I’m minding my business, avoiding coding thoughts, that my sub-conscience will bubble up with a solution.

And so now, I’m trying to be more mindful about taking breaks, as tempting as continuously hacking away at the code is. Just looking away from my laptop for five minutes to stare into space, or going to fill up my water bottle or any other seemingly mindless activity, has been a surprisingly productive discovery. Who knew my tendency to daydream could be so helpful?

Next time you’re stuck on something, instead of grinding away at it non-stop, try walking away and thinking about something random or even not thinking for 10 minutes or more. Return to your machine when you’re at peace and trust me you’ll have a new sense of clarity!

5) Don’t attribute your worth to your technical ability (or lack thereof)

I’m fortunate enough to have always been a high-achiever, from school, to university, and in my early career. Along the way that ‘achievement’ wove its way into my sense of identity. And honestly there’s nothing like joining a completely new industry where I have very little (technical) expertise to blow that sense of identity out of the water!

This year I’ve had to re-evaluate and reflect on what ‘success’ looks like for me and what value I bring, in a world where technically my skills are minimal. That starts with understanding that the role of a Software Developer is much more than just coding.

Insecure Growth Meme

Sure, I can’t write 30 lines of JavaScript without my trusty friend Google but there’s a lot more that I bring to the table. Some of these are personal attributes — I’m super curious, I am tenacious, I pay attention to the details. And some of these are core skills I’ve honed whilst not being in the tech industry like being able to explain something clearly to different audiences, context-switching whilst working on multiple projects at once, building relationships, conflict resolution and so on.

If you’re new to software development like I was and struggling to find your place in a team where it seems like everyone knows what they’re doing, take a step back and trust that you’re there for a reason. Assess your skills more holistically and find opportunities to display them. Maybe you create excellent documentation, or you may be a STEM ambassador, or have fun ways to run meetings, there will definitely be something!

6) Talking to others gives you a better perspective of your journey

It’s so easy to fall down a rabbit hole as a new developer, or even more broadly, as a beginner in anything. You focus on your progress or perceived lack of it, you work hard and push yourself, and it becomes easy to focus on how much further you have to go rather than how far you’ve come. As simple as it is, talking and listening to others in a similar boat can put everything into perspective.

My developer journey first began in an evening course full of women who were all mostly new to tech. This was then followed by me starting on a Graduate Scheme with another cohort of people with similar-ish skill levels. So, I’m lucky that I do have groups of people who are largely going through the same experiences that I am. We can go for lunch and natter and be reassured that we are all doing just fine, or if something seems off my colleagues can chip in with what their experiences have been and I can course correct.

If these resources aren’t available to you, I’ve also joined more technology Meetup groups than I can name. I couldn’t recommend them enough, particularly if you are from an underrepresented group in tech. They tend to be free or at the very least affordable, with food(!) and the opportunity to meet others, be pointed in the direction of new resources, and see the career paths and decisions that others have chosen.

If you have a daunting fear of networking, don’t be put off, you can still gain insight and perspective by simply turning up and listening to the panellists, or by making small talk with just one new person. Following developers of a similar skill level on Twitter or finding online communities is also a great way to get an understanding of the achievements and troubles that others have, which can help put yours into perspective.


It’s almost been a year since I career-switched into Tech and I definitely feel like I made the right decision. It’s challenging, the learning is endless, and I’m constantly building things to destroy them and re-build them again, but that’s the fun of it! I have a job where I get to problem solve all day and I feel very fulfilled doing so.

Top comments (5)

Collapse
 
juanfrank77 profile image
Juan F Gonzalez

Great post. Thanks for sharing your learnings.

Collapse
 
mccurcio profile image
Matt Curcio

Nice article!
How did you make the switch so quickly? Do you already have a CS background?
It would be nice to hear more about your journey. ;)

Collapse
 
faithege profile image
Faith

Thank you!! I don't have a Computer Science background - I was pretty fortunate to do a bootcamp with an organisation that was hiring, so I was able to get a job upon bootcamp completion.

Collapse
 
jerneu profile image
Jeremy Neumann

Do you have recommendations on how to keep a journal? Examples of templates that keep your notes organized and on track? Or, examples of others?

Thanks

Collapse
 
faithege profile image
Faith

The example of what I used isshared in the blogpost as a screenshot - it's nothing complicated - my achievements, learnings, questions asked, and todos