One of the more common things I hear from intern developers, and have experienced myself, is being afraid to push code.
There are a lot of reasons new developers are scared to share their code. Some haven’t deployed before, some don’t want to make a mistake around their new colleagues, and some feel like they don’t know enough. As a result, they question their code.
Most of the things I use day-to-day as a developer I’ve learned from jumping into a project and trying to do something new. Occasionally it works immediately, but usually, I’ll make mistakes and have to fix them.
Why are new developers afraid of pushing code?
Some are worried of looking like they:
- don’t know what they’re doing
- are not solving the problem
- are not providing value to the team
A lot of these feelings can be summed up by Imposter Syndrome — where people aren’t able to accept their ability and are constantly afraid of being discovered as a “fraud”.
It’s easy to feel like this as a junior developer; you get things wrong, you don’t know as much as the more experienced developers, and the top developers you know often make you question your own ability.
I’ve worked in another company, have been doing freelance work for the last year, and I was still scared when pushing code during my first few days in MiniCorp. Luckily, we’ve got a great review process — someone looks over your work, then you ship it.
My advice to new developers
- Ask questions if you’re stuck. You’ll learn faster, waste less time, and ship more often.
- Don’t try to perfect something before being sure it’s going to work. It’s better to tinker, find out it doesn’t work, and move on than spend a lot of time making it seemingly perfect to find out it doesn’t work.
- If you’re jumping into a new project and aren’t sure how it’s setup/works, ask someone who worked on it, it can save a lot of puzzling down the road.
- Commit often, push your code, learn from your mistakes.
Don’t be afraid to break things. Or be afraid and do it anyway. You’ll learn from your mistakes and become more comfortable as a developer the more you fix them. I break things daily; the key is to learn from it and use that going forward.
I’ve learned more about building software from breaking things than two years studying computer science.
The real value in breaking things is that you have to fix them. To do that, you need to understand:
- Why what you did was wrong
- What you need to do to make it work
If you apply those two things to every mistake, you’ll quickly become a better developer.