Non-technical skills learned at the 6 Months Mark of my First Software Engineer Role
Take a look at this picture and note what thoughts come to your mind. Are you thinking of the glow at the end of the road? Does it bring you a slight sense of hope for where this car is going? Wondering what’s on the other side of the curve?
For me, this picture sort of represents how I feel about being a software engineer at the moment. There’s been a lot less mystery/confusion than there’s ever been for me, but there’s still an unlimited amount of it ahead of me when it comes to working in my first software engineer role.
It has now been 6 months since I started my first professional software engineering job at a bright Chicago based start up called Home Chef, a meal kit delivery service. So far it has been information overload as everyone warned me it would be before I started, but I’m ever so grateful at where I am with it.
Undoubtedly, I’ve learned plenty of technical based things along the way to grow in the world of software which I’ll cover in some other posts. But in this post, I specifically thought it might be a good idea to reflect back and talk about the non-technical things learned.
I’ve chosen to focus on this topic because I’ve quickly discovered that it’s not just what you code, but how you think before you code that influences what the code looks like and how effective you are at doing it. My hope is that this three pointer list provides some value to those wanting to know what the halfway year mark looks like within the first year on the job from one person’s perspective.
Curiosity is needed to solve problems & expand your knowledge
During my technical interview for this job, I was given the opportunity to pair program with other engineers to work on a real life software ticket. One aspect that made it really tricky is that the part of Home Chef’s codebase we were touching was their giant monolith app. More specifically, it was a Ruby on Rails app with a few hundred models in it. It’s safe to say it was sort of intimidating to me with how to navigate it to only change the code we needed to change.
The way I got through it though was to of course use my knowledge of the fundamentals of how a Rails app itself is structured (MVC), but more importantly it was to ask the interviewers questions on how they’ve organized certain parts of their models.
An example of this would include asking about details on the flow of how the information we are trying to troubleshoot moves through the app currently. Then diving into more specifics like are they using a service file or why/where are they putting helper methods in a certain area. Being curious helped me to ask the right questions so we could run certain things in our Chrome Dev Tools console to get the answers we needed to go in the right direction.
Staying curious with this approach, still helps me to this day on the job because leveraging other people’s historical knowledge on the codebase, or on certain foreign concepts of how Rails/React works, lets me better understand the background of the problem. By doing this, it is easier to find out what actually matters that will lead me to the solution.
If I wasn’t curious to ask more experienced people questions, then I’d have to waste more time setting up the background mentally for myself which would lead to the ticket taking longer to try to complete.
Sometimes though asking questions leads me to explore new parts of our codebase galaxy based on their answers which might have nothing to do with the current ticket I’m working on, but has helped me to complete tickets in the future that become related to the things I was curious about.
Keeping this curiosity mindset alive has helped me to learn quicker on the job for a lot of cases.
At the same time you don’t have to understand everything (and shouldn’t try in some cases)
There’s a balance to everything and on the other side of the spectrum, if one gets too curious on the job, it can cause them to be overwhelmed in a not helpful way. Especially this becomes true if they bite off more than they can chew with the amount of tasks in the beginning.
This is exactly what happened to me in the beginning of this role. I felt that I had to learn everything at lightning speed and get it all right the first time or else I wouldn’t be able to contribute enough.
This way of thinking just isn’t true though. I’ve learned you need to give yourself grace for working with production code that can be super complex compared to coding exercises from school or some less complex projects you’ve built.
Think about it this way, if finding a solution to the ticket you’re dealing with required 6/10 possible concepts within the codebase to be understood and the last 4 require twice as much brain power. You, being the ambitious/curious coder you are, try to understand everything. Then what do you think will happen?
I can only speak for myself here, but it ends up with a really big unnecessary headache where you only have so much depth in what’s going on and you only remember so much details at the end of that ticket.
Instead what’s more effective to become better is to:
1. Identify what’s critical information to comprehend as you go through your thought process
1a. Maybe take the time to understand one more non-required point if you have time
2. Then write down those other things you want to understand and come back to them later if you have a less busier day. Or sometimes the even better thing to do is to be on the lookout for tickets in the future that will require you to know these things later on.
I’ve come to see for myself that time, as long as you are trying your personal best to learn as quickly as possible, really will work its magic in giving you skill.
When you’re less intimidated by the code, it’s easier to put your mental energy into comprehending it
The last point I want to touch on is the fact that coding is difficult by nature. Even if it is a high level language (a programming language that reads closer to English than others), it really is writing in the language of how a computer “thinks” and requires a lot of brainpower to change or add the right lines to get you what you want.
With this being true, I’ve learned to just constantly remind and admit to myself that coding is not supposed to be easy and that anything worthwhile requires steady efforts over a long period of time. It seems obvious, but sometimes the overwhelmed side of myself would get the best of me where doing this was needed.
When I tell myself this it helps me to have realistic expectations to be challenged which leads me to be less intimidated by whatever piece of work I need to complete. It gives me more energy to actually put it towards solving the problem instead. Thinking like so has always lead me to better results in terms of how much I learn, completion time, and how I feel about my technical skills.
On the other hand, if I expect something to be really hard to do and don’t do what I’ve just described, then I’ve now hyped myself up and have to waste energy on keeping the mental part of myself grounded when doing the technical planning in the beginning for my approach.
Having faith that the right solution is out there and that the right resources will help makes the difference.
Wrapping things up
These are only a few things I’ve learned out of many when navigating through such an awesome, yet sometimes complicated role. Software and building websites requires dealing with a lot of ambiguity/mystery and being okay with not having all the answers.
Throughout it all though it has been really awesome to be able to work with such a challenging, yet innovative and supportive company with some wonderful and talented senior software engineers who I aspire to be like constantly. They’ve been a key influence in teaching me, sometimes indirectly, how to think because like I mentioned how you think influences how you code.
If you’re starting your first software position I hope this inspires you to put your all into the first few months of you well earned career. And if you’re a more senior software engineer, maybe having read all this has brought back some bittersweet memories. Kind of like enjoying key lime pie
