Since humanity created the concept of time, we’ve been fascinated with the idea of time travel. While I have mulled over the idea of returning to the past to offer advice to ‘younger me,‘ Marty McFly taught me in Back to the Future that going back in time can actually threaten your existence. That’s just more reason to take my advice here.
I’ve been a software developer for 15 years, and the learning curve has sometimes been steep. I’m currently a technical lead of a small development team, which entails breaking down, estimating, and prioritizing tasks. I’m also responsible for verifying that our technical approach is sound.
There have been growing pains along the way: uncommunicated expectations, technical hurdles, things lost in translation, and thoughts left unsaid. While it’s probably a good thing time travel isn’t a reality, if I could go back, here are five pieces of advice I’d give myself as a young software developer.
1. It’s okay to say, “I don’t know.”
Everyone wants to look like they know everything. It’s nice to be the person who has the answer to every question, especially in front of a boss, client, or potential client. But no one knows everything.
There will come a point in your career when someone asks questions you don’t know the answer to. It can be tempting to fudge the truth and maintain your know-it-all persona, but that’ll set you up for failure later.
It’s okay to say you don’t know and need to do some research before answering. Giving the wrong answer is always worse than admitting that you need more research, learning, and investigation.
2. Over-communicate.
Communication is hard—really hard. What you think you’re saying is sometimes different from what others think you said. Assumptions, biases, lack of context, and bad call connections can all lead to our message not reaching the audience as we imagine.
When pressure is on, and stress is high, it’s easy to assume too much when conveying information. Pressure and high-stress situations are exactly when you can’t afford to have things ‘lost in translation.’
No one enjoys dealing with software problems, whether they involve bugs, uncompleted features, unexpected behavior, or crashes. Many times, though, the root of these issues is poor communication. Unclarified requirements, expectations, and delivery timelines can all cause problems. The first step in debugging a reported problem is understanding exactly how it was being used and what the expected behavior was.
Before diving into a technical solution to a problem, make sure you understand the root cause. Was it poor communication with the user? Poorly understood requirements? What other parts of the application might also be affected similarly?
Take notes, repeat what you understand, and communicate early and often to help avoid misunderstandings. Ask whoever you’re communicating with to echo what they heard. Many software issues are not due to bad code but bad communication.
3. Document everything you can.
There’s nothing worse than getting on a project with little to no documentation. While you’re early in your career, make it a habit to document everything you can. Your future self and fellow developers will thank you.
Proper documentation can speed up the onboarding process and save time by allowing new project members to read a comprehensive overview rather than grilling you with questions.
There’s only so much room in your brain, and your current work will likely be at the forefront. Documentation on the ‘whys‘ behind choices helps retail intuitional knowledge and provides a refresh on the details when you need to revisit.
Plus, over time, you will get old and struggle to retain information quite as easily as you used to. (Trust me on this one.)
4. Don’t be afraid to dive into a new tech stack.
There are so many technologies, frameworks, and libraries out there that it’s impossible to know them all. Sometimes, clients hear the buzz of some new technology and have to have it. Other times, they’re anchored in some older frameworks you haven’t messed with.
It can be very tempting to stick to what you have experience with, but sometimes, another technology fits the project’s needs better (even if those needs aren’t technological.)
Working on or with a new technology can be intimidating, but it’s just another problem to solve. Learning another technology stack makes for a more well-rounded developer and can shed more insight into how you approach technologies you’ve used before. There is no better way to expand your skills than by tackling a real problem. So, communicate this is a new tech stack for you, fire up a tutorial, and dive right in!
5. Never stop growing.
In addition to learning new technologies, always strive to grow as a developer, especially outside of technology. Working with colleagues, mentoring young developers, and helping solve big problems for clients are all areas of practice that provide you much room to grow.
Every day is also an opportunity to expand your skills to provide a better experience for your clients. Taking clients from tech-frustrated to tech-enabled is the heart of software development. Constantly sharpening your interpersonal skills goes a long way.
Parting Thoughts
Reflecting on my first few years as a developer, I now have a completely different and much more varied skill set than I did then.
While I don’t have a Delorean to go back and give myself advice, I do have my experience. By sharing, I hope to help younger developers avoid some of the learning pitfalls I encountered and encourage them to expand their skills.
-
Chad Kuboviak
