My Journey In Tech

Why and how I transitioned into Tech (UI/UX design) and what I’ve learned in 10 years.

I've been in the tech industry for almost 10 years. My path toward becoming an engineer was unconventional from the typical CS path. When I started my journey, I was a college student pursuing graphic design. Prior to that, I had been a henna artist and aspiring artist. My knowledge of coding had been limited growing up, mainly involving CSS to customize my Myspace profile (does that date me a bit?). So while in college, learning to code was an investment to be a better designer, wanting to understand the limitations and possibilities of web technology at the time.

That investment quickly became a passion—I switched my major, spent my free time learning code, helping my peers, and took every opportunity to learn and build. I worked on personal, freelance projects and internships to build my portfolio. Within a couple of years, I found myself in my first full-time development role. Since then I've worked across multiple companies, from small agencies to mid-size corporations of various industries and projects. The last two years have been spent as a Senior Software Engineer at Echobind, a digital agency dedicated to providing bold, beautiful, and bulletproof web and mobile solutions for our clients.

With this experience, I’ve learned some valuable lessons that not only helped me become a better engineer but also kept me interested in this industry, and put me on a career path I never expected years ago. Here are some of the things I’ve learned over time:

There is No Linear Path

To start, there’s no linear path toward growth. It’s not as much of a shock or stigma now, but back when I discovered coding as a career path, boot camps had just started to take root and I was fortunate to be one of the early adopters of online learning. This path enabled me to become a software engineer and showed me that success didn’t have to be achieved one way. Over time, I’ve only seen the field become more diverse, with many engineers with non-traditional backgrounds who are changing the development landscape. Like my own path, seeing the success of others has continued to shape my thinking that embracing unconventional can sometimes lead to the best opportunities toward growth and success, and we want to foster that the best we can.

Stay curious and ask questions

There is no amount of experience to negate the need to ask questions. In fact, asking questions is often the best channel for communication and learning, whether it’s how a feature or a piece of code works, or how another developer would approach a problem. Even as a senior engineer, I’m often curious about how others solve problems or implement code because there is always something new to learn or better approaches than my own, and a significant resource to learn is those around you. There are countless examples I’ve come across in my career, but one that comes to mind was when first learning about using object literal lookups instead of switch statements. This was all because of asking a coworker how they would approach returning from functions based on a value with many possibilities. It was a game changer for me and really reinforced how important asking others can be because the best ideas often come from others. There’s a time and place, but you’re only limiting yourself and your growth if you think you have to solve it all.

Know your audience

At some point in your career, you’ll realize the importance of communicating to different audiences—beyond the diagrams and tech jargon. At one of my previous jobs, I worked closely with our UX designer prototyping a sharing feature for a healthcare mobile app. Alongside them, we discussed the flow of authorization to allow a user to share their information with other users. At one point, they had a bewildered look on their face trying to understand what it would take to implement this, in both design and code. The UX lead stopped us and asked us to explain this in another way. Knowing they were lost, we restarted the conversation by finding the right way to help bridge the gap.

One of the engineers in this scenario kept trying to bridge the gap with more tech jargon and traditional whiteboarding. But it was only causing more confusion. Realizing this person was a visual person and needed a relatable example, we switched gears. In this case, we found an analogy (ironically Starwars) that ended up working perfectly to explain the transactions that needed to take place for our sharing service to work. We cemented it further by sketching this transaction on the whiteboard. It may have not been a perfect example, but it was enough to get the point across. The point of the story is, that sometimes flowcharts or tech terms are not enough, and you will need the right soft skills to play to your audience.

Code for your future self and others

It’s bound to happen in your career (more often than you’d like) that you’ll run into code that is cryptic or overly complicated with no documentation of what it’s doing and the steps to get there. Often times code was written this way out of laziness, to appear intelligent or to try to solve it all with little attention to future-proofing. Without proper documentation, likely those who work on it will struggle to understand what or why it was implemented, or the learning curve will be too steep without the original author to explain. This will lead to headaches and complications. So do yourself and others a favor, and code for readability with:

• Reusable code, but when it makes sense the most sense. Avoid overly generic functions that leave the question of what are we getting or expecting. Each function or variable name should represent the result of the code or the value it holds.
• Break code down into digestible pieces. If your functions are handling multiple tasks, ask yourself if it’s possible to break it down so that it’s easier to understand.
• Code with a natural flow in mind. If the code seems like magic or isn’t clear how things are interacting, it is an enemy, not a friend.
• Leave the code in a better place. If you run into code that could be optimized, do so if you have the time.
• Write comments when needed. While function/variable naming should be sufficient to describe what should be expected, comments will still help to describe the inner workings of a function. Documenting what the function does can provide better context for a named function or variable, especially if there is insider knowledge to some handlings within the function.
• Write for diversity. Everyone has different learning styles, if you can try to approach your code and your PRs with this mindset, it will be beneficial to your team.

Fighting burnout, knowing your limits, and learning to honor your boundaries.

It’s possible that at some point in your career you’ll experience fatigue or developer burnout. Coding is taxing on the brain, but there are so many external factors that can cause a breaking point if not mitigated or managed. I’ve suffered through bouts of burnout multiple times in my career during various projects, teams, etc. Even in my engineering role at Echobind, I’ve experienced burnout on client projects I’ve worked on as I’ve lost interest in the things that use to motivate me. As someone who has lived through seasons of anxiety and depression, I’ve become practiced to recognize and prioritize fighting burnout.

It’s important to recognize when it happens, know and honor your limits, and proactively make changes or seek resources to help reduce or eliminate the burn. Some changes can include:

• Prioritize physical and mental boundaries
• Seek out things you do care about inside and outside work
• Surround yourself with those who inspire and have your back
• Be transparent about needs and seek help
• Find opportunities to have fun, be creative, and give back
• Prioritize rest, vacations, and even breaks

While there is a very valid nuclear option (aka quitting your job), it’s best to analyze if there’s no other recourse before seeking this one out. Developer burnout is nothing to be ashamed of, and there are resources and communities out there to help you prevent, fight, and thrive.

Lastly, pursue your purpose and find opportunities that will support it

I’ll be honest, I have struggled with my path as an engineer over time. When I first started my career, I was very passionate about learning, building, and creating. It fulfilled many aspects of the things I craved and found fulfillment in. I have worked on many projects and with some fun technologies. Over time I found my motivations for being an engineer shifted, and I began to question if this was still the right path for me. Turns out it is, but I had to make a change to support the things I cared about—mentorship, community, and supporting others toward their success.

It’s incredibly important to find and foster the things that really matter to you to continue in this (and any) industry, and be okay acknowledging when those things have changed. If you’re struggling to find fulfillment in your work, take the time to start asking yourself what really matters to you, what opportunities (whether at your company or community) are available to support them, and what’s holding you back from pursuing them. Sometimes this will lead to a direct shift in your career, sometimes it will lead to fostering it elsewhere. Regardless of how it directs you, you will need to be ready to embrace it when it happens because it may be the best thing you can do for yourself (and others).