DEV Community: David Glassanos

Who's Hiring Junior Engineers - Edition #1

David Glassanos — Tue, 30 Aug 2022 04:55:00 +0000

Welcome to the first installment of Who's Hiring Junior Engineers 🎉 .

Every few weeks you can expect a post with hand-picked links to job listings from companies that are hiring junior software engineers. I’m hoping that by sharing these job openings I can help more people get their foot in the door and begin their programming careers.

Beginner.dev is a reader-supported publication. To receive new posts and support my work, consider becoming a free or paid subscriber.

Recent Job Listings

Junior Software Engineer - Alpha Ori Technologies (San Diego, CA)

Junior Software Engineer - 4 Mile Analytics (Remote)

Junior Software Engineer - Gray (Remote)

Junior Software Engineer - Castle Hill Gaming (Charlottesville, VA)

Junior Software Engineer - Valkyrie Trading (Chicago, IL)

Junior Software Engineer, Full-Stack - CharterUP (San Francisco, CA)

Junior Software Engineer - Latitude, Inc. (Bethesda, MD)

Junior Software Developer - Gleim (Gainesville, FL)

Junior Software Engineer - Gambyt (Remote)

Junior Software Engineer - 401GO (West Jordan, UT)

That’s all for now. Keep an eye out for Edition #2 in a few weeks. Sign up for the Beginner.dev Newsletter to receive more Junior Software Engineer job listings in your inbox.

I Burned Out

David Glassanos — Tue, 23 Aug 2022 15:43:59 +0000

It’s been a few months since I last published anything on Beginner.dev. My goal with this newsletter has always been to help developers reach that next step in their career, and giving an honest look into what it takes to build a successful career is part of that goal. The reason I haven’t been publishing new posts lately is because I’ve been dealing with severe burnout at my day job and I had to step away for a bit. I’m hoping by talking about it publicly will help others that may be going through something similar.

Burnout can happen to anyone, at any time. I’ve been programming professionally for 15 years and I wasn’t able to notice the signs of burnout until it was too late. The amount of work and pressure I’ve been dealing with on my projects eventually caught up to me, and it impacted my output and efficiency significantly.

It’s taken some time away from work and some self-reflection to identify what went wrong, when things went wrong, and why things went wrong. I may write another post someday going into more detail about it, but for now I’m still focused on getting back to my normal work so I just want to talk about what has helped me so far.

It’s not easy to recover from burnout. It’ll take some time for things to settle down, but there are some things you can do to reduce the stress and help get yourself back to a good spot.

Step 1: Recognize you’re burned out

In a way, recognizing that you’re burned out is the hardest thing to do because it’s probably too late by the time you do realize what’s happening. The important thing is that you’re able to recognize the burnout, because then you can do something about it. If you don’t know you’re burned out, it’s much harder to take any steps to recover from it.

How do you know you’re burned out?

Feeling angry when something doesn’t go the way you want it to.
Feeling jaded or unmotivated about the projects you’re working on.
Feeling jaded or annoyed when working together with other developers.
General lack of motivation to do some or all parts of your job.

Everyone’s situation will be different, and you may react differently than others would in situations if you’re burned out, but the important thing is to reflect on yourself and your behavior and understand when you’re not being yourself.

Step 2: Ask for help

If people don’t know that you’re struggling, they won’t know that you need help. It can be difficult to open up and be honest with people, especially your coworkers who you have a professional relationship with. If possible, set up some time to talk to your manager and let them know that you’ve been feeling burned out. Just be honest with them and tell them what you’ve been dealing with and why you’re feeling burned out. It might be hard to open up, but it’s the best thing you can do when suffering from burnout.

Your manager is there to help you succeed, and they should hopefully work with you to get you back to a productive state. They can help in different ways, such as reducing your workload, bringing in additional help on your projects, or moving you on to other projects that are less stressful or have less urgent deadlines. If they know you’re going through a tough time and not able to work at peak productivity, they should do what they can to help reduce your workload and take some of the stress off your plate.

Step 3: Lighten your workload

It’s hard to give specific advice for this step because everyone’s circumstances will be different. Your situation will be entirely dependent on your manager, your company, and the severity of your burnout. While your manager can definitely help reduce your workload, it’s ultimately up to you to determine and dictate how much work you can take on at once.

Things you can talk to your manager about that would help reduce your workload:

Bringing other people onto your project to help out
Moving you to a different project
Moving to a four day work week temporarily
Taking some time off of work

Even if your manager does help out by giving you a lighter workload, there may be other people reaching out directly to you to ask questions, ask for favors, and ask for help with certain things. It’s up to you to learn how to say “no” to people asking things from you in these side channels. The important thing is to stay focused on the tasks and projects that are planned and are on the roadmap, because those are the projects that upper management have visibility into. If you’re spending time on side tasks and not on your planned work, it will look like you’re making slow progress on your projects on the roadmap, which could lead to increased pressure from upper management to get them done sooner.

🔗 Additional Reading

The Ultimate Burnout Guide: Symptoms, Causes, and Prevention(commoncog.com)
How to Prevent or Recover from Developer Burnout (dev.to/actitime)
83% of Developers Suffer From Burnout, Haystack Analytics Study Finds (usehaystack.io)

Business Value for Programmers

David Glassanos — Mon, 02 May 2022 14:53:51 +0000

This week we’ll be focusing on how you can add business value. When you’re working on your tasks this week, try to take some time to understand how what you’re working on is adding value to the business, whether it’s planning, writing code, or reviewing other developer’s code.

