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"?

Asking "why" saves you time because it prevents you from building the wrong solution.

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).

Understanding "why" opens up alternative ways to build the feature.

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.

After asking "why" enough times, you'll build an understanding and intuition about your customers and their needs.

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.

I’ve been working with Maven, a company that specializes in live community-based courses, to develop a 2-week intensive to help early-in-career developers learn the essentials about what it means to be a software engineer.

Most people think they need to learn the right programming language … but what you really need is to learn how to solve problems with code!

Programming languages come and go, but I want take a deep-dive into what it means to write code confidently, break-down problems, and collaborate with other software engineers.

I would love it if you would take 3 minutes to answer a couple of questions about your struggles learning to program.

I'd love to share an early preview of the course as we get closer to time!

Also when the course is released, anyone on the waitlist will get a special 50% early bird rate.

Share your thoughts using this form

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 suggestions for the values of a parameter, but we couldn't actually restrict the value of that parameter. This is because 90% of the time, the value would be a couple of obvious values, however, the other 10% of the time, we had no way to predict what the value would be!

The challenge

You would think that the solution would be simple. But it wasn't.

If you are familiar with TypeScript the initial problem seems easy. We need to declare a list of insects that you can use. This is easily accomplished by defining a Union Type.

type Insect = 'scorpion' | 'cockroach' | 'caterpillar';

The thing that's missing is that if I find a new insect and try to use it, I can't:

const foundInsect: Insect = 'bee';

That would cause an error.

Well, there is a type that would accept any of these strings, right?

const foundInsect: string = 'bee';

This would work, but we lose our IDE suggestions because now the IDE thinks we should just add any string value.

The next assumption is if we have our Insect type as a union, why don't we just include the string type? That's one of the first things I thought to try!

type Insect = 'scorpion' | 'cockroach' | 'caterpillar' | string;

const foundInsect: Insect = 'bee';

At first look, this seems like it should work. We define our list of approved values and we also allow it to be a string.

This won't throw an error, but it turns out ... we still lost our IDE suggestions!

It turns out that

type Insect = 'scorpion' | 'cockroach' | 'caterpillar' | string;

gets simplified down to

type Insect = string;

which means no IDE suggestions for us!

That is when I discovered this issue on the TypeScript GitHub repo, where this problem has been discussed at length.

The problem is, we need to say that the final segment, "string", includes all strings except the ones we've defined. By doing that, TypeScript understands that it needs to hold on to the original literal string types that we define upfront.

The solution, provided by @spcfran and @manuth is:

type LiteralUnion<T extends string | number> = T | Omit<T, T>;

Which works wonders!

The solution

All together you end up with:

type LiteralUnion<T extends string | number> = T | Omit<T, T>;

type Insect = 'scorpion' | 'cockroach' | 'caterpillar';

const foundInsect: LiteralUnion<Insect> = 'bee';

The first type, LiteralUnion is what's called a Generic. It needs a second type to be fully defined. In that definition, the letter T represents whatever type you provided.

So LiteralUnion takes another type called "T" which can extend either a string or a number. Then LiteralUnion defines itself as either: the type, or everything that doesn't match the type.

That's a bit abstract, so let's dive a little deeper.

The second type, Insect is just what we've been working with. It's a Union type, so it says that a value can be "A or B or C". In this case, we're saying the value can be scorpion OR cockroach OR caterpillar.

When we combine these two types: LiteralUnion<Insect> we're saying that the generic type for LiteralUnion is going to be Insect. so T = 'scorpion' | 'cockroach' | 'caterpillar'. This means that ultimately when the LiteralUnion's type is: T OR OMIT T, we essentially get:type LiteralUnion = 'scorpion' | 'cockroach' | 'caterpillar' | OMIT<string, 'scorpion' | 'cockroach' | 'caterpillar'>, which is exactly what we need in order for TypeScript to hold on to all the types for them to be used by the IDE to suggest them as options!

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 hobby for me and then was a side hustle in college. Ultimately I thought I would end up doing something in cyber forensics or cyber security. But I just kind of made decisions as they came up. I quit college because I was bored, worked full-time at the Apple Store, and moved to Maryland to live with my parents at 24. Not exactly what every 24-year-old plans on doing.

But then I applied and got a job as a Geospatial Software Engineer, it turns out, that all of my side hustles from college had created a pretty great resume, which was nice since they didn’t give much money!

