7 ways to improve as a software developer

I was going to title this post “How to improve as a Junior Software Developer”. But after writing a few of them I release I could be better at following them myself…

So instead I’ve broadened this article for all developers. New, experienced, and old. Regardless of how long you’ve been doing it, it’s important to reflect on where you are and how you can improve. Continuous improvement is practiced by all good software developers.

These are my tips on how to improve as a software developer.

1) Learn to deal with frustration

As a software developer, you must prepare for frustration.

There are a lot of things that can cause it: poor documentation, slow builds, confusing error messages, changing requirements, package version mismatches…. the list goes on.

Fighting against frustration is pointless. It will burn you out and make you hate your job.

It’s a never-ending cycle if you let frustration take over you.

Frustration inhibits your problem-solving skills. So if you let a problem frustrate you you’re less likely to solve it. Which will only increase your frustration. And on and on the cycle goes.

So please, for your own happiness and mental health - learn how to deal with frustration.

Getting frustrated with your computer

Don’t let this be you

2) Read error messages

It’s amazing how often this catches me out.

I’m coding away and making great progress. Run the app to check my changes. Boom random exception. Take a look back at my code to see if I’ve missed anything obvious. Nope can’t see anything. Run the app again. Same exception. Copy the exception title into Google. Start reading through blogs, Stackoverflow, and Github issues. 40 minutes pass of trying different recommendations. Nothing seems to work. Run the app again. Same exception. Actually, open and read the thing properly this time… Ahhh. It says exactly what the problem is inside the exception. Fix the problem in 10 seconds.

Story sound familiar?

Actually take time to read error messages.

Reading exception messages

Take your time when reading errors

3) One story at a time

We like to write code. Writing code makes us feel productive.

There’s no better feeling than smashing through a couple of bugs in quick succession.

The problem is there’s a lot of stuff in between. We have to wait for builds, QA, and deployment. Stuff that’s out of our hands.

It’s very tempting to start the next story and get coding again while you’re waiting.

But things get out of hand quickly when we have multiple stories on the go. Keeping track of deployments becomes difficult. Especially when changes are needed after things go through QA.

It’s boring waiting for stuff out of your control. But getting a story completed and deployed is better than half finishing multiple stories.

So instead of picking up the next thing when you’re waiting. Make some coffee and read some articles instead.

One at a time please

4) Discuss ideas and approaches early

Having ideas is amazing.

Taking a problem and thinking of a solution is what makes software development so much fun. But there is a wrong way to have and implement ideas that we need to be careful of. Here’s the classic story:

A member of the team has an idea and becomes super focused on implementation. You don’t hear from them for a while while they’re building. Eventually, they come back and you discuss what they’re working on. With your knowledge in the area, you spot a flaw in their approach. It’s going to ruin the whole idea. Explaining the flaw is difficult. It’s difficult for them because they’ve spent so much time on the idea. It’s difficult for you because you don’t want to break their heart.

Two brains really are better than one.

It doesn’t matter if you’re the most experienced developer in the whole company. You should still brainstorm your ideas and approaches with other devs.

As a human, we will always miss stuff. We need other humans whose brains are wired differently to spot the stuff we miss. It will save so much time in the long run.

But it’s difficult…

I think everyone has already heard this advice. So why don’t we follow it? I think there are two reasons:

Credit - We want credit and praise for our ideas. There’s nothing wrong with that. But it leads to being reclusive with our ideas until we can implement and show them off.

Rejection - Opening up our ideas for debate can hurt. We don’t do a good job of separating our ideas from ourselves. So when we open them up for critique it feels like an insult to us.

I don’t know how to get past these feelings but it’s important that we do.

5) Ask Google before a teammate

This one contradicts the previous tip a little bit…

As we’ve just discussed in the previous tip, communication is so important.

But it can get out of hand.

Asking questions about every small error and how to do the most minor things becomes too much.

That’s what Google is for.

Google will give you the answer quickly and won’t take your teammates out of their flow.

It’s good to ask questions but relying too much on other people will limit your own progress. Reading error messages and official documentation develops your problem-solving skills.

Use teammates as sounding boards for ideas and advice, not like Google.

Google has a lot of information

6) Don’t get bogged down in patterns and principles

Many developers, especially new developers, overemphasize the importance of design patterns.

There’s a feeling of imposter syndrome if you don’t know many design patterns. It’s even worse when other developers use patterns are a way of gatekeeping.

It’s completely unnecessary.

As long as you have good problem-solving skills you will be able to write any type of application. As long as you write clean testable code it will be extensible for the future. You don’t need patterns to achieve these things.

Patterns are overrated anyway…

A lot of the time following a pattern to make code super extensible means writing five times as much code. Which makes you question if it was worth it?

One rule will help you better than any pattern: keep it simple.

7) Don’t measure others with your own yardstick

Every team member in your team has different domain experience and technical abilities.

.We’ve all solved different problems throughout our careers.

What seems simple and straightforward to you might seem completely bewildering to someone else.

It can be frustrating to see things done differently from how you envisioned them. Or when you have to explain things that seem simple to you.

But it’s unfair to criticize others based on your own experiences.

It’s not their fault if a teammate isn’t able to solve a problem to your level of standards. They implement things that they don’t know about.

It’s better to be inclusive and helpful. It’s not productive to shoot down the work they have done. Instead, try explaining the approach you would have taken so they can learn for next time.