Search for a command to run...
Eddie's mission is to increase joy and empathy within the tech industry. He does this through engineering leadership, mentoring, and podcasting. He works as an Engineering Manager @ Glassdoor, Mentors on ADPList, and Hosts the WebJoy Podcast.
No comments yet. Be the first to comment.
In this series, I talk about all the missing skills and mindsets of successful software engineers so that you can get to the next level!
Things have been pretty busy, and I want to sit back down and write some more posts soon. But in the mean time, I wanted to share some exciting news about one reason I’ve been so busy! I’ve been working with Maven, a company that specializes in live ...
So here’s the thing, no matter how you learned software development, either in a degree program, through self-reaching, or by using a bootcamp-style program; one big risk is that what you learned yesterday isn’t necessarily going to help you tomorrow...
The problem In my current role, we build internal libraries for use by our front-end developers. For a new library we're building we needed to do something I hadn't ever done before. Our library is in TypeScript and we wanted to provide IDE suggestio...
I spent a large chunk of my career making the worst mistake for career development: I didn’t have a plan. A lot of people have a plan for their life. Being a software engineer wasn’t the clear plan for me for a long time. Programming started as a ho...
Every software engineer has that moment.
You are assigned a feature requirement. It could be a Jira ticket or a sticky note. You first start brainstorming if this is possible, how you would achieve it, and how much time it might take.
But before you start thinking through the technical implementation, you need to step back and ask "why"?
Often by nature, there are some technical assumptions built into a requirements ticket.
However, those writing software requirements sometimes don't clearly understand what is and isn't possible. There may be a better solution that is either faster or more user-friendly that has not been thought of or assumed to be impossible. As the software engineer building the feature, understanding why a requirement exists allows you to validate that the best solution (given all the variables) is being selected.
As a software engineer, you are the technical subject matter expert (yes, even if you're new).
Even if the requirements you're given are correct, there are many assumptions you may make based on what is or isn't listed in the ticket.
It is so important to never make an assumption. Assumptions lead to faulty technical decision-making. This feature may be a stop-gap and will need to change in 6 months. You save yourself and your company time by asking questions and unlocking those things that other stakeholders may not think to volunteer. This complete understanding of the problem and solution allows you to make the right technical trade-offs.
You aren't really doing your whole job as a software engineer if you are just building what people ask rather than what people need.
The sweet spot for software engineers is when they understand their customers and their needs deeply.
When that happens, engineers can suggest ideas that product managers or designers might not have considered. This collaboration between engineering, product, and design makes unique software exist. So embrace being a collaborative, product-focused engineer.
Ask "why" and make your product better.