As new opportunities came up, I decided about them, but it all felt very random until I was at a company that had a horrible manager. When that manager had to step down due to personal reasons, I realized it was an amazing opportunity. I hadn’t planned on management, I hadn’t planned much of anything in advance. But I felt I could do better at managing the team than he did. So I applied internally, got the position, and then realized I needed to find out how to manage people.

I grew and thrived in that role, but it also made me realize my career could be more than just working in “Senior Engineer” type positions at random companies for the next 20-30 years, which is what I had just assumed without thinking much about it. Instead, I could actually do important jobs that made an impact and even work at big or well-known companies.

This started the most exciting part of my career. I’ve done people management for several years, building a team from 2 people to 8 people, and ended up moving on because I knew I wanted to get into big tech. I’m at Glassdoor now and loving it! I never would have imagined I would be on a trajectory to lead and manage engineering teams much less as part of big well-known tech companies. But my realization that I was now a manager in charge of other people’s careers made me start to actually think about careers and career progression.

Have a long-term idea and a short-term plan.

You need both short-term and long-term plans. Not having a short-term plan will slow your progress and take longer to get where you want to, but a short-term plan without a long-term idea 💡 means every year might have you headed in a different direction rather than making strategic moves towards your ultimate goal.

That is why it’s important to pair both your short-term plan, which allows you to make intentional choices, while your long-term idea keeps you from getting sidetracked on something that seems good but will take you down a different path.

That’s easier said than done! No worries, let’s talk briefly about 3 essential steps that can help you make a basic plan for your career.

1. Start with the end in mind

“What do you want to be when you grow up?” is a question that adults ask kids but that makes no sense. There are so many possibilities, how is a kid supposed to know!

So how can I expect you to plan 5 years ahead?!?

At least that’s what several people asked when I tweeted about having a career plan.

The key is to figure out where you want to be or what you want to do. There is a Japanese idea called Ikigai, which is about a person’s reason for being or purpose.

This framework, Ikigai, is a great way to start brainstorming where you want to be at the pinnacle of your career. The key is finding what sits in the center of four overlapping areas of your life:

• What you can be paid for
• What you are good at
• What you love
• What the world needs

Obviously you may not be able to get a job in 5 years that fits in the center of all four of those pieces, but if you identify what the center looks like, your 5 year idea can move you closer there than you are today.

In my view, it’s best to actually try to move more into the circles in a clock-wise function. This means you start with what you can get paid for. It’s important to take care of your Provision. Then you can double down and get good at it, embracing Proficiency. Once you’ve showed that, you typically open up new doors to shift into what you love, using your Passion. Finally, at the pinnacle of your career the hope is that you’ll be able to be in a position that helps provide something the world needs and thus have an Impact.

2. Choose one significant change over the next year that gets you closer

We often over-estimate what we can do in shorter time periods but we under-estimate how that compounds in the longer time periods. So the goal should be to accomplish one major change in a year. Something that requires several steps and moving parts and that makes a meaningful step towards your 5 year goal.

For example, think about things like:

• Is there a big promotion you’re close to?
• Is there a necessary skill you’re missing or have very little experience with?
• Is there some area that you haven’t gotten to work in?

3. Define 4 milestones that will get you to your 1 year plan

A year is both quick and a long time. It’s quick in terms of your life and a decade, however it’s a long-time in the day to day. To bridge that gap, you should set shorter goals, I recommend quarterly goals, that are smaller steps that can get you to your year long plan.

If you are working to get a promotion, then your goals should focus on ensuring you’ve been part of projects or other things that you’ll be able to use in your promotion packet or discussion.

If you’re trying to expand a skill, you’ll probably want to learn about it, then find a project to use it in. You’ll want to be sure and have a period where someone can give you feedback, because that’s the only way to learn and grow, and then implement that feedback actively.

Whatever your plan for this next year, it’s likely something that can be broken down into smaller chunks that can be tackled on a quarterly basis.

Don’t experience the same mistake I did, choose to invest in your future by setting up an action plan for your career today! Figure out where you are at in the Ikigai framework, and figure out what the next area you want to grow into is.

Provision, a job that pays? Proficiency, becoming good at your job? Passion, a job you love? Impact, a job that provides for a need in the world?

Choose where you want to be in 5 years and what that might look like. Make a plan for where you want to be at the end of this year and then set quarterly goals to get yourself there!

Just remember by developing an intentional plan, you are ensuring consistent growth. Consistent growth is the key to long-term success!

I’d love to hear your questions or your goals!