The best career advice I’ve ever gotten

This is a guest blog post, lightly edited, from Josh Doody. Enjoy.

Dear new developer,

Let’s talk about jobs.

My first job

I was 25, and I wanted to move my career along as quickly as possible. I had my first real job, and had gotten three raises and a promotion in only two and a half years, nudging my salary up 12% from when I started. I was feeling pretty good.

Then two things happened that changed my career’s trajectory. First, my boss told me that striving for big raises and promotions would get me nowhere. “The way things work around here,” he said, “is you might get a big raise one year, or even two raises, but they’ll eventually work out so that you’re right back at the average. It’s hard to get ahead or fall behind.” He meant that I might be on top now, but eventually I’d regress to the mean. My boss had been working at the company for 30 years, so he knew what he was talking about. Ouch.

Second, I had been begging for a new challenge and just hadn’t gotten one. I had been looking for ways to stay interested, but got more and more bored, so I asked my boss for a new challenge. He eventually offered me a new opportunity: the same work I had been doing, but in a crummier location. I asked if we could keep looking.

A couple of months later, my boss came to me with yet another opportunity: I would move to a different building and redraw schematics for a 20-year-old piece of test equipment. I could hardly believe it, but he’d actually found a worse position than the one I’d already turned down.

But he made it clear that I couldn’t keep saying no to these opportunities—I was being too picky, and it was making both him and me look bad—so I reluctantly accepted the position.

I moved from a building where I had tons of friends and a 10-minute commute to a building where I had no friends and a 40-minute commute. The clock was ticking on my time at that first job.

Looking for something new

I started looking for a new job for two reasons: first, I needed to get out of there; but second, I wanted to know if I was over-valuing my abilities. I was young but self-aware enough to realize that one very plausible explanation for my frustration was that I just wasn’t very good at what I was doing. Maybe my boss was in the uncomfortable position of having a really ambitious, but really ineffective employee on his hands. Maybe he had done everything he could to pacify me without putting me on an important project that I would just screw up.

Around this time, a friend reached out asking if I knew any web developers looking for work. I told him that I did know someone…me! I had a little bit of web development experience and after we talked, he suggested I might be a good fit for his startup’s client services team. I interviewed with the company’s CCO and he offered me a job as a Project Manager. I had also been interviewing for a managerial position in a different city and, although I didn’t get that job, those two opportunities reassured me that I was a valuable enough employee to take seriously. I happily took the Project Manager job at the start-up.

Before I could start my new job, I had to wrap things up at my old job. Ironically, my manager on my temporary project (redrawing old schematics) had been the best boss I’d worked for my whole time there. On one of my last days, as we were looking over some schematics, he gave me the best career advice I’d ever gotten:

Josh, your first job is where you get your first job. Your second job is where you get experience. Your third job is where you get paid.

My second job

My second job meant a career change from electrical engineering to project management. I took a small pay cut, but that was completely reasonable considering I had no client-facing experience. I went on to work there for five years, scratching and clawing my way to a slightly higher salary than I’d been making as an engineer.

Of course, the money wasn’t what I was after—I wanted experience, and I found it by pursuing unusual opportunities, including a “special project” that ended up being crushed after nine months and getting me laid off. But they soon hired me back to work in a different capacity, which again provided great experience for slightly less pay. This position marked my second pay cut since starting my career, and I was making exactly the same salary I’d made as a test engineer, five years earlier. But by then, I had amazing experience and was in a position to move nowhere but up.

After five years in my second job, I finished up my MBA, which I’d been pursuing on the weekends. I decided to quit and take some time off to travel, relax and recharge.

My third job

After my hiatus, an old colleague from the start-up reached out from a different company: “You looking for work?” I was, and my experience landed me my third job, where I would make almost 30% more money than I had been making when I quit the start-up eight months earlier. Just like my sage manager said, my third job was where I got paid.

I’m glad I heard that advice during my first job, because it allowed me keep putting in time when things got tough. I knew that getting paid was inevitable if I continued to do good work and gain experience. That advice allowed me to stop obsessing over raises and promotions and start focusing on trying new things and building my resume so that when I did encounter a lucrative opportunity, I would be ready.

Sincerely,

Josh

Previously published on JoshDoody.com

Josh Doody is a salary negotiation coach who helps experienced software developers negotiate job offers from big tech companies like Google and Amazon. He also wrote Fearless Salary Negotiation: A step-by-step guide to getting paid what you’re worth to help software developers navigate job interviews and salary discussions to earn more throughout their careers.

