Edmunds Innovation & Technology Culture

What technical skills do you consider to be the most essential to your success as a full-stack developer?

Understanding how HTML, CSS, JavaScript, back-end systems and different persistence options work together to deliver an application is the foundation for any full-stack developer. But without a doubt, one of the most essential skills is the ability to read and trace through code. Traditionally, front-end developers do this in the browser and back-end developers do this in their tooling, but being a successful full-stack developer means your tracing doesn’t stop where your expertise ends. 

Different projects will use different technologies. You can always learn new languages, frameworks and technologies, but if you are not afraid of tracing through code to understand what is happening at each level, you will find success regardless of the technology.

What’s a soft skill that you also consider critical for your success? 

There’s an old proverb: “Curiosity killed the cat, but satisfaction brought it back.” My morbid curiosity has led me down many holes but the satisfaction gained when things click and I understand how something functions makes it worthwhile. This desire to understand how and why things work and can be improved has led to my professional growth.

Curiosity alone didn’t get me this far. Humility has been just as important. I am never the smartest person in a room, even when I’m by myself, so seeking feedback and mentorship from others to fill in knowledge gaps or bounce ideas around has contributed to my success. Sometimes a different perspective is all that is needed to change something from good to great.

Describe the product or feature you worked on. What does it do, and what was your role in creating it?

Given the sheer volume of data and the essential need for a seamless customer experience, we’ve initiated a project aimed at achieving a tenfold improvement in our operational performance. The core objective is to reduce the data updating time frame from months to days. 

This project will ensure the timely availability of up-to-date and standardized vehicle information, despite the varied nomenclature used by different manufacturers. 

In this project, my role is primarily that of a strategic leader, or what we call a technology and product sponsor. I am responsible for defining the project vision. This involves setting a clear direction for the project, outlining what we hope to achieve in the form of measurable success metrics, articulating how our efforts will contribute to Edmunds’ broader objectives and laying down software architecture and guidelines for the project. These guidelines help maintain consistency in our technological and operational approaches, ensure that we adhere to best practices and guide our team in making decisions that align with our project vision and objectives.

What was the most exciting or interesting aspect of working on this product or feature?

One of the most exhilarating aspects of working on this project was undoubtedly tackling the sheer magnitude of the desired improvement. The team experimented with open-source solutions, vendor integrations and innovative cloud-native machine-learning solutions. We were attempting to streamline the process of standardizing diverse data formats and terminologies across various vehicle features. As you can imagine, the myriad of terms used by different manufacturers could easily confuse any customer.

The team’s adoption of new technologies and willingness to embrace change and learn continuously was truly inspiring. This project was not just about achieving business impact or improving operational performance; it was also about growth, learning and pushing our boundaries, which made the experience truly enriching and exciting.

The incremental value added with technology experimentation has reduced the effort for some of the team’s most complex tasks from 220 hours to under 30 hours. We are entering the next exciting phase, and with the recent advancements in large language models, we can accurately categorize and standardize the terminology for several features.

How did your engineering team culture support the successful creation of this new product or feature? 

Our engineering team’s culture has been instrumental in the successful creation of this new product feature. Rooted in autonomy, learning from failures, rapid iteration, collaboration, ownership and continuous learning, our culture has shaped our approach to problem-solving and innovation.

The response to a challenge we faced during the first implementation phase highlighted our culture in action. We incorporated a vendor solution into our architecture but soon identified that it created a maintenance overhead that wouldn’t scale as needed for our project. The autonomy our team enjoys led to a proactive search for alternatives. The decoupled architecture of our system supported this exploration. A “battle-hardened” framework used by another department was identified as a promising replacement for the vendor solution. 

This example highlights the culture of reuse and cross-departmental collaboration that we nurture and emphasizes the power of a supportive and dynamic team culture. It’s not just about our technology or tools but about how we work together, take ownership, learn from failures and help each other grow. That’s the real driving force behind our success.

Describe one of the principles that differentiates your unique approach to engineering.

I always take the lifecycle of the code I write into account, balancing between writing minimalistic, clean code and code that’s readable and easily maintainable by others in the future. 

For example, I align with the tried-and-true engineering advice to balance my “Don’t repeat yourself” programming tendencies with the concept, “Avoid hasty abstractions.” I’ve been embracing this principle since the start of my career, and with our companywide focus on code quality as well as my organic interest in this topic as a part of my professional development, I’ve been able to polish and instill it as an effective habit in my day-to-day life. 

What differences did you notice after you adopted this new principle in your work? 

I initially struggled to effectively apply my principle to balance throughput and quality for building and reviewing clean, abstracted code that’s easily maintainable for business and engineering practices on the team. 

I started off by spending a disproportionate amount of time focusing on code quality beyond what’s necessary, which slowed throughput. However, now that the principle has been put into practice more effectively due to my new habit, I’ve obtained much more of that balance. 

For example, I now weigh the relative business priorities and deadlines of a given task against the significance of potential optimization opportunities I may want to apply and present. If the significance is relatively minimal but the business need is much more urgent, I’ve learned to relegate it as a technical debt item. In return, my team and I hold regular technical debt meetings to review and prioritize such work to keep it reasonably managed and addressed in a timely manner. 

Ultimately, I’ve noticed positive differences in both the feedback I’m getting from my engineering managers, product owners and peers as well as from our flourishing product evolution and quality. 

What does this approach to engineering help you and your team accomplish?

It gives us the flexibility to reduce technical debt without jeopardizing our velocity and launch targets. It also helps avoid overengineering and unnecessary launch delays. 

Moreover, I’ve found that some of the other engineers on my team share my desire to emphasize code quality while also experiencing similar challenges with overengineering and potentially reduced throughput. Through my learnings and establishing this new habit, I’ve encouraged other engineers to adopt the same balanced principle and participate in the practice, thus benefiting our entire team.