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, three 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

Write a brag document

Dear new developer,

You will encounter good managers and bad managers in your career. I’ve found that one common thread for all managers is that they are busy. Busy with meetings, busy with coordination with other teams or parts of the business, busy putting out fires, busy with helping team members. Busy busy busy.

They also will likely be responsible for your career. Promotions, compensation increases, title changes. A good manager will want you to be challenged and grow and learn.

However.

The only person who really cares about your career is you.

You can help your manager help you by helping them know what you do. Sometimes this feels like an undue burden. Surely your manager can keep track of what you’ve accomplished on their team. And some do know some of the stuff you’ve done, some time.

But what you want is to help them know everything that you’ve done that you’re proud of. This helps them understand what a great team member you are, and also gives them ammunition to fight for resources (money, projects) that you deserve.

One place to put this information is in your LinkedIn profile (more about my opinion on LinkedIn). Of course, make sure you don’t reveal any company secrets (projects, launches, technologies) in this.

Another alternative is an internal brag document. Julia Evans has written a great post on writing one. This outlines one way you can help your manager (and yourself) keep track of all the great work you’ve done. It can be far more detailed since it is internal and not limited in length.

It’s not just limited to project accomplishments. You can build a bigger story. From the post:

In addition to just listing accomplishments, in your brag document you can write the narrative explaining the big picture of your work. Have you been really focused on security? On building your product skills & having really good relationships with your users? On building a strong culture of code review on the team?

I haven’t written one of these (although you could consider my blog somewhat of a brag document, I suppose. Yet another reason to start a blog). But having some kind of record of your accomplishments that you can share with your manager will help them help you.

Sincerely,

Dan

Someday, You Won’t Want To Code For A Living

Dear new developer,

I remember the first full time coding job I had. I was able to¬† work on a great team, on interesting problems. I was able to get into the “flow” that is such a magical state. I was paid well. I had free snacks.

I remember going into my manager’s office and chatting with him. He seemed a bit stressed. He was constantly interrupted. He had lots of meetings. He seemed to want to code, but didn’t have time for it.

Me being the naive young optimist, I asked him once why he wasn’t coding. Why would he leave a really fun job for management?

He looked at me with a knowing smile and said something like “one day, you’ll understand”.

I don’t code for a living now. Oh, sure, I write some code. And it still gets me into flow. And I still enjoy it.

But the honest truth is that when I am coding, I have the leverage of one person. As I grow older, I grow more impatient to effect change in the world. The best way to effect change is to have more leverage. Some options for higher leverage:

  • writing
  • project management
  • product management
  • speaking
  • mentoring
  • leading a team
  • managing
  • teaching
  • architecting
  • consulting

Most of these involve communicating about coding (or other technical systems), but coding is not the primary work output. Instead, the emphasis is on knowledge or alignment of a team.

Now there are also code specific ways to get more leverage. Two that I can think of.

  • work on really big systems that have a lot of users (FAANG companies, or something similar).
  • work on open source libraries or projects that have a lot of users

If either of those floats your boat, then pursue that. I don’t like the first because I don’t really enjoy the bureaucracy and politics of big companies. I am not a fan of the second because I don’t really enjoy working for free.

By the way, no one says you have to have leverage. I’ve just seen that happen again and again across many companies and many individuals. Part of that might be the crowd I run with, but part of it might be that more leverage typically means more pay.

Your career is long. My guess is that one day you won’t want to code for a living. Enjoy it now, but keep your head up and think about what other areas, focusing on communication or team alignment, might eventually be of interest to you. Learn about those areas. Meet people who are currently doing them, and ask questions.

Sincerely,

Dan