I started my journey as a software engineer quite some time ago. Beginning sometime around the middle of high school, I had the benefit of knowing for certain what I wanted to do with my professional life. Not everyone is that lucky I guess, but it did give me a good start. I dabbled and experimented a bit with programming, and even took some high school level programming courses.
I then moved on to college to pursue my degree in Computer Science. In the middle of my college adventures, I jumped head first into the professional world. I was ready to take on the world. But I had no idea just how much more I had to learn. It’s been 22 years (rapidly approaching 23 years) since then. I can’t say that I’ve learned everything there is to know. But I have picked up quite a bit along the way, and hope to pick up plenty more in the future.
Below are a handful of things I’ve learned, wisdom I’ve acquired, and advice I’d like to pass on that will take you far if you’re in the midst of a similar journey. This is definitely not an all-inclusive list, or in any particular order. But these are some of the most important things that come to mind as I reflect on the many years I’ve enjoyed as a software engineer so far.
See the Big Picture
I’ve always been good with the details. That’s always come naturally to me. I don’t want to downplay the importance of that; it is certainly important. However, it is equally as important to learn how to see things from a higher level, to see the big picture. This can come in many forms, and it won’t necessarily look the same for everyone. But some common elements include everything from learning to properly plan and design to asking the right questions, and more.
I don’t believe there’s any better way to see the big picture than asking the right questions. You don’t know everything, and usually the customers you work with don’t either. Ask your coworkers questions about the things in front of you. Ask customers about the things they claim to want in order to get to what they need. Customers frequently know what they want, but just as frequently don’t know what they actually need. There is an important distinction here that typically doesn’t line up perfectly.
Learn to plan and estimate well. When you plan something, before any code is written, you will often learn things that are not obvious if you had just started coding. This becomes more and more essential as the size of your task or project grows. Also, don’t make assumptions at the beginning about the size of your project. Think it through and plan it well. Then estimate each piece as if it were its own unique thing, making sure not to under-estimate. No one likes to keep pushing beyond a deadline, so don’t let it happen.
Be Thoughtful in What You Do
Never, ever, jump straight into programming. Give it some thought first, or even some design in the case of your larger tasks and projects. What am I trying to accomplish? What are the potential consequences of the changes? How might this be used, or misused? There are so many questions to ask.
In your designs, plan for the most important pieces of your project, most especially the things that would cost you a lot of time if you had to go back later to make changes. In your planning, make sure you have 100% clear knowledge of what “done” means.
When you are ready to start your coding, just outline it first. Break it down to the unique pieces required, stub it out, writing some skeleton code. After you have enough to get the code flowing (note that I didn’t say working), write your unit tests. Only after all that is done, should you start your coding, filling it all in. Everything you’ve done to this point will allow you to concentrate on each piece individually, one thing at a time.
You can remember all of these things with one simple phrase, “go slow to go fast.” That’s what it all boils down to. With the right thoughtfulness and planning ahead of time, you can eliminate so much rework, thus improving your time to a final product.
Communicate Well
In your work, you will have a variety of different channels and levels of communication. This could range anywhere from the customers you’re working with, to your fellow engineers & developers, to your project managers, and more. Each requires a different style of communication, so understand your audience.
It goes without saying, but I’ll say it anyway; with everyone be open, up front, and honest. Tell them like it is. Say what needs to be said. However, this doesn’t necessarily mean giving every detail. For example, you don’t necessarily want your customers to know when you don’t know something, but instead give them confidence you’ll figure it out. With your coworkers you may have to tell them something they don’t want to hear. Tell them confidently and directly, but with clarity and understanding.
Learn to explain things in simple terms. Learn how to translate technical language into human language. This is especially important with your customers, but also important for your non techie coworkers.
When you’ve got something to offer, speak up when appropriate. Your opinion matters. You were hired for a reason. Offer what you’ve got.
By far, one of the most important times for communication is to reach out when you’ve got questions or are stuck. Don’t allow yourself to spin your wheels too long on something, wasting time. Find that happy medium between the satisfaction of solving something on your own, and reaching out after admitting that you’re stumped.
Maintain visibility and transparency. This applies to you with your team and additionally with your company to your customers. If you don’t know something, speak up. Lean on your team to help you grow. A true team wants everyone to succeed. If you’re behind on something, or need more information, let your project manager and/or customer know (depending on who you report to). Customers typically will appreciate it, and be more forgiving, when they are kept in the loop. It makes it easier to work through a situation, the sooner someone knows about a problem.
Know Who You Are
It’s important to know who you are, what you are capable of, and where your weaknesses lie. Make sure you are working with a team that values your uniqueness and encourages your growth.
Almost everyone goes through some degree of impostor syndrome, especially in the beginning of a new role. You can somewhat look at it like not giving yourself credit for what you know. Be aware of what you actually do and don’t know. Also, as you progress, you will typically find that the more you know, the more you know what you don’t know.
Don’t be afraid to take on some leadership roles. It can help you to identify some of your weaknesses that you may not have otherwise even thought about when you are in charge of leading a team.
Go Head First
Sometimes you need to jump into the deep end to learn to swim. Not many things can teach you faster about something than being forced to quickly learn it. To make full use of this analogy, just make sure you have a lifeguard who can help you keep from drowning if you find yourself to be in over your head.
Remember, as a software engineer your primary job is not to code, it is to solve a problem. Code is just the tool we use in our profession. Maintain an attitude that nothing is impossible; you just haven’t figured it out yet. If you cling to this, you will solve great challenges. Stick with it, and you’ll get it.
Learn How to Fail
Nobody likes to fail. But it happens. So embrace it! Don’t try to avoid it. So many things can be learned only from failure. When you fail, you can easily identify why you failed and have an opportunity to improve. But conversely, when you succeed you may have no idea why you succeeded, preventing any improvement.
I will be the first to admit that some lessons from failure feel painful at the time. But just like when you experience physical growing pains as a child while you’re growing into an adult, failure is a primary source of growth in your career. Learn from mistakes, grow from them, and don’t repeat them.
Learn how to hear and take constructive criticism or feedback. Don’t sweat the small stuff. It’s almost never as bad as it seems.
Also don’t be afraid to try new things, or try things in new ways. This is another potential source for failure. Don’t miss out on the potentially great advancements from taking risks.
Continue to Learn
Make learning a life-long habit. In software engineering, things are constantly and rapidly changing. You will see great benefit from always refining your skill and learning new things. Learn how to learn so you can be good at anything tossed in your direction.
There are so many ways to learn. Read to learn new things. Take classes. Practice your skills alongside others, or in friendly competition with others. Participate in discussions. Find any way you can to refine yourself and keep the learning going.
Another important habit is to log your lessons learned. Keep a journal, write them down, or otherwise document them somehow. This allows you to see where you’ve been and where you’re headed.
Keep Yourself Going
There are going to be days where you’re just not feeling it. Maybe you’re in the middle of a monotonous task, maybe you’re trying to figure something out, or learn something. Never allow yourself to just be staring at the screen. Make sure you have ways to clear your head to keep yourself going.
I have found exercise to be a great tool for this. For me that typically comes in the form of a walk or a run to keep my mind sharp during the day. I have figured out solutions to many issues simply by taking my mind off of the issue for a little bit.
On a side note, on the topic of health, make sure to not sit for extra long periods of time. This is an extreme temptation when sitting down to code something. There are numerous studies out there indicating that it’s not good or healthful for anyone. Take breaks, and at the very least, stand up, stretch, and look away from your screen every now and then.
Another way to keep yourself going, is to allow yourself to “sleep on it.” A big temptation is to sit in front of a screen until you’ve figured out a solution to a problem, or to catch up on something when you’re behind. If you’ve got the energy for that, great. But you could actually be slowing yourself down. When you don’t get rest, your brain becomes fatigued, and mistakes are more frequently made. I can speak from experience that I have figured out solutions to numerous problems as I’m falling asleep, or after waking. Again, the main takeaway here is getting your mind off the problem for a bit. For such situations as this, it is good to keep a notepad nearby your bed so you can document your thoughts and get the rest you need.
In Closing
Hopefully you’ve been able to take something away from this. The 22 years I’ve been a software engineer have been very rewarding, and I hope for many more to come, with continued growth and learning. Did something particularly resonate with you? Do you have nuggets of wisdom you’d like to share? Be sure to let me know in the comments.
