Starting anything can be challenging. Starting out as a new developer is no different—it’s hard. There are endless things to learn and a huge crowd of people who have been in the game longer than you. It doesn’t help that seasoned developers may come off as opinionated, condescending, cynical, and even unwelcoming. The personality of a “typical” developer is for another article, but we’ve all been in a situation where we’ve been left feeling dumb.
Whether you’re a seasoned developer who needs to be reminded to take it easy on the new comers. Or you’re the new person seeking a few pointers or motivation to keep pushing forward. This article aims to remind everyone that none of us are perfect and we all make mistakes.
Not Asking Questions
Easily, the biggest mistake I’ve made and have seen others make is not asking questions. There are many facets to this and the first is making assumptions. We all know what happens when you assume something. There’s a joke about it and it’s funny because it’s true.
In software development, when you assume code was written a certain way—you break something. When you assume requirements for a new feature—you burn cycles writing code that never ships. When you assume QA will surface all of your bugs—you ship a bad user experience.
Don’t assume. Talk to the person who wrote the code you are confused about. Ask your project manager/client clarifying questions. Then, ask yourself: “Did I test every edge case?”
Another facet of not asking questions is the fear of looking dumb. No one likes to pester the team lead and reveal their ignorance or inexperience. You’re trying to impress these people after all, right?
When it comes to asking questions or asking for help, there is indeed a fine line to walk. You can’t ask so many questions that you’re being disruptive or a burden. You need to figure certain things out on your own—it’s what you’re paid to do. But at the same time, you’re part of a team for a reason. No single person knows everything.
If you’re indie or don’t have a team, you still have a vast community in the industry to reach out to. It’s no big secret that developers ask each other questions everyday—just look at the popularity of StackOverflow.com. So don’t beat yourself up. If you’re really stuck and can’t figure something out it’s better to ask a question. Many times you’ll answer your own question by materializing it from an abstract thought into actual words. With that, here’s a tip:
Before you get up and walk over to someone or ping them with a simple “Hey”. Take the time to write out what you are going to ask. I’d bet you’ll find yourself answering your own questions from time to time. This is sometimes referred to as “Rubber Duck Debugging”, see https://rubberduckdebugging.com for more.
Solving The Big Picture
I see this all the time, people will randomly reach out to me on Twitter, Reddit, or other forums and ask for advice on how to approach a problem. I never have time to delve into their project, but I do try to provide quick assistance if possible. A common pattern I have noticed is they are tied up with getting to their end goal. Going from New York to London whilst forgetting about the Atlantic in between (hopefully they’ve at least set out to head East).
Writing software is best accomplished when you isolate small problems and solve them individually. Or as many in the industry word it; separation of concerns. Say you are tasked with writing a shopping checkout experience. Part of that is a credit card field that detects the issuing bank, displays its logo, and pre-validates the user input using the Luhn algorithm.
Don’t start out by building the entire form. Implement the Luhn algorithm as an encapsulated method that reads in a String. Then another method to determine the issuing bank based on a String. Continue to break down your problem into separate components and then piece them together like a carpenter might construct a house.
It’s ridiculously easy to get bogged down and overwhelmed by your project. Take a moment to step back and identify as many modular components as possible and begin building those, one by one.
Giving Bad Estimates
I haven’t done any research on it, but I am confident in saying every single day someone screws up an estimate. Of course, it’s not isolated to software development; there’s nothing particularly unique about software that makes it hard to give estimates. The fact is there are too many unknowns for anyone to give an accurate estimate on anything of substance. No one is good at estimating as far as I’m concerned, but there are definitely unnecessary mistakes made in the process.
As a new developer you are going to feel pressure when asked to give time estimates for a task or project, no matter what. It may be the person asking who is applying the pressure or you’ll unwittingly do it yourself. You will feel like you need to give a number on the spot—don’t do it. The best thing for everyone involved when you’re unsure is to ask clarifying questions and/or request more time before giving an answer. If you’re working with reasonable people, your request for time will be granted and respected.
Step away and take this time to research any new technology involved. Look for red flags in existing code you’ll be working with. Identify edge cases that need to be solved; edge cases are often big—yet necessary—time sinks. Utilize separation of concerns to estimate small pieces at a time, then add them all up. Once you have a clear picture; provide the estimate, along with any caveats you suspect might come up, in a timely manner.
It’s a fine line to walk but you may find under promising and over delivering beneficial. Nothing is more frustrating than a deadline being missed again and again. It is much easier for a business to plan for long estimates than it is when a deadline set from a bad estimate has already been reached.
Not Utilizing Unit Tests
Unit testing is a hot topic, and probably always will be. It’s typically the grand vision of someone on the team to have all projects 100% unit tested. We’re not here to talk about that today. Unit tests are good for your project but they do take time to write and maintain.
What developers should realize about unit testing is that they can be used to save time and frustration. In short, if you’re unfamiliar, a unit test is code that executes other code and checks for expected results. Unit tests typically execute fast and they are easy to run as your code evolves. They do the due diligence of testing the same thing for you, over and over.
Now, there’s a good chance you’re working in a project that doesn’t have unit testing configured. Configuring unit testing for a project can be pretty daunting— so don’t get caught up on that. Rather, start a clean project with unit testing enabled (most IDEs can configure this for you automatically). Working outside the main project is a great way to build isolated components allowing you to practice separation of concerns, as well. Best of all, empty projects are almost always faster to build and run!
Use your unit tests to put your code through the ringer, they only take a few seconds to run unlike tapping through screens yourself. Once your code is working, evolve it by improving its design and readability with the confidence you’re not breaking anything since the tests are there to let you know.
So many more
The list goes on and on, there are an endless number of mistakes both new and seasoned developers make. To rattle off a few more:
- Over engineering (read this)
- Releasing at the end of the week (read this)
- Not using version control (read this)
- Not using issue tracking tools (read this)
- Homegrown “encryption” (read this)
- Overuse of third party libraries/frameworks (read this)
- Naivety surrounding time zones (watch this)
As I said in the beginning, none of us are perfect. It’s all too easy to sit on the sidelines, pointing and laughing at the mistakes of others. We all make mistakes, we all have deadlines that pressure us into taking shortcuts—there are never enough hours in the day. User expectations of software are ever increasing and ironically fellow developers are the worst critics—the ones who know just how difficult it is.
I have a challenge for all of us. The next time you see a mistake or something shortsighted in software you’re using—try reaching out to the developer/company in a non-public way. Whether that is a DM on Twitter or their official feedback form, give them the benefit of the doubt. They may have no idea there’s a bug. Or the decision to do something a certain way was made with information you don’t have over the course of many weeks. There’s of course power in publicly reporting issues, but the tendency seems to be doing so in very negative and hurtful ways. Let’s fix this, let’s show a little more compassion to each other.