So what even is business value? If I had to pick one sentence to describe what business value is, it would be this: Business value is all about solving problems for your users. It sounds simple, but there’s more to it. It’s easy to forget, but your users may be paying customers, external partnerships, or internal users within your company. Whoever your users are, as long as you’re solving problems for them, you’re adding business value.

The thing that most developers have a hard time understanding early on in their career is that the code doesn’t matter as much as you think it does. Your users don’t care about what programming language or framework you use, or what design patterns you implemented in the codebase. All they care about is that your product solves their problem, that it is bug free, and that it’s reliable.

So how do you solve problems for your users? Focus on their pain points. Be relentless about making things easier, cheaper, and faster for your users whoever they may be. Don’t get caught up trying to write perfect code or finding the perfect abstraction. If the code is good enough (and it solves their pain points) ship it and move on. If you’re constantly refactoring code until it’s perfect, you’re just wasting effort to make the code better without adding new value for your users.

So how do you know what your user’s pain points are? That’s up to you to learn as much as you can about the domain of the problem you’re trying to solve.

Internal users

If you’re working on an internal tool, you should be able to reach out to the users of your product and ask them directly about their pain points. Ask them what is most important to them when it comes to using the tool or product you’re building. What frustrations do they have? If they could change one thing about the product, what would it be? How would the tool work if it were fully automated?

There may be opportunities to optimize internal workflows even further if you are able to understand what is important to your coworkers. When building internal tools, your focus should be making it as easy as possible for your users.

Paying customers

In order to truly add value for paying customers, you need to understand why they use your product. What problem is your product solving for your customers? Why is it even a problem for them? If you really want to fully understand your customers, you’ll need to learn the business domain.

Anyone can write a CRUD application that does basic data manipulation for a specific vertical, the real value is in writing software that does complex tasks for your users that they otherwise couldn’t do themselves. The key is to understand why your users need to perform these complex tasks so that you can expand your product’s capabilities to make your user’s lives easier. And the only way to do that is to fully understand the industry you work in and the real problems your products solve for your customers.

I’ll encourage you to spend ten to fifteen minutes every morning this week thinking about your users and how you can make their lives even easier. When you put yourself in the shoes of your user, you’ll be able to think about new ways that you can add business value for them.

🔗 Additional Reading

Code-first vs. Product-first (thezbook.com)
You Are Not Paid To Write Code (dzone.com)

If you liked this post, subscribe to the Beginner.dev newsletter on Substack for more great content just like this.

On Choosing a Career Path

David Glassanos — Tue, 08 Mar 2022 21:01:51 +0000

As a programmer, it’s important to focus on your career goals, because if you don’t know where you’re going, you won’t know when you’ve reached your destination. Even the most ambitious programmers won’t get very far if they don’t have an end-goal in mind. Setting a north star will keep you focused and motivated as you navigate the twists and turns of your career, so it’s important to reflect on the path you want to take so you can stay on track.

There are a few different aspects that you should consider when thinking about your career goals -- the engineering path you want to take, whether you want to focus on a generalized or a specialized set of skills, and the leadership path. When combined, these factors help you determine where you should focus your time and energy during your career development.

Let’s take a look at each of these in more detail.

This is an excerpt from "Junior to Senior", my upcoming book about building the soft-skills needed for a promotion to a senior software engineering role. If you’d like to be notified when the book is available, you can join the waitlist.

Your engineering path

You’ve probably already put some thought into the engineering path you want to take. Perhaps you’re learning your first programming language, or you’ve found a framework you like and have built a few projects with it already. That’s great, because that’s the first step to deciding which engineering path you should pursue.

The engineering path you follow will determine your journey to increasing technical mastery of one or more technologies of your choosing. The technology (or set of technologies) you decide to learn early on in your career may seem inconsequential right now, but they will have a drastic impact on your career.

In some cases, the technologies you chose to focus on will dictate which companies and industries you’ll apply to when searching for a job. On the other hand, if you’ve already landed a programming job, you’ll want to do as much as possible to become an expert in the technologies that your company has invested in.

Let’s dig a little deeper into each of those scenarios.

Choosing a technology

Programmers have a natural tendency to seek out roles that require similar skills that they possess. Part of this is due to the fact that interviewing is hard, so people tend to want to interview in a language or technology that they are comfortable and confident with. Because of this, they will research and apply to companies that work with similar technologies that a candidate is familiar with. So while it may not be obvious, the technologies you choose to learn early in your career will determine which companies and industries are within reach when it comes to searching for a new role.

This is partly due to the fact that businesses have limited time and resources when it comes to hiring and onboarding new employees. Most companies can’t afford to spend more than a few months getting a new hire up to speed, so they tend to recruit programmers that are experienced in specific technologies that the company has invested in.

If a company’s product is built on a codebase consisting of Python code, for example, they’re more likely to consider candidates with strong Python skills over candidates with no Python experience at all. Taking the example further, if the company utilizes a specific framework or library such as Django or Tensorflow, they will naturally seek out programmers who are familiar with these technologies. It’s more cost effective for companies to hire candidates who already poses desired skills a company is looking for, rather then hire someone and team them those skills.

Most companies tend to be more lenient when it comes to frameworks versus languages, because frameworks are easier to learn if a new hire is already familiar with the underlying programming language. At that point, it becomes a matter of learning the different APIs of the framework, which is arguably easier than learning the semantics of a new programming language, in addition to the APIs of the framework.

The more a new hire is required to learn during onboarding, the longer it will be until they can start to provide real value, so it’s cost effective for companies to hire candidates that are already familiar with specific technologies.