How to manage one to ones

Dear new developer,

Hopefully you’ll work in a place where you’ll have regular one to ones with your manager. I find these helpful for building a relationship and engaging with your manager and your reports (if any). I even did them with my co-founder when I founded a startup.

These meetings tend to be 30 minutes and on a regular cadence (weekly, biweekly or monthly, typically). If you are face to face, you can have them in the office, but going for a walk or to lunch is a great way to mix it up as well. If you are doing them over video chat due to being in different locations, it’s best to have a great internet connection, a quiet space and video turned on. There are nuances you pick up via someone’s face that you’ll miss if you only have their voice.

The purpose of these meetings is to keep communication lines open for both parties. It also helps both parties get to know each other as people. People generally react poorly to surprises and stress, but building the relationship and communication practices before any of these situations arrive (and they will) will help the team to navigate them.

It’s worth stating that as a new developer, you probably don’t have a lot of influence over many things. In fact, you might not even have a one to one. If you don’t, the first step is to ask for a regular meeting with your supervisor. You can start with a monthly 30 minute meeting, which shouldn’t be impossible to schedule. I’d frame this request in terms that are helpful for the company and your supervisor:

I want to understand where we are heading
I want to know how I can best help you and the company
The insights I gain will help me be more effective in helping the team

If you do have a one to one, you can use it to share knowledge and gain understanding. Here are some tips for making the most out of your one to ones as a new developer.

First, schedule (or ask for) regular meetings at a time that works for both of you. Be cognizant of each other’s schedule (does someone like to get up early or work late? Are you in the same time zone?). Scheduling these back to back can be helpful for a manager. And scheduling them outside of “in the zone” blocks of time can make sure that there’s time for other work to be done.

The fact that the meetings are regular is important. They don’t have to last the entire scheduled time, but the manager should never cancel them, and if they must be rescheduled, do that promptly. (This meeting is very important for you as a new developer, and the manager should treat it that way.) If your manager is stretched too thin or is for whatever reason not treating this like an important meeting, suggest decreasing the frequency.

Regular meetings establish the relationship. If the only time you are meeting with your manager is when there are issues, you need guidance on work to be done, or at your performance review, that relationship won’t have the time to grow.

As the employee, come to a one to one with your agenda. I use a google doc in reverse chronological order, with the current meeting at the top. If you can, share this with your manager. Over the week or weeks between your meetings, add items to this doc. This can include items such as:

How should I have handled situation XXX?
I’d like to learn more about NoSQL databases; what are the opportunities at this company?
I’m struggling with XXX, do you have any suggestions?
What are the challenges you see facing our team during project YYY?
I heard a rumor that we’re opening a London office; is there anything you can tell me about that?

In general, topics should be about professional challenges, discussions or opportunities. Some chitchat about what you each did over the weekend is good social lubricant, if you both feel that way. (I’ve struggled in the past with connecting to reports, but found that discussing their out of work interests can lead to good conversations and a stronger relationship.)

I like to record action items for myself and the other party right in this google doc (sometimes the action item may be as simple as “bring this up again in three months”). This means that when the next one to one comes around, I can see what we discussed last time and if there was any progress. This doc is also great for preparing for your performance review, sharing with a new supervisor, or even just to see what you’ve done or been concerned about over time.

Another thing that I’ve had to learn over the years is that one to ones are a great place for me as an employee to ask for what I want. It’s awkward for me, because I’m a people pleaser at work, but if I don’t ask for what I want or need from my supervisor, how will they know? Now that doesn’t mean you can ask for the moon, but if you see opportunities in adjacent areas to your current work, ask for them.

If you see technologies that you think would make everyone’s lives easier, ask if you can investigate them. If you see a conference or other educational opportunity, ask if there’s money for you to attend. I remember at my very first job, I was interested in learning about databases and database administration. I asked my supervisor about doing a three month internship in that group, and they let me do so. I learned a lot about the data driven mindset during that time.

What is said in a one to one should be kept private, unless sharing it is discussed and both parties agree. Keep the agenda doc between the two of you. I think this article, “The 1-on-1 Disclosure Framework”, covers the levels of privacy very well.

Finally, it’s worth acknowledging that there’s a power differential in every one to one, based on the fact that the manager influences and/or controls the employee’s role, salary, and job. This meeting isn’t about being buddies or friends, but rather about building the person to person relationship that will allow both parties to thrive and help the company with its goals.

