I don’t know about most freshly graduated computer science majors, bright-eyed, hoping to build amazing software that impacts people. Leaving school, I didn’t know what actual software development was like: the ceremonies, the process, the tech/infrastructure considerations, how to deploy, etc. I was thrown into an ocean of software terminology, practices, and concepts I didn’t even know existed, let alone how to use them.
Now you might be asking, “Pavan, why are you telling us about your bad start as a software engineer?” I am so glad you asked. I am telling you this because I know I’m definitely not the only one who struggled a bit to get my bearings and plant my feet on solid ground starting out. I am telling you this so that you will take to heart what I am going to talk about, which are the skills that saved me as a junior that I still use to this day.
These are the skills that most juniors learn that can be a little uncomfortable to use, but they are paramount for building a solid foundation in the field. Now, some might think that things you did as a junior, you stop doing as you become more senior. I am saying that, if anything, you should get more comfortable with them. If you develop these skills to fit your current experience level, as you grow, they will help you continue to grow and develop consistently.
Ask questions.
This first skill might seem like a no-brainer; asking questions is basic, and we should all do it. I agree, but I have seen some developers shy away from asking questions as they become more experienced for a variety of reasons. In my case, I thought I should already be able to handle these problems without running into issues. I should be able to figure out the problem or at least get close. This brought me back to being a junior when I would waste time before asking a question that would have saved everyone some time.
Today, I can’t just go to a senior member on the team and ask,”Can you explain this function to me?” Now, what I do is gather as much information as I can about it. What happened when I ran it? What went wrong? Which steps have I tried in the process of understanding a function or solving the problem? And, what were those results? What are my assumptions? After I’ve compiled all that information, I present it to my teammate, who then knows exactly what I do and don’t know. They can then fill in the gaps.
An example of this might look like this: “I am running into issues with this API endpoint in our application. I thought it should return the info about this activity, but I am not getting anything back. Then, I tried checking the logs, but couldn’t find anything specific to it. I tried running the API locally and logging that, but the logs never showed up. I have been using a postman to test all this. What am I overlooking?”
Now, I have clearly stated my situation, what I think should be happening, and what I have tried to understand it, with any relevant details. I’ve also asked a clear question about what would help me progress. That was a rough example, and screenshots and less vague language would help. But you get the idea. That information gives the teammate you’re asking the context they need to quickly and accurately answer the question, saving both parties time.
Assume you know nothing.
Alright, this sounds extreme, but bear with me. As a junior, there’s a good chance that you won’t have the first clue about what you are looking at. As you gain more experience, you will recognize patterns and commonly used logic and won’t need to spend as much time going through lines of code to understand what is happening. This is incredibly useful and a good skill to have, but you know what they say about assuming.
Whenever tackling a new bug, take the mindset that you don’t know what is happening and take a bit of a closer look at what is going on. Console log all the things, set all the breakpoints. Test every assumption you have because not every function and code block is the same. And, even similar code might have wildly different outputs. Now, to be clear, I am not saying I go meticulously through every line of a function or user path. But, if I am even a little uncertain about what is happening, I note the spot and add a traceability log there showing me what I need to know.
Then, after adding everything that will tell me what I need to know, I’ll run the function and compare what I think with what’s actually happening. Usually, I’ll also find what is going wrong that causes the bug and can implement a fix to solve the issue. This can be a double-edged sword for things you are mostly familiar with. It’s not that huge an effort, but the less familiar you are, the more effort and time it will take. That is when you might want to consider reaching out to a teammate with more knowledge who can tell you what a function is doing.
Just break it.
Again, I know it sounds extreme, but sometimes the only way to solve a problem is to do just that. Try a solution, see what happens, analyze, regroup, and try again. It’s definitely a brute force method, but a lot of the time, simple and straightforward is the best solution. Like Thomas Edison once said, “I have not failed. I have found 10,000 ways that don’t work.” Eventually, you’ll find the way that works.
Today, I am more methodical in my failure. I am looking for specific things, getting the info about what was failing and what data was there when it failed, and at which step. Failing with purpose can lead to the perfect solution that solves the problem. As a bonus, it usually helps you gain a deeper understanding of how the code you are breaking works, which will make future tasks much easier to complete.
Bow to the duck.
This might be the most powerful skill/practice I have ever used and will continue to use. Rubber Duck Debugging.
Laugh all you want, but there is some mysterious power that comes from explaining how your code works to an inanimate rubber duck that gives clarity and insight you wouldn’t have otherwise realized. I am sure there are many a developer/engineer that can think of a frustrating moment they just sat in front of a rubber duck and talked out the process of what they are doing. Then, as if struck by divine inspiration, they realize exactly what they were missing and how to fix it or account for it.
All jokes aside, talking out loud the sequence of how a function should work will help you quickly identify what you are missing, what doesn’t make sense, or what is getting in the way. We spend so much time in our heads thinking that it gets pretty tangled up in there, like that scene from “A Beautiful Mind” or Charlie from “It’s Always Sunny”. Talking it out and hearing it clears up the clutter and lines it all up. You don’t have to use a duck. It can be any inanimate object that will not interrupt you. If you really want to get wild, ask your co-worker/teammate to listen to your ramblings and see what they think.
Skills That Stand the Test of Time
These skills are some of the most common I have seen new devs/engineers pick up that help them level themselves up quickly. They are incredibly helpful and when used appropriately can be helpful long into your career. And now with AI tools can be done more quickly, or more intricately depending on what you are doing. These are skills that I plan to hold onto and utilize long into the future and I think you should too. Now go grab that duck.