Which brings us back to what we talked about earlier – that it’s easier to land interviews and get offers at companies seeking experience with technologies that you’re familiar with. While it’s still possible to find companies willing to hire candidates with no prior experience in a programming language, those companies can be difficult to find.

However, as a junior programmer you are presented with a unique opportunity, because there are companies that are willing to hire candidates in the early stages of their career even if they don’t have any prior experience with specific technologies. These companies tend to be established enterprises, because they have the budget and resources to invest in their employees over a longer timeline. These companies tend to operate in niche industries or industries with high barriers to entry, so they can afford to spend a year onboarding a new programmer. Some industries such as aerospace, healthcare, energy, and many others may take years to get up to speed, so they are willing to invest in their new hires and teach them everything they need to know.

Startups and small businesses, on the other hand, don’t have the luxury of large budgets and longer timelines that established corporations can afford. Startups naturally need to move quickly as they seek to validate and scale their business model, so they tend to focus their hiring on candidates that have the specific skills they need. Smaller companies need new hires to add value as fast as possible, so it may be harder to land an interview at a startup if you don’t have experience with a specific technology.

So, how do you go about choosing which technologies to specialize in? There’s no easy answer to that question, because everyone’s situation is unique, but I’ll try to give some advice that will help you decide.

First, think about the languages and frameworks you’re already familiar with. Are you comfortable enough that you feel you could interview for a role in that language? Try solving some practice problems on HackerRank or LeetCode to gauge how ready you are. If you feel like you’re prepared enough to solve interview questions on the spot, then you’re ready to start applying for roles.

Start searching for companies on Linkedin or other job boards that are looking for programmers with experience in your language. You may even be able to get your foot in the door for an interview with startups and smaller companies that need to hire programmers with your specific skill set.

If you don’t think you’re ready to interview with a specific language yet, that’s okay. That just means you’ll need to keep practicing and learn the language until you feel you’re comfortable enough to interview. You’re not completely out of luck though, because you can still look for larger enterprise companies that are willing to hire smart candidates without any prior experience with a language or technology. These companies tend to hire based on potential rather than how well you know a specific skill or algorithm.

Now let’s look at what you should consider once you’ve landed a role and are invested in a specific technology.

Mastering a technology

Getting hired for your first programming job is one of the biggest hurdles of your career. The next step is to focus on mastering the languages your team uses as best you can.

Unfortunately, you may not have much of a choice when it comes to choosing which programming languages and technologies you will work with. The decision was probably made for you by other programmers who built the system before you joined. Even if you’re familiar with the programming language they chose, it’s possible they built the system using a framework or library that you’ve never used before.

Like it or not, your ability to succeed is dependent on how well you know the technologies that your team uses. Your technical mastery of these tools can actually have an effect on whether or not you get promoted to a role with increased responsibility.

As you gain more experience and work on larger projects, you’ll need to understand the technologies you work with at a deeper level to design and scale solutions to meet the business’ needs. You can’t pick the right tool for the job if you don’t have a good understanding of the strengths and weaknesses of each technology you’re working with.

So what are some ways in which you can master the technologies you work with?

The most obvious resource that you can leverage is right in front of you – your coworkers. They are likely the ones who have written large portions of the codebase you’re working in, which means you can lean on them to learn the best practices and core concepts.

Most programmers need some help early on in their career as they make the transition from learning how to program to learning how to solve complex problems through code. It’s a small but important difference that requires a different way of thinking about problems. You’ve learned how to use the foundational concepts of your language to build programs, but now you need to learn how to break down a problem and construct a solution using the building blocks available to you.

This transition can be difficult if you try to do it entirely on your own, so it’s best to try and leverage the experience of your coworkers and their knowledge as much as you can early on in your career. Read their code, review their pull requests, and ask questions about how they come up with their solutions. There’s actually a lot that you can learn from reading code and asking the right questions.

With the help of your coworkers, you’ll be on a good path to mastering your first programming language. It’s important to stay focused early on in your career and get really comfortable with the language you’re using. Don’t worry too much about learning other languages at this stage in your career. Your priority should be to get really good at one language, because you’ll always be able to fall back on that as your foundation. Assuming you chose a language that has a large community and is used by many companies, you’ll have job security because you’ll always be able to find work at companies looking for your skillset.

It usually takes a few years to reach an advanced level with a programming language. Once you approach this point, you have to start thinking about where you want to go in your career. One decision you’ll have to make is whether to take a generalized approach with your skill set or specialize in a specific skill set.

Let’s take a look at both of these options.

Generalist vs. specialist

At some point you’ll need to decide whether you want to branch out and learn additional languages and technologies, or double down and become an expert in one or two specific technologies. Programmers can be successful in either path so it mainly comes down to personal preference and some careful consideration about where you want to take your career.

Let’s look at each path in detail.

Going broad

A programmer who views themself as a generalist typically wears many hats and will have an intermediate-to-advanced knowledge of many different complementary skill sets. They may work with many different programming languages, databases, and platforms. Their range of skills allows them to collaborate across multiple disciplines to solve customer problems.

☝️ It’s worth noting that the term “generalist” does not mean “full-stack”, even though the two terms are often conflated. While full-stack developers are considered generalists, you can still be a generalist within a vertical such as mobile development, game development, or systems programming.

Generalists typically cast a wide net, which gives them the ability to jump around to different projects, companies, and even industries throughout their career. They bring with them a broad set of experience because they’ve worked on many different projects and technology stacks. In some cases they can bring experience from one project or industry over to another to solve problems in novel ways.