Sincerely,

Dan

Three principles for guiding your development career

Dear new developer,

I thought this article nicely laid out three principles to guide a developer’s career.

They were:

follow your taste
find community
take risks

Each of these really resonated for me. The first because the wide world of software can lead to analysis paralysis, so you should really have some way of deciding what you want to work on. When you are starting out you don’t have too many ways of doing so. Taste is better than random choice.

I’ve already written about the benefits of finding community (online or offline) and how it can help you grow.

Risk is an area I haven’t covered much on this blog, but in my own career I have overvalued stability. If I had it all to do over again, I’d take more risks, because I fall prey to overestimating the impact of failure on my life. (Of course, that’s easy for me to say looking back.) An example of that is that I waited until I was in my 30s to really commit to a startup; I had the skills to do so earlier, when it would have been easier financially, but I was too afraid to give up the stability and money of the consulting I was doing.

Here’s an excerpt from the article about following your tastes:

The default path is to follow what’s popular or prestigious. That can lead to a bunch of problems: What’s prestigious is already highly competitive. When you compete with smart people in a game that has established rules, just keeping up will take most of your time. That leaves little time to explore what interests you. When you don’t explore what interests you, you won’t understand things as deeply, and that leaves you with an undifferentiated skillset.

The whole thing is worth reading.

Sincerely,

Dan

On mid-career challenges

Dear new developer,

I really liked this post on mid-career challenges. I know you’re new, but you’ll be mid-career before you know it!

I’m in a position right now where I have to figure out what comes next for me and how to navigate the challenges of getting there. I made it to senior engineer, I wrote a book, I spoke at a bunch of conferences, switched from ops to dev back to ops again — so now what? For some people, mid-career looks like figuring out what your next set of career goals might be, what you might want your next 10 years of work to look like. For others, it might mean changing careers — you might be in a position where you’re quite senior in terms of core skills such as communication, team dynamics, and project planning, but you came into tech from another field so your coding skills still have leveling up to do.

As you get your legs under you as a developer, it’s worth peering into the future so you can set yourself up for success. Setting goals is part of that. So is learning from other’s experiences.

As usual, the whole post is worth a read.

Sincerely,

Dan

Manage your career

Dear new developer,

You have to manage your career. If you don’t, no one else will.

This means three things.

Know what you want.
Communicate that.
Make moves toward it.

Let’s talk about each of these in turn.

“Know what you want” is the hardest part. Because we are lucky to live in a world with lots and lots of options and opportunities. You can focus on one of a 100 different kinds of software development. And that is to say nothing about other related opportunities (product management, teaching, engineering management, etc) where your developer skillset will help set you apart.

My advice here is that you should pick one and follow it while it is interesting. If you have fundamental skills (problem solving, learning, listening, typing), you’ll be able to transition between areas. It may not be an easy transition and you may pay a price in terms of compensation or status or ego. You may have to spend precious time outside of work getting up to speed. But no decision is permanent. So pick what is interesting. Commit to it for a period of time (six months, a year). Realize that you can change (though, as mentioned above, that may have a cost), so commit.

“Communicate that” because if you don’t talk about what you want, you will have a hard time getting it. This is because people generally want to help, but need to know how to help. So, communicate your desires to your manager, to your communities, to your friends, to your co-workers. You don’t need to mention it every day, and you should tune your communication to your audience.

For example, if you are a web developer and want to be database focused, then volunteer to work on database projects. Mention it to your manager at your 1:1s. If there are people that are doing database work at your company, ask if you can meet them regularly.

This doesn’t mean you can avoid the web development work for which you are paid. What it means is that you can tune your work environment toward your interests. Not immediately and not at all companies, but often.

“Make moves toward it” means you aren’t just talking about your desired direction, but you are actually taking steps toward acquiring skills and doing that work. To expand ont the web developer -> databases example, take action. Present on databases at a meetup. Do a brown bag on databases at your company. Read a book about databases. See what you can apply to your current work.

However, sometimes you can’t make a move internally. Maybe the opportunity just isn’t there. Maybe the company needs you in your current spot. You may have to switch jobs. That’s OK.

Don’t burn any bridges, but when it is time to move on, move on. Find a new job with your new skills and knowledge, hopefully from the community you’ve found. Give notice and head off to a new adventure. (Don’t forget to connect to colleagues on LinkedIn.)

What’s the alternative? Floating through your career, buffeted from opportunity to opportunity, or worse, from job you’re afraid to lose to another job you’re afraid to lose.