Because generalists carry such a diverse set of skills with them, they have the advantage of a larger job market and an easier time finding work. Many companies prefer to look for candidates with a generalist skill set because they deal with constantly evolving requirements from customers. New projects arise from changing requirements and companies are able to shift developers from project to project without having to hire new programmers with a specific skill set.

More often than not, it’s typically a good idea to generalize your skill set during your career, but only after you’ve become comfortable in your first programming language. When you generalize you are exposed to many different technologies and industries, but just because you’ve taken the generalist path does not mean you can’t specialize in one area. In fact, starting off as a generalist gives you the opportunity to try a number of different technologies before deciding which one you’d like to specialize in.

🔸 One thing generalists should consider is the need to stay up-to-date for multiple skill sets as the ecosystem for each technology evolves in parallel. Without continuous learning, generalists may fall behind in one of more technologies if they don’t find time to practice those skills.

Now let’s look at the specialist in more detail.

Going deep

The specialist path is an option for those programmers who want to take a deep dive on a technology, effectively becoming an expert in one specific area. You may choose to specialize in a programming language, a database technology, or a field of computer science such as machine learning or algorithms. It can take years, sometimes decades, to reach an expert level, but once you do you’re often rewarded with job security and higher salaries, because companies will compete for your skills if they’re in high demand.

🔰 Examples of specialists include a computer vision expert working for an autonomous driving car company, someone who specializes in quantitative trading systems working at a hedge fund, a big data expert working for an IoT company, or even an expert in the Ruby programming language working for a company that has built their codebases on Ruby.

Specialists often have leverage when it comes to negotiating job offers and salary increases because their deep knowledge in a field may be considered a competitive advantage in certain industries.

Although specialists may not have trouble finding new work, the size of their overall job market may be much smaller than that of a generalist due to the fact that there are fewer companies looking for their specific set of skills. This presents an interesting problem and something that should be considered when thinking about your career path: What if you specialize in the wrong thing?

There’s inherently more risk if you decide to specialize in a programming language or field of computer science, because you’ll need to devote years of your life becoming an expert in one specific set of skills. If the industry evolves during that time you may be putting energy into something that isn’t guaranteed to be in demand a few years from now.

That’s a calculated risk you’ll need to take when deciding what to specialize in, but if you understand a specific technology well enough to become an expert in the first place, you may be able to anticipate where the industry is headed and get a head start. When done right, specializing can be very lucrative for programmers.

☝️ While most programmers think about specializing in a specific technology, it’s also possible to specialize in a specific industry. You may use different technologies as you jump from company to company within the same industry, such as healthcare or finance. Although you may not be an expert in the technology at a company, you bring a wealth of industry knowledge with you which can be just as valuable. When it comes to hiring, a company may consider years of experience in an industry just as valuable as years of experience with a technology.

Now that we’ve gone into detail about the technical path of your career, let’s look at another aspect.

Your leadership path

In the early stages of your career you’re probably going to be focused on developing your technical skills first before thinking about any kind of leadership path. While it’s good to have a sense of where your career is heading from a technical perspective, it’s equally important to start thinking about your career from a leadership perspective.

At some point, usually after you’ve been in a senior role for a while, you’ll reach an inflection point where you’ll need to decide if you want to stick with the technical track as an individual contributor (IC), or make the jump to the management track. There are excellent leadership opportunities in both paths, but it’s important to understand what those responsibilities look like as you think about the direction you want to take your career.

All programmers begin their career on the technical track as individual contributors, because the foundational skills you develop early on are prerequisites for both the technical and management tracks.

The primary responsibility of an individual contributor is to support the organization through the projects and tasks that you work on. You won’t carry any management responsibilities or have anyone report directly to you, so you will only be expected to manage yourself and your own work.

Most programmers enjoy working as an individual contributor because it allows them to do what they love–programming. The majority of your time will be spent reading, reviewing, and writing code. You’ll design and implement feature enhancements and identify and fix bugs. As you start out you will rely on senior engineers to provide direction and context for the changes you make, but as you gain more experience and autonomy you’ll shift to designing and implementing your own solutions to medium and large sized problems that are well understood.

Once you reach the inflection point–sometime after you’ve been in a senior role for a while– you’ll need to decide if you want to continue down the technical track or shift over to the management track.

Let’s look at both tracks in more detail.

Technical track

After you’ve reached a senior engineering role, the most common levels on the technical track are the Staff Engineer, Senior Staff Engineer, and Principal Engineer roles. These roles deal with increasing job complexity and often require expert knowledge in multiple technologies in addition to development best practices.

In contrast to the junior, mid-level, and senior engineers, the higher roles on the technical track are responsible for exploring different solutions to large and poorly understood problems. They often build proofs of concept to demonstrate the feasibility of different solutions before choosing which direction to pursue.

Staff and Principal Engineers are expected to perform expert programming tasks and find opportunities for large scale refactorings in order to pay down technical debt. They think strategically about how the technical systems fit into the rest of the company in order to provide leverage and opportunities for the company to scale.

They may not necessarily sit on just one team. Staff and principal engineers often move across teams to wherever the difficult and vague problems exist. They may design a solution for one team and them move to a different team to help them find the best direction for a different problem.

Although it is primarily a technical role, most senior programmers on the technical track provide leadership through their technical guidance on projects and through mentoring a handful of individuals. Many engineers incorrectly assume that they want to stick on the technical track because they don’t want to manage people. While it’s true that Staff engineers don’t have direct reports, there is a fair amount of people management involved. They still need to work with other engineers to build consensus and buy-in for their ideas, concepts, and initiatives they belive the company should pursue.

The technical path provides opportunities for those who aren’t necessarily interested in managing people directly, while still allowing them to practice their technical skills in order to design and build systems that provide value for the organization.

Managerial track

The path toward management is gradual. You don’t suddenly become a manager one day when the title gets assigned to you. Rather, it takes years of experience leading projects from a technical point of view, learning to collaborate with others and listening to the needs of other programmers. Engineering managers have a knack for helping other programmers achieve their potential, and that isn’t something that can be learned overnight.

Rather than continuing down the technical path, some programmers may find themselves more comfortable leading the direction of the projects, or the people involved in a project instead. While it’s possible they still contribute code here and there, they enjoy fostering the collaboration and communication between engineers working on a project to get it across the finish line.

While they are expected to have an intimate understanding of the technologies involved in the company’s products, managers are required to have an expert knowledge of the products themselves as well, including how those products are implemented from a technical perspective.

In addition to balancing tactical short term goals with strategic long term goals for the company, to be a great leader in the managerial track you need to be able to recruit and retain great engineers. Part of their job is to build great teams, and in doing so they need to find ways to foster career growth for the engineers on their team. Above all else, the managers support the needs of everyone on their team so that they can all achieve their full potential.

🔹 While the leadership path consists of two discrete tracks (technical and managerial), engineering managers almost always start out as individual contributors. Just like how managers need to understand the technical issues at hand, the individual contributors need to understand the management issues in order to be effective as well.

It’s a marathon, not a sprint

Now that we’ve looked at what things to consider when thinking about your engineering path, whether to generalize or specialize, and options for your leadership path, it may feel like there are a lot of things to think about. There’s a lot that goes into software development, but you don’t need to decide all of these things at once.

It may be overwhelming to think about all of these things right now, so it’s important to give yourself a reasonable timeline when it comes to advancing in your career. It’s important to keep things in perspective when setting goals for yourself, because you have a long career ahead of you.

Some skills take years to learn and decades to master, so be patient and take things day by day. Continuous improvement is the best thing you can focus on right now, as that will give you a strong foundation that you can build off of in the future. Small improvements every day will compound over time, and soon you’ll look back and be surprised at how quickly you’re progressing.

Think about your career as if you’re running a marathon, and you’re just starting your race. You wouldn’t want to sprint to the finish line right now because you might burn yourself out. Just be patient, and take it one career milestone at a time.

If you enjoyed this excerpt from "Junior to Senior", join the waitlist to be notified when the book is available.

How to Beat Imposter Feelings

David Glassanos — Mon, 14 Feb 2022 16:45:33 +0000

This is an excerpt from Junior to Senior, my upcoming book about building the soft-skills needed for a promotion to a senior software engineering role. If you’d like to be notified when the book is available, you can join the waitlist.
__

Have you ever sat in a room and felt like you weren’t smart enough to be there? Maybe the conversation moved too quickly for you to follow, or perhaps your coworkers debated a topic you weren’t familiar with. It’s an uncomfortable feeling that every programmer goes through at some point in their career. When you start to doubt your own abilities and feel insufficient at your job, you’re experiencing imposter feelings.

🔰Feeling like an imposter can come on suddenly in a number of different situations:

If you’ve ever questioned your ability to complete a task that you’re stuck on.
If you feel like you don’t belong on a team or at a company because you’re not capable enough to follow along during discussions.
If you’ve ever felt completely overwhelmed, especially when starting a new role, a new project, or learning a new codebase.
If you’ve ever had trouble articulating how something works on a technical level, or when someone asks you why you made a certain decision.
If you’ve ever found yourself in one of these situations, it’s hard not to feel like a phony.

The good news is that it’s probably not as bad as you think, and it’s way more common than you realize, because all programmers experience these feelings throughout their careers. Unfortunately, part of the problem is due to the stigma surrounding imposter feelings, which often discourages people from discussing their feelings openly and seeking advice from others. It’s especially hard during the first few years of your career because you’re learning so many different things all at once.

You’re focused on learning things such as:

Your team’s codebase and the technologies they use.
Your team’s development processes and methodologies.
Your company’s business logic and business model.
Your manager’s management style.
How to work well with your team members.
How to work with stakeholders, product managers, designers, and executives.

It’s common for software developers to feel overwhelmed with the pace of things during the first few years of their career. Things move incredibly fast when you’re still getting up to speed, and decisions happen quickly. Try not to get discouraged if you’re having trouble keeping up with your coworkers as you’re still learning. Some of your coworkers have been with your company for years, so naturally they will have more domain knowledge that they’ve built up over time, and a deeper understanding of the problems that need to be solved. They’ve probably written large portions of your codebase so they will know the system better.

🔹The key thing to remember is that you shouldn’t be intimidated by coworkers who know more than you. In fact, you should view it as an opportunity to learn from them and ask them questions. Leverage their knowledge so that you can learn faster from their experience.

It’s a Feeling, not a Syndrome

Chances are that you’ve heard people talk about feeling like an imposter, although they probably referred to it as having “imposter syndrome.” While this phrase is commonly used, it’s misleading because it tends to oversimplify the issue. Unfortunately, the phrase “imposter syndrome” is a well known phrase that helps you easily communicate the feelings you’re experiencing. It also does a good job of recognizing a feeling of being overwhelmed or inadequate that you may be struggling with. While this may seem like a good thing, there are some negative consequences that come from using the term.

The solution is not to label yourself as having a medical syndrome that needs to be treated; it’s to recognize your feelings so that you can work towards improving yourself and building confidence. Slapping a label on something you’re feeling doesn’t make it go away, but recognizing it is the first step towards self-improvement.

Additionally, the term “imposter syndrome” tends to imply several things for different people:

You either have it or you don’t.
It’s abnormal.
You likely won’t get better without treatment, as with many medical syndromes.

None of these points are true, at least for most people. Think of it more as a natural feeling you have, like stage fright or feeling uncomfortable. It may come on suddenly and with varying intensity, but it’s a temporary feeling that will pass eventually. It’s good to remember this when you’re having these feelings so that you can manage them and try to reduce the negative thoughts that come with them.

In essence, imposter feelings can happen to anyone and can come on at any point in one’s career. Rather than trying to fight it, it’s more effective to embrace it and use it to motivate you to improve. Let’s dig deeper into what you can do when you suddenly start to feel like an imposter.

Knowledge Gaps

As programmers, we’re expected to know a wide array of things in order to do our jobs. On top of necessary skills like writing code that compiles without errors, we also need to know how to design our programs to be future proof, how to write automated tests so we can be sure the code works as expected, and how to deliver results consistently and efficiently.

It’s easy to feel overwhelmed with the amount of knowledge required in order to complete our day-to-day tasks, in addition to answering questions from project stakeholders, defending our technical decisions during code reviews, and planning ahead for the future.

There will be plenty of times throughout your career where you won’t know the answer to a question, or won’t know what someone else on your team is talking about. It happens to software engineers of all levels, not just junior engineers. The thing that makes good engineers stand out from the rest is that they are humbled and reminded that they don’t know everything, and they use those situations to learn and grow.

🔰Examples of situations that might bring on imposter feelings include:

Your boss might ask you a question in front of your team that you don’t know the answer to.
A senior engineer might ask if you considered an obvious edge case when fixing a bug.
A senior product manager might ask you to estimate how long it would take to build a new feature in a part of the codebase you’re not familiar with.
Your boss might ask you to clarify how something works that you built six months ago, and you might not remember all the details about it.

It’s okay to admit that you don’t know something, or that you hadn’t considered some obvious edge case. In fact, admitting that you don’t know something is a sign of maturity. If you want to be successful in your career, you need to put your ego aside and accept the fact that you won’t know everything. In fact, it’s nearly impossible to know everything there is about programming. It’s such a broad industry that is still evolving each and every day, and it’s simply not possible to be an expert on every topic.

Additionally, there’s even more to learn about the process of delivering software, because writing code is only one part of the equation when it comes to delivering value for customers. There’s planning, analysis, design, implementation, testing and integration, and maintenance phases in a modern software development lifecycle, and each phase comes with its own nuances and best practices. While you may not be great at all of those phases, a senior engineer must understand the entire process. It’s natural to feel like an imposter if you don’t have a lot of knowledge in one or more of these areas, but that doesn’t mean you’re not a good engineer; it just means you have more to learn.

Let’s look at what you can do to minimize those imposter feelings and leverage them to become a better software engineer.

Identify the Gaps

You have gaps in your knowledge. We all do. It’s natural, so don’t worry about it too much. What’s more important is that you seek out and acknowledge these shortcomings so that you can take steps to close the gaps. When you accept your limitations, it allows you to put your ego aside and open your mind to new ideas and opportunities to grow.

Too often we fall into the misconception that we know more than we really do, which leads us to be stubborn and closed-minded when we’re presented with new information. Believing that you know more than you think you do can have a negative effect on your ability to learn, and in some cases it can stagnate your career growth. If you believe you know more than you do, it’s easy to get defensive when your ideas are challenged. How you react in those situations can lead to conflicts with your coworkers or hinder your ability to make impartial decisions, which is why it’s important to be honest with yourself about the limitations of your knowledge and your skills.

When you accept that you don’t know what you don’t know, it opens the door to opportunities to improve the situation:

When you’re honest with yourself about what you don’t know, you naturally identify areas where you need to seek more information and learn more.

When you accept you don’t know something about a topic, it takes the pressure off when you need to ask for help. It gives you confidence to reach out to someone else who can help you who may be an expert in that topic, or they may be able to point you to someone who is.

Knowing what you don’t know helps to prevent you from making an uninformed or biased decision.

So how do you identify what you don’t know? A good first step is to write down in your notes things you already know that you don’t know. This could be things like topics, phrases, or acronyms that you’ve heard before, but don’t know what they are. Write down as many things as you can think of.

🔹Use your favorite note taking app or even a physical notebook. Something that you’ll be able to access at any time and be able to reference later on.

It’s important to be honest with yourself during this step. Don’t be embarrassed if the list is long or you think it’s full of basic topics. And they don’t necessarily have to be technical topics either–they can be related to general business topics, some unique aspect of your company, or something unique about your industry. And finally, while it’s important to write down things you don’t know or understand, it’s also important to write down what you don’t understand about it too. This will give you some indication on what you should focus on when it’s time to learn.

🔰Let’s look at some examples:

I don’t understand how containers are different from VMs. It sounds like they do the same thing.
I don’t understand dependency injection or why I would need it.
I don’t understand our company’s sales process. Where do our customers come from?
I don’t understand react hooks. Why do I even need them?
I don’t fully understand the difference between an abstract class and an interface, and when to use one over the other.
I don’t understand the difference between stack vs heap memory.
I don’t understand the economics of our industry. How do we determine the price point to sell our product competitively?

The next step is to observe. Take note of any new terms, phrases, acronyms, or concepts that pop up during conversations, video calls, chats, or comments from your coworkers or things you come across online. Anytime you come across an idea that you’re not familiar with, add it to your list. And every time you hear someone mention a topic that’s already on your list, add a checkmark or a +1 next to it.