That doesn’t sound like much fun.

Sincerely,

Dan

A bunch of career advice from a new developer

Dear new developer,

This post has a lot of great career tips including how to select companies to apply to, what to do in an interview if you don’t know the answer to a question, and how to challenge yourself in a new job. This piece of advice in particular resonated with me:

Show how you think

Most interview questions are there to see how you think. So show that! Explain your thought process, draw diagrams, write out the intermediary code, explain pitfalls in your approach, etc! Be vocal, and ask clarifying questions. That’s part of being a good developer after all!

When I was hiring, especially for newer developers, I really wanted to hear how people thought through a problem. That process is important in two ways beyond actually solving the problem. The first is that it shows how you handle something tough that you haven’t encountered before (which happens almost every day on the job). It also shows an interviewer how you communicate. Since a lot of the challenge of building software is communication, learning how potential team members do it is crucial.

The whole post, “The Career Advice I Wish I Had” is worth a read.

Sincerely,

Dan

No choice is permanent

Dear new developer,

Sometimes when you are thinking about a new job or shifting to a new position in a company, it can feel overwhelming. What if I make the wrong choice? At least, I’ve often felt that way.

Every choice you make has effects. When you choose to study ruby, you can’t also study python (opportunity cost!). When you work at a company, you will learn how that company works, but not about how other companies work.

I sometimes have FOMO (fear of missing out) when I commit to one path. “What would have happened if I had gone down another path?” I wonder.

That’s OK. I think it’s human. But you still have to make a choice.

I remember talking to a friend once about making decisions. She said that she likes to make a decision as late as possible. I think this is a good practice. Gather the data you need and can get without asymetric effort (that is, the larger the issue is, the more effort you should put in–I should invest more effort into learning about joining a new company than I should into learning a new project within the same company, for example). Make the decision as late as you can, because you’ll learn more as time goes on.

However.

It’s also important to realize that few decisions are permanent, especially as a new developer in your career. You’ll have flexibility in terms of geography, type of company, type of job, size of company, business domain. Some shifts may be easier because of your history and the aforementioned effects (shifting from being a web developer to being a backend engineer), some may be harder (changing from a web developer into an embedded systems engineer), some may be well nigh impossible (changing from a web developer into a compiler developer), but some change will be available to you.

What this means to me is that decisions which seem crucial, critical, life-changing, are, but that if you make an incorrect decision you can change. And that, for me, takes some of the pressure off.

Sincerely,

Dan

PS, as Kendall pointed out, there are some decisions that are essentially permanent. But most career decisions aren’t.

Types of companies that use software

Dear new developer,

In my experience, four types of companies use software. Software is as prevalent as accounting, so every company uses it in some way.

Those that sell software to help build software, software product companies. Examples from my career: Oracle.
Those that sell software, often called product companies. Examples from my career: The Food Corridor, Katasi.
Those that sell hours or knowledge of developers and other software professionals (PMs, designers, etc). Examples from my career: XOR, Culture Foundry.
Those that sell anything else and use software to help. Basically almost every other business. Examples from my career: 8z, Phoenix Enterprises.

As a new software developer consider where to seek employment, they each have strengths and weaknesses. It’s worth talking about these so you can find a company that aligns with where you want to go (remember, every place has its warts).

Software product companies

Pluses:

You are the end user, so having user empathy is easy.
Software developers are highly valued within the organization.
Lots of focus on building out higher leverage software processes.
When successful, these companies have great gross margins and can afford good pay and benefits.

Minuses:

Developers often start companies like this, so there’s a lot of competition.
Jobs are desirable, so may have a long interview process with a lot of hoops.

Product companies

Pluses:

You can go deep into a particular business domain.
Software developers are key components of such a company’s success, and are treated like it.
They often have recurring revenue and a business model that allows for good pay and benefits.

Minuses:

Can be harder to get hired than in other types of companies because jobs are more desirable.
May be boring to be in same domain for long periods of time.
May use older technology depending on the age of the company. Legacy systems make money!

Consulting

You often skim domains, so you can get some variety of experience in different types of businesses.
Always new projects to be on, often means new technology to evaluate and learn.
An hour worked is often an hour billed, so your efforts are directly related to revenue.
If you are looking to go off on your own, these consulting businesses are easy to start (no overhead, no investment in building a product, you just need a laptop and an internet connection and someone willing to hire you).

Minuses:

As an employee, you need to realize that there is no real exit strategy for the founder(s). Which is fine as long as the founder is still interested in running the business.
There is limited recurring revenue, which means that the business goes through cycles of grow -> shrink -> grow -> shrink.
Lots of lots of effort in finding new projects and clients.
Because of the sales cycle, it is hard to specialize as a consulting company, sometimes you take projects because you have to pay bills.
Can have tight deadlines and lower profitability, which affects your experience as a developer.

The rest

Pluses:

Often have stable businesses.
Software quality and process tends to lower in non software focused companies, making it easier to outperform competition.
Software quality could be competitive advantage.
You’ll have the chance to learn about and work in a non software business domain.

Minuses

Developers won’t be as highly valued at some other types of companies.
IT/software can be seen as an expense rather than a revenue generator, especially if not affiliated with revenue side of the business.
Sometimes you may be alone or in the company of expert beginners.

Each of these types of companies has different strengths and can be a good fit for you early in your career. Consider what excites you and what is available in your job market when you make the choice. It’s also worth reminding yourself that since as a new developer you’re judged on potential, any choice you make to go into one type of company or another isn’t permanent!

Sincerely,

Dan

Speaking isn’t as scary as you think, eventually

Dear new developer,

I remember one of the first times I spoke in public. I was talking about J2ME (which was a technology for building mobile apps, pre iphone) to the Boulder Java Users Group. I threw up some slides showing the flow of data across the system, and made a joke along the lines of “sorry if this is confusing, but at least it isn’t UML”. The audience all laughed, and I went on with my talk.

Guess who the next speaker was?

Grady Booch, inventor of UML.

Doh.

Public speaking is a great way to do a number of things for you as a developer.

Raise your profile in your company and in the community. Standing in front of a crowd and talking about a topic will get you noticed. Even if it is a crowd of 10 at your local meetup.
Teach you how to educate people. The way to help someone understand something is not intuitive. Speaking gives you a chance to practice it, and that will help you in your work life, since a large part of development depends on helping other people understand what you mean.
Force you to really understand your topic. Trust me, the pressure of being up in front of a group of people will cause you to dive deeper than you otherwise would have. (Kinda like writing an ebook.)
Let you learn something new. Related to the above point, you can learn something new when you are presenting. This can either be ancillary to the topic you are talking about, or, in some cases, can be the topic of your talk.

Some tips for getting started:

Find something you are interested in. Brainstorm ideas around that. Think about cross sections: “Using javascript in marketing” or “what do SQL and devops have in common”. Both technical skills like javascript, SQL or design and “soft” skills like interviewing and communication can be good topics.
Join a meetup. Go a few times as a regular member, learn who the organizers are. Then go to the organizer and say “I’m a new developer, but I’d love to speak sometime. Do you have any slots open?” (You can also join Toastmasters.)
When you get a chance to talk, practice it multiple times, at least once in front of someone. Remember that you are likely the most expert person in the room. If possible, start off with a joke or self deprecating remark, and ask for audience participation. More tips.
Look for local conferences. Then, look for Calls for Proposals (“CFPs”) at such conferences. Submit. Don’t spend too much time polishing a submission. Submit any proposal to multiple conferences. Papercall is good for that. (I confess, I’m not an expert at this process, so this is more based on advice I’ve read.)
When you go to conferences or meetups, walk up to speakers and ask how they got started. I’d suggest avoiding the superstars. Regular speakers will still have useful advice, but fewer folks surrounding them.

By the way, it is terrifying, but many things are the first time you do it. I mean, do you remember learning to ride a bike?

Public speaking is a great way to stretch yourself, learn new skills and meet new people. Highly recommended.

Sincerely,

Dan

Benefits of blogging

Dear new developer,

I’ve written before about my belief in blogging as a way to sharpen your thoughts and give examples of your expertise. Here’s a post along the same lines. From the post:

People always try to find someone they can trust. You can go through a series of interviews and hope that they will figure out you are a great colleague, or you can write about your approaches and let a wider audience know that.
If you have a deep expertise in some technology, you can demonstrate it by writing deep and thoughtful blog posts.
If this technology is in demand, you will definitely get some opportunities coming your way!

And

Your views expressed publicly can be a good conversation starter.

This may come handy in any professional social context: interviews, meetups, conferences. It’s a different level on conversation when you get approached because someone likes your views.

The author then goes on to talk about specific, measurable ways that his blogging has helped his career.

The whole post, “Is blogging useful?”, is worth a read.

Sincerely,

Dan