🔰Here are a few more examples:

What is ARR? And why is the leadership team interested in tracking that metric?
My boss keeps mentioning the need for static code analysis. What is it and why is it so important?
I keep seeing people mention Kubernetes online. I know it has to do with containers but why is it so popular?

Before you know it, you’ll have a long list of topics of things for you to learn and improve your knowledge about. Whenever you have some time to spare, you can use this list as a starting point for things to research and learn about.

Close the Gaps

Once you’ve compiled a list of topics that you know you don’t know, you can begin to work towards learning and closing those knowledge gaps. At this point you’ve essentially compiled a roadmap for expanding your knowledge. Now you can begin to chip away at this list and start to close those gaps in your knowledge.

You can start with any topic, whether it’s something that you’re really interested in, or something that you think will help you during your career. Another option is to rank the topics by what you think is the most important or what will have the highest impact in your day-to-day work.

An important thing to remember during this step is that you shouldn’t try to learn everything at once. Your list may be long, but that’s okay! Focus on learning one topic at a time so that you can give it your full attention. Try to learn as much about it as possible before moving on to the next topic. If you try to learn too many things at once, you won’t be able to give each topic the attention it deserves, and you may not remember each thing you’re trying to learn.

You may be able to learn about some topics in a day, while others may take days or weeks to fully comprehend. Feel free to dive as deep into a topic as you see fit, but always try to learn more than just surface level details about something.

Let’s look at the ARR acronym from the previous example.

Through your research you learn that “ARR” stands for Annual Recurring Revenue. Great! Now you’ll know what the executive team means whenever they “say we need focus on growing ARR.” But don’t stop there–try to dig further and understand why focused on growing ARR is so important.

Why is ARR an important metric for a SaaS company? How is ARR calculated? (knowing this will help you understand how to increase it) What does it mean if ARR is growing? What about declining? How does my work fit into the company goal of growing ARR?

Spending time to do your own research and teaching yourself a topic is invaluable. Try to learn the foundational concepts behind each topic, and what makes them important. Once you start to learn about a topic beyond just the basics, you may come up with more questions and want to dig deeper. Use this as a good opportunity to reach out to others and ask some questions. Try to identify coworkers or people in your network that are familiar with the topic and let them know that you’d like to learn more.

☝️Sometimes the hardest part is in determining exactly what you should ask, who you should ask, or how you should frame your questions. Asking questions is harder than it sounds, so we cover that topic in greater detail in Chapter 6 of my book: How to Ask Better Questions. If you’d like to be notified when the book is available, you can join the waitlist.

Identifying and closing your knowledge gaps is just one thing you can do in order to counteract the negative thoughts when you’re feeling like an imposter. It’s a great way to build confidence, expand your knowledge, and learn new skills and ideas that could help you throughout your career. Next time you’re feeling like an imposter, try writing down things you don’t know or want to learn, and start chipping away and learn something new.

Hopefully you now understand that feeling like a phony or a fraud is common among all software developers, and that you shouldn’t get too hard on yourself when you’re going through a period of feeling like an imposter. The most important part is to try to identify why you’re experiencing those feelings, and accept that nobody is perfect. Once you understand the root cause of why you’re feeling a certain way, you can begin to take action to improve yourself and your skill.

With a little persistence and determination to get better, you’ll be able to build up the confidence to take on any situation, no matter how daunting.

If you enjoyed this excerpt from Junior to Senior, join the waitlist to be notified when the book is available.

Find Your Priorities

David Glassanos — Mon, 04 Nov 2019 23:27:14 +0000

At some point in your career, you’ll have setbacks. Whether it’s personal health, family emergencies, burnout, a colleague getting the promotion you wanted, or just plain bad luck. Sometimes life gets in the way of work and you feel like you’re not progressing in your career. It sucks to feel stuck. And you might even question whether programming is the right career for you. There have been two times I can remember where I considered switching careers because I was so unhappy with my day job. It happens to everyone.

When this happens it’s hard not to compare yourself to your peers at similar junctions in their careers. I’ve done it too. Especially when you hear about engineers at the big tech companies making $300,000 a year. Suddenly you’re wondering what you’re doing with your own career.

It’s a bit cliche to say but it’s worth mentioning that money != happiness. During the first half of my career, most of my focus was on maximizing my salary. In the latter half of my career, I’ve focused more on maximizing my happiness, even taking less salary so that I could have a better work-life balance that worked for me and my family. I’ve held high paying jobs where I was miserable, and I dreaded rolling into the office every morning. At some point, you have to ask yourself if it’s worth it. And only you hold the answer to that question.

My personal experiences won’t apply to everyone, however, so I encourage you to spend time self-reflecting and determine what’s most important to you. And do this often because your priorities will likely change as you grow older.

Also, keep in mind that your salary isn’t the only thing you can negotiate with your employer. Things like time off, work schedule, flexibility to work from home, job title, equity, commuter benefits, and many other things are all negotiable. And don’t have to wait until you change jobs to negotiate these things. You can negotiate these benefits with your employer today. At the end of the day, honesty is what matters when bringing these things up with your manager. If you’re more productive working from home one day a week to avoid the office distractions, let your manager know. They won’t know until you ask. And most likely it’s in their best interest to keep you happy and productive. It’s less expensive for the business than hiring and onboarding a new engineer to replace you.

Regardless of what priorities are most important to you, always remember that it doesn’t do you any good to compare yourself to others. Everyone progresses at different paces. Some people pick up new skills immediately. For others, it may take months to grok a new framework, and years to become proficient at a new language. New skills require new ways of thinking and approaching problems. It clicks right away for some people. It’s not a bad thing if it takes you a little longer. You’ll get there eventually if you stick with it.

And that’s okay.

These things take time. Just focus on yourself and what makes you happy.

This post was originally pubished on my newsletter Junior To Senior

Managing Emotions As A Programmer

David Glassanos — Mon, 28 Oct 2019 17:08:19 +0000

There's going to be times when you'll feel stuck. Your energy, drive, and emotion will go up and down over time during your career. Managing your enthusiasm during the day to day work as a programmer takes significant practice. There's a good chance you will go through many ups and downs. I’ve found that it helps to visualize it as a time-series graph of your emotional state over time. It's important to have a general sense of where you are in relation to your historical emotions in the past.

When I talk about emotions I'm talking about how excited you are to wake up and get to work on whatever project you're working on that day. Some days you'll jump out of bed because you're working on an exciting project. Perhaps it's something new you've never worked on before. Maybe you have to solve a difficult algorithmic problem or work on designing a new class or service. These kinds of projects are what get us excited to go do our job every day. Sometimes it might not even be the technical side of things. Many engineers thrive off of the positive feedback they get from the people who use their software, whether they're customers or internal team members. We all love recognition for our work, and times when the software you write gets praised, whether it's for the intuitive user experience, the simplicity of the interface, the challenging problem you solved, The critical bug you fixed, the magic that your code does to save the team hours, or even days worth of effort. There's a real sense of accomplishment when your efforts get recognized by other people. These are good times, and you should enjoy your accomplishments.

The day to day emotions are something you need to learn how to control though. One good day or one bad day at work won't make a difference in the short term. We all have bad days, but it's helpful to be aware of when you string together multiple good or bad days in a row at work. Maybe even one or two bad weeks, and things suddenly feel much duller. It'll get harder to get out of bed in the morning. You start dreading your commute into the office. There may be a coworker who is difficult to work with, and it's hard not to let it affect your mood in the office. There may be a bug in production you just can't seem to figure out. You'll want to bang your head against the wall because you're so frustrated. You've thought through every scenario and read over your code changes multiple times. Why won't the code work?

You'll feel like you're going insane. We've all been there. The faster you can learn to manage your emotional state during frustrating times like these, the faster you'll grow as a programmer. You'll learn sometimes the best thing to do is walk away from the keyboard. For small issues, this could mean going for a quick walk outside to get some fresh air. Other times it may mean calling it quits for the day and heading home. We often do our best thinking away from a computer screen. Some of the hardest algorithms or trickiest solutions have come to us while we're not actually thinking about the problem. It could come to you in the car during your commute, in the shower before work, or even in your sleep.

My point is, do your best not to let your frustrations take over. The work will still be there tomorrow. Walk away from the keyboard and give your brain a chance to recover. Managing your mental and emotional state isn't something you often hear, but it has a big effect on our career.

This post was originally pubished on my newsletter Junior To Senior

The First Few Years

David Glassanos — Tue, 15 Oct 2019 15:16:18 +0000

The first few years of your career will be an exciting and challenging time. One of the best pieces of advice to pick up in the early stage of your career is that you, and only you, are in charge of your own destiny. The field of programming is so broad, it will feel overwhelming. It's one big choose-your-own-adventure story, and you're the main character. There are hundreds of programming languages, frameworks, databases, and programming paradigms available. So how do you know which direction to go?

The easy answer is that any path you decide to take will be the right one. That's true, to an extent. First, you should always learn the tools, languages, and patterns you enjoy the most. Chances are that you are most productive when using these tools. You will soon gain enough experience to know when a certain tool is the right one for the job. You'll hear many opinions about which tools you should use, and why they're the best. In the end, you should do your due diligence and make your own decisions about which tools to pick up. Play around with different languages. Build a proof of concept to kick the tires a bit. The only way you'll be confident in your decision is if you test-drive the tools yourself.

The harder answer to the question above, is that you should take a good look at your industry, whichever one that may be. What are the languages that are primarily used? Moreover, you should try to understand why the big players in your industry use those tools. What advantage does it give them? Research the popular frameworks or libraries for a programming language, and try to understand why they're so popular. Try to understand the drawbacks of these tools, and when to consider using a different tool.

You should push yourself to reach an advanced understanding of at least one of the popular languages used in your industry. Do you want to focus on programming the web? You'd better learn Javascript, and probably one server-side scripting language. Want to work on mobile development? Well, you can choose between Swift for iOS or Java/Kotlin for Android. Want to work on hardware and embedded systems? Better get familiar with C or C++. Want to get into game development? Research what languages the big game development companies are using. While those are a few examples, you should always know what tools pay the bills in your industry.

It will take years to master your first programming language, so be patient. You'll learn a lot through observing your more experienced peers at work, and understand how they use (and abuse) the programming language. Ask questions. Ask lots of questions. But don't ask too many questions. I'll explain more about that in a later post, but for now, know it is completely up to you, and only you to master your tools. Your manager will have an incentive to help you develop your skills and level up as an engineer. It pays for companies to invest in their employees, but that doesn't mean all companies will. You may luck out and land in a company that encourages career development, or you may not. Your best bet is to not assume anyone else will guide you or your career where it needs to go. Your career path is completely up to you. My advice is to stick with programming languages that pay well in your industry and give yourself a couple of years to master the language.

This post was originally pubished on my newsletter Junior To Senior. Sign up now so you don’t miss the next issue.