Most people don’t write code just for fun, though programming can be a joy. They do it because it’s a good job. One position leads to another, and soon you have a career in software development.
It happened to me.
Your progression as a software engineer is in your hands. There is no licensing authority. The equipment required to learn a new skill is often an Internet connection, a computer, and time. The scope of software engineering work is wide. Embedded systems running elevators, web applications helping people with their jobs, or gigantic globe spanning architectures—all these are built by software developers. If you consider the rapid evolution of the state of the art in software development as well, the possibilities are endless and shifting. You need to determine your career goals and work toward them.
In this chapter, we’ll cover such topics. There’ll be tactical letters about interviews and one on ones. We’ll also look at strategic choices such as ignoring the sound and fury of the Internet and the value of authenticity.
Favor learning over earning
Dear new developer,
I suggest that the first job you take be the one with the highest learning potential, not the largest salary. Positions which aren’t as lucrative will set you up for success later in your career.
Of course, this means the best job for you depends on what you want to learn. If you want to experience working directly with clients, a consulting company is a great place to start. If you want to experience autonomy, rapid change, and chaos, join a startup. If you want to work on deep technical problems, consider a large company with more complex systems.
If you are the sole technical team member, you might be paid more but will learn less. If the plan is to add team members, this may be an adequate situation, if temporary. However, if the business doesn’t grow as expected, the team may not grow either.
If you work alone, beware of stunting your growth. It’s hard to improve when you don’t have other team members to challenge your ideas. Meetups and online communities can help with this, but nothing beats a teammate working in the same codebase.
No one dislikes money. I like money, and I bet you do too. But over-optimizing for initial salary rather than exploring your options is a foolish choice. You may have constraints—family obligations, student loans—but within those, look for teams that will help you improve. Ask about growth during interviews—and not just formal plans; look for results. Did your interviewer start with the company as a new developer and grow into their current role? Are there team members a few years ahead of you in their careers at this organization?
The goal of your first few jobs should be to learn as much as you can. By doing so, you invest in yourself. You’ll make more intelligent choices later, be more valuable to future employers, and have a better idea of what you like. When you have a choice, pick the job where you will learn the most.
You don’t have to know right away what kind of education you seek, either. In fact, your first few jobs might be very dissimilar. In the first decade of my career, I worked at a consulting company, then as a contractor, then at a startup, then again as a contractor (startups, as mentioned, are chaotic), then at a small product company.
In each case, I learned more about what I liked in a company, a boss, and a business domain.
Sincerely,
Dan
You will never be in a better position to leave a bad job than before you start
Dear new developer,
Interviewing is a two-way street. That means that you, the candidate, need to be evaluating your employer as much as they are assessing you. Yes, you need a job, but your employer needs your skills; that’s why they are hiring.
You’ll never have more leverage with a company than you do as a candidate. Why? Because when you are interviewing, you can talk to multiple potential employers. If someone acts like a jerk during an interview, it’s a hassle, yes. But compare that to having the same person as your manager. In the latter case, you’ll be looking for a new job during your precious weekends, at night when you’re exhausted, or during your lunch hour. Or worse, you’ll stay in a job where you are miserable.
If they don’t treat you well during the interview process, when they’re trying to convince you to join the team, how will they conduct themselves when you are an employee and don’t have any options other than finding a new job?
This means you must invest time to learn about possible future employers. Search the Web for information—just realize that you may need to take what you find with a grain of salt. I once published a blog post about the development process at my employer—how information was transmitted from client to project manager to developer, how the work was done, and how project status made its way back to the client. The post wasn’t a lie, exactly, but it documented how the process worked when everything went swimmingly. And, unfortunately, things didn’t always go well. Plus, last I checked, it was posted on the company website, even though I know the process has evolved.
Job descriptions also can be misleading. In fact, I’d say in the job descriptions I’ve written, about 30% of the description didn’t apply to the candidate I hired. What? The extra text was there because I was seeking perfection, but I have never hired anyone with all of the desired skills. Every potential employee is missing a chunk of what’s needed; it’s just a question of which 30% they don’t have. I always leave the extra requirements in to attract candidates with different strengths and weaknesses. It’s frustrating, but hiring is frustrating for everyone involved. In any case, once you become an employee, the job will also change based on your skills, interests, and company needs.
To learn about how things work at a possible employer, reach out to people you’ve met in your network and ask. Look on LinkedIn to see if you have any connections, however tenuous, who have worked at this company. Ask these folks about the good and the bad of this organization. You are going to spend a lot of waking hours at your job, so spend the time before you interview.
Interviews are hard to do well. They are designed to extract as much information as possible in a short time period. Companies want an accurate hire/no hire decision. Good employers, however, want a bidirectional information exchange. This can happen in a few ways: by allowing plenty of time for questions during the interview, having a discussion in a casual environment like lunch, or having individual contributors on the team participate in the interview.
During the interview, if the schedule doesn’t allow time for your questions, make sure your interviewer knows you have some. If it hasn’t already been mentioned, about 15 minutes before the interview is scheduled to end, say something like “I want to be respectful of your time. The interview is scheduled to end in 15 minutes or so. Is this a good time to ask you some questions?” If they don’t respond politely to this request, well, that’s more good data.
What are the best parts of your job and this company?
What are current challenges you or the company face?
Why do you believe in this company?
What does success look like for this position?
These are all good standbys. However, don’t ask them if they’ve already been answered earlier in the interview process. You can incorporate a previous answer into a question, though. This illustrates your attention to detail: “You mentioned earlier that the upgrade to Kubernetes 1.16 was a large challenge for the team. I was wondering if it was because of communication difficulties or a particular technical issue?”
Is the interviewer prepared and respectful?
Does the interview start on time?
Is it a real conversation or are you being grilled?
Does the interviewer appear happy and enthusiastic?
Is the company communicative regarding deadlines and expectations or are there surprises?
Does the company ghost you?
Do people do what they say they are going to do during the interview process?
Are they flexible during the interview—what happens when something unexpected arises?
How do they respond to your questions?
Do they keep in touch after the interview until you’re either hired or passed on?
Do they ask you to do a large take-home project, especially without compensation?
These all paint a picture about the company and the position. Note that none of these signals relate directly to the technology or work you’ll be doing. That is important as well, but the context in which you work is crucial. If you are being paid $200,000 per year in a job that makes you miserable, you will be unhappy. In contrast, if you are paid a yearly salary of $100,000 working with a team and a project that you enjoy, you will be happy. These numbers assume that you can live well on either salary—feel free to double the numbers if that isn’t the case.
You will never have more power in the employer/employee relationship than when you are interviewing. Even though it is stressful to have no income, this is the point you have the most optionality to pursue a different job. One exception worth noting is when the job market is bad and you’re looking for your first position. In that case, I’d recommend taking any position working with software. It’s far easier to find another engineering job when you’ve had any amount of professional experience.
Poor interview treatment indicates, in my experience, a general lack of regard for employees. This leads to other unpleasantness, such as no commitment to or budget for professional development and considering developers “resources” to be shunted between projects.
You will never be in a better position to leave a job that isn’t a fit than before you start. An interview is the right time to make sure you learn enough to avoid jobs that aren’t for you.
Sincerely,
Dan
Pick a flaw, any flaw
Dear new developer,
Every company has its warts, also called flaws, issues, problems, or challenges. I have never met anyone who worked for the perfect company. Join an organization with your eyes wide open and choose the warts you can live with. You may be able to help solve some issues, but others are permanent. Some are fundamental parts of the company’s business model. For example, I have worked for multiple consulting companies. I hated keeping track of hours, but this task was core to the company’s economic model; developer hours were the product the consulting companies sold and therefore had to be precisely tracked.
One wart to avoid is an indifferent team—one punching the clock and only trying to get through the week. If a company is full of people who don’t care, you’ll have trouble fixing anything else. Customers will be an afterthought. Work will drag. It’s unfortunate, but places like this exist.
That’s not to say that a place where people care will be only unicorns and cotton candy; there will still be problems. But at least employees will be trying to fix issues and serve customers.
How do you improve processes?
What do customers love about what you do?
What changes have you all struggled with over the past year?
How do you keep up to speed on the newest technologies?
If the answers to these questions indicate apathy, then I’d avoid that employer. If you are already there, make plans to leave.
Another wart to avoid is nonsense. Unlike apathy, the definition of nonsense varies from person to person. Some people can’t stand politics, while others can’t stand shifting priorities. Some are frustrated by rigid hierarchies, while others need to know where they stand. I’m averse to politics, myself.
It will take you time to learn which nonsense disheartens you and which you can tolerate; try to distinguish the frustration you feel because you’re being pushed to grow in a new environment from the sinking feeling in your gut telling you you’re in the wrong job.
What’s a typical day like?
Who makes decisions about priorities? How are those decisions made?
What kind of projects does this place shine at?
What are the best and worst parts of your job?
No job is perfect, but by keeping an eye out for warts you can’t tolerate, you’ll be able to find an employer who matches what you need.
Sincerely,
Dan
Preparing for a recruiting event
Jeff Beard is a director of software development at Oracle Data Cloud. He would also like to acknowledge Caitlin Hickey and Mridula Natrajan for their help editing.
Dear new developer,
Preparing for a university job fair or similar recruiting event is very important if you want to make an impression that results in a phone screen.
A hiring manager and their recruiters receive an enormous number of contacts and resumes from a variety of channels so you have to be able to stand out from the crowd in a very short amount of time, often measured in seconds.
However, when you are at a recruiting event, you have a unique opportunity to make an impression since you will get to talk directly to a recruiter or even a hiring manager. So you need to be fully prepared to exploit that short window of opportunity.
Resume
The introduction
The conversation
Appearance
Resume
A resume is something of a pitch deck that you use to get attention and tell your story. It’s also a notepad and reminder for a recruiter or hiring manager to go back to in order to find you in the huge pile of resumes they collect—or, sadly, to figure out what goes into the recycle bin now vs. later (it’s no joke: a desk covered with hundreds of resumes requires triage).
To begin with, make sure that you have complete basic information such as address, phone, email, GPA, and graduation date (for students) at the top of your resume.
Motivated
Passionate
Skilled
Adaptable
Collaborative
Articulate
The purpose of the project
Why it was important
Did you work on a team
How did the team self-organize
How you overcame challenges
What was the outcome
Why you liked the project
Importantly, what a good hiring manager is looking for is intrinsic motivation. We want folks that are naturally excited about the domain they are looking to enter for their career.
So put your favorite project at the top of the list and drive the conversation to that project if you can. The person you are talking to needs to see what lights you up, and there is native passion for your favorite project that you need to let shine through. The project description should be brief and to the point, with a focus on the “what,” “why,” and the outcome. A project description doesn’t need to be burdened with the tech used unless it adds to the overall narrative.
Projects don’t have to be school class projects or work experience. They can be side hustles, open source, personal interest, or hackathon projects.
If you haven’t done a lot of projects, take the initiative to find a couple of projects to work on. If you are in school or in your first job and it’s not producing projects that engage you, seek them out or invent them yourself. This will be reflected in your resume and will send a signal that you are curious and passionate about the domain and look beyond what you are doing day to day for interesting problems to solve.
One final bit of advice on resumes: Have more than one resume for different audiences. For example, if you are equally interested in DevOps and software development, craft two different resumes that highlight projects and work experience in each category. You can also optimize resumes for different industries to highlight aspects of your experience or interests that cast you in a good light for that market .
The introduction
The introduction is a critical face-to-face interaction that is your opportunity to form a connection with a potential hiring manager or recruiter. There is an incredibly short window of opportunity to impress the person, which means you need to say a few impactful words, delivered with confidence.
When you approach the company representative, reach out to shake hands while you say hello and start your introduction. People receive signals from a handshake so don’t go soft and don’t be aggressive. Just a firm, confident handshake will do the trick. Practice with friends.
I personally will listen for about a minute before I interrupt and direct the conversation to, say, the resume in a candidate’s hand, but it’s important to have a story that is concise, to the point, and well rehearsed.
The introduction should contain your name, your college program and graduation date (if appropriate), what you are passionate about, what role you are looking for, what your interest is in the company, and why you would be successful. It’s a brief statement of intent and a value proposition signal. You should practice saying it out loud often enough that you can deliver it with a practiced confidence, energy, and restrained enthusiasm while looking the person straight in the eye.
Don’t make assumptions about the person you are talking to; ask them what their role is at the company. If they are technical, this is an opportunity to signal your depth. If they are not, you can tailor the conversation accordingly.
Also don’t launch into a description of every item on your resume; exercise restraint and stay focused on a concise introduction that will lead into a conversation.
Finally, like resumes, you can have more than one introduction crafted for different audiences.
The conversation
Your introduction will lead into a very short, general conversation which you also need to be prepared for. If the introduction is the hook, then this conversation is closing the deal on a phone screen. (Note you are not closing the deal on a job or an interview, that’s later. You just want a second look which is what the phone screen is.)
You get it by handing the recruiter or hiring manager your resume to scan and ask their questions. Have a ready answer for everything on your resume including any questions about whether or not things went bad on a project or an obviously short tenure at one of your jobs.
You should also seek to align your interests with what the company does which requires research.
At most career fairs, there is a list of companies available ahead of time so you can research them and target the companies that do work that best aligns with your interests. If you aren’t sure about what your passions are or it’s hard to figure out what the company does, be prepared to put that out there right away. Some of the most awkward moments are when someone tries to improvise what they think my company does. Don’t improvise, do the research. It’s easy and pays dividends.
Just identify a few things that the company does to show interest and then ask about other things the company does and what market they operate in. What’s important is that you show that you are interested and motivated enough to do the research. This also helps with the common question you may get: “why do you want to work for Willard’s Widgets?” If you’ve done the research, you’ll have a good idea of whether you can honestly say that whatever they do is super interesting and you’d love to help the company be successful.
Other questions you can ask are “what is the culture like?” and “tell me about an exciting initiative at the company,” and as you wrap up the conversation, you could ask “when can I expect to hear back?”
To get extra credit, educate yourself on the industry that the company operates in. If you can speak intelligently about the major trends in a market and tie it to what a company does, you are instantly distinguished from your peers. Very few early-career candidates pay much attention to the business side of things, but it’s important to understand the industry you work in, especially as you mature in your career.
Appearance
No need to wear a suit; it’s not the norm for our industry except for executives (and even then there are a lot of hoodies and t-shirts in the wild). But don’t wear pajamas with bunny slippers either. Casual clothes that are clean and not shredded, a folder full of printed resumes, and a cell phone are what you need when you step up to the table to confidently deliver that well-practiced introduction.
If you are comfortable with it, you can add something colorful, or otherwise visibly interesting or memorable, to your outfit that makes you stand out from the blue jeans/black leggings and t-shirt crowd. Don’t be silly or obnoxious, just wear or add something visual and unique to your outfit or just make it more colorful in general. It provides something else for the hiring manager or recruiter to associate with a good conversation when they’re digging through a pile of resumes, trying to decide who to call.
Finally, job fairs can be taxing so make sure you take breaks and have access to snacks and drinks to power you through the event and keep up your energy levels.
Sincerely,
Jeff
The surprising number of programmers who can’t program
Dear new developer,
There’s a class of interview problems which aren’t difficult but exist to ensure someone who says they are a developer can actually write code. Yes, unfortunately, there are people who pretend they can develop software.
The canonical problem of this type is FizzBuzz. To solve this problem, you need to print the numbers from 1 to 100. If a number is divisible by 3, print “Fizz” instead of the number. If the number is divisible by 5, print “Buzz”. If both are true, print “FizzBuzz”.
A solution to FizzBuzz
I’ve been working since the 90s and I never attempted to do FizzBuzz. Is it really relevant? Maybe to screen junior developers out of college?
So, as someone who spends maybe 20% of their time hiring, it’s still a very effective screen. You wouldn’t believe how many people can’t do it. People at big companies, respected places. It’s surprising.
Over my career, I only can think of two colleagues who I believe couldn’t program a solution to FizzBuzz . One in particular I remember basically having to excruciatingly lead him toward every solution. The project was structured such that I, a contractor, had to work with him. It was no fun, but I gritted my teeth and kept my eyes on the goal of delivering for the client.
You will be competing for jobs with people who can’t program. Make sure you can.
If you are one of the folks who can’t program, fix that as soon as possible. Please. There are a lot of resources available online. Or seek a different type of technical position.
There are ineffective programmers who still manage to find jobs as developers. You may end up working with them.
Make sure you practice programming. This book doesn’t focus on the particulars of technical software development, but if you can’t do the basic work of coding, you’re going to have a tough time as a software engineer. Being a programmer who can’t code is like being a professional baseball player who can’t run. It doesn’t matter how good someone is at catching a ball or hitting, if they can’t run, they’re going to have a hard time succeeding.
Sincerely,
Dan
Start at a small consulting company
Dear new developer,
If you have a long-term goal for your career , work toward it. Whether the goal is mastering embedded programming, being a manager of a high-frequency trading team, or running a one-person web development contracting business, you can achieve it if you stay focused.
If the goal is your very first professional software development job, remember that to a large extent it is a matter of being at the right place at the right time. Keep applying and networking. Don’t be too fussy about that first job.
If, however, you are looking to gain experience across technologies, domains, and businesses, work for a consulting company. If, in addition, you want to have an impact, work for a small one. This is where I started. I didn’t really know what I was looking for, but I interviewed at large companies like HP. After college, I ended up getting an internship at a small web consultancy where I was one of the first 70 employees.
In this context, small means having between 10 and 75 employees. The lower limit of ten means the company is large enough to hire new developers and provide structure and support. Below that number, you’ll have more autonomy, but other employees may be too busy to help you grow.
Seventy-five colleagues or fewer means that every hire matters. It’s small enough that you’ll have a relationship with everyone else at your company. Larger companies have places for people to hide and avoid real work. Small companies just don’t have room for people not pulling their weight.
Consulting shops do a variety of work. If a project isn’t working for you, you can shift to a different one. If that option isn’t immediately available, you might have to gut it out for a few months. This is unpleasant, but a far cry from working on a product team you dislike for years.
Agencies are often hired for new projects, what is colloquially called “green field” development. This type of software engineering can be quite fun because there are fewer existing constraints on the system you are building.
As a consultant, you will get as much interaction with nontechnical folks as you desire; engineers with the ability and appetite for this are uncommon. You’ll also learn how to build software to spec and on (or to be honest, near) budget.
On the flip side, smaller consulting companies tend to lack formal education programs. You must actively seek out mentorship, request conference attendance, and pursue assistance. These are good skills to develop, but if you aren’t aware of the need, they may be overwhelming tasks piled on top of the actual work you were hired to do. Agency work can also be choppy, as projects start and stop based on the clients’ needs.
Working at a small consulting company allows you to acquire a wide variety of technical and business experience. If you do a great job and keep track of people you work with, it can set your career up for the rest of your life. A majority of my jobs and contracts over my career have resulted from the people I met at that first consulting position, two decades ago.
Sincerely,
Dan
Potential vs. delivery
Dear new developer,
Early in your career , you are judged on potential. When you are young in your career, you don’t have much of a track record, so there’s not much else to judge you on.
Make sure you’re exhibiting your capabilities to possible employers. Ask smart questions. Show you’ve learned your stuff. Say what you’re going to do and then do it.
However, because potential matters for the early years, you can take career risks. Explore different areas of software development—technology, business size, or domain. Each time you shift, you’ll bring useful experience, but mostly you’ll be hired because of your capacity and willingness to learn. Companies must train you on their process and their technology stack and, as a new developer, they don’t typically expect you to ship code on day one.
The more experienced you are, the less your potential matters, and the more you are assessed on your ability to deliver. The longer you are a developer, the more human capital, in the form of knowledge and experience, you possess. As a more senior developer, you are expected to deploy that capital. Your skill in doing so is assessed by examining your past accomplishments. The further along you are in your career, the more what you’ve done in the past is a harbinger of your future work.
Expect to demonstrate your experience during interviews. Outside endeavors such as contributing to open source are helpful. Don’t reveal any work secrets in these conversations but expect to address the problems you’ve helped solve in general terms.
Periodically, or when you complete a project, take a few minutes to write down lessons you’ve learned. I blog, but a private journal works just as well. Then you can review this record before interviews. When you’re asked “what is a difficult project you’ve worked on?”, you’ll have a cogent answer. Plus, you now have a personal retrospective; if you look back over past work and can’t pinpoint any achievements, you may be in a job where you aren’t progressing.
Even as an experienced developer, you won’t necessarily be expected to commit code your first day. You’ll need to learn how systems work. In fact, the bigger the company, the longer the spin-up period; I worked at a large software organization where people were surprised I expected to ship any code in the first week of my contract. But when you are an experienced developer, you need to slot in to your team and pick things up more quickly than a newer developer.
Once you’re a senior developer, does that mean you cannot switch domains, tech stacks, or employer size? Absolutely not. But it does mean that you’ll have a more difficult time doing so than a newer developer would. You’ll need to convince hiring managers that your skills apply to the new position. A great book about making this type of switch is What Color Is Your Parachute by Richard Bolles.
The more experienced you are , the more constrained your choices become since you’re judged on your past achievements. Take risks early.
Sincerely,
Dan
Maintain work-life balance
Dear new developer,
Preserve a firm boundary between your job and your life.
I wanted to “prove myself.” Working extra hours is an easy way to be more productive, for a while.
I was looking to be promoted or otherwise recognized.2
I believed in the mission of my employer.
Building stuff is fun.
Some extra work, some of the time, is okay. This is especially true if you are learning or enjoying it.
However, make sure you set boundaries. Companies won’t do that because the incentives are not there. A good manager will—I have seen managers force employees to take vacation. One of my best bosses said: “work is a marathon, not a sprint.” As tempting as it is to overclock and work extra hours regularly, save this for special occasions.
Every project I’ve seen with a deadline has “crunch time.” During such a time, I needed to work extra hours for a few weeks. Sometimes that was 45 hours in a week; other times it was 65 hours. But if you try to work like this year in and year out, eventually it will burn you out. You’ll then have to take some time off and recuperate.
And even during crunch time , take care of yourself. I worked 96 hours one week to help save a project. The project launched, but I never got those hours back. A few years later, the project was shuttered. Would slipping a few weeks have had a material impact on my happiness? Yes, I would have been more of a human and less of a zombie. Would such slippage have had an impact on the long-term success of the project? No.
Call up a friend.
Find a hobby (that is not related to computers).
Travel.
Visit family.
Get outside.
Get inside.
Read a book.
Read a magazine.
Volunteer.
How you spend your free time reflects your desires and options. More importantly, you must decide for yourself the balance you want between work and life. This ratio has changed for me over time—I used to be more interested in sitting down at the computer after work and cranking out some code or a blog post. Now I’m more likely to read to my child or meet a friend for a beer.
Once you’ve determined your boundaries, communicate them.
Be explicit by presenting choices to your manager: “I’d love to work on project X, but as of last week I understood the priority to be project Y, and I just don’t have time to do both of them well. What should I do?” At job interviews, ask how you’d be expected to handle unplanned work. Yes, the issue is a bit scary, but employer expectations on this topic will have a large impact on your life. You also should ask about on-call expectations, as more and more companies are shifting this responsibility to developers.
You can communicate boundaries implicitly by not answering emails or chat messages outside of working hours. While doing so may not seem like a burden, it sends a message about when you are willing to work, which then may turn into an expectation. Leave Slack off your phone or configure its “do not disturb” mode.
Leave promptly at the end of the day. I’m not saying drop everything at 4:59—if you’re in the middle of a conversation, finish it. But don’t hang out till 6 or 8 p.m. regularly. Also, respect the work-life balance choices of your teammates. If they want to arrive early and leave early, good on them. If they must work from home periodically to deal with their obligations, adjust your expectations.
Expectation setting is even more important when you step into a leadership role. Many team members take cues from their leads and managers. Practicing this balance now ensures you will set a good example later.
Just as you need to manage your career because no one else will, you need to manage your work-life balance—no one else will. Employers and clients will only value your time as much as you do .
Sincerely,
Dan
Take this advice, or leave it
Rishi Malik has been a founder, manager, and engineer for over 15 years. You can reach him at www.rishim.com.
Hello new developer!
Right now, as I write this, it’s Q1 2019. And there’s a lot of advice you’ll find out on the Internet. Much of it is good, some of it is bad, but the important thing to note is that what you read are all points of view from people—from that person to be specific. This letter is no different; this is just my view on what matters. Take it or leave it. In fact, that’s the first point I want to make.
Tech is full of voices. Social media, popular blogs, and news sites amplify voices and feelings. This is an awesome thing, but remember that loud views aren’t necessarily right.
What I mean is that you’ll find points of view on everything. Developers have always loved flame wars and pointless battles (vi vs. emacs, tabs vs. spaces). Now it’s “JavaScript developers aren’t real engineers,” or “If you can’t code a binary search, you’re a bad engineer.”
Find yourself in all these voices. It’s not easy, and it will take time. But work on what you value, and develop your skills to who you want to be. It’s okay if you want to work by yourself on speeding up a search by .01 milliseconds. It’s equally okay if you want to ship a single page app with a brilliant user experience. Listen to the voices when they help, and ignore them when they don’t.
To help find yourself, focus on finding customers that value what you do. Most of the time, these customers are the people in the company you’re working for. But if you want to do algorithms, find people who will value that work. If you want to work on networks, find companies who need that.
It sounds obvious, but it’s an easy thing to miss when you’re looking for a job and when you’re evaluating comp, culture, benefits, and offices. It’s also really hard to gauge from the outside of a company.
On that note, remember that the 2019 tech industry isn’t how it will always be. Right now, the job market is stellar. I mean really stellar. In most big cities, you can find a job doing just about anything you want, most of the time within a few days.
This won’t always be the case. It wasn’t years ago, and everything comes in cycles. That’s the second point. Be willing to do things you didn’t think you wanted to. I worked on embedded systems when I started my career. I got into web technology not because I cared about it, but because it helped me get a job in a city where I wanted to live. Turned out to a prescient choice, and opened up tons of opportunities I wouldn’t have had otherwise.
The tech choices come in cycles, but so does demand. I said before that the job market is stellar. But some of us old-timers have been through the downturns—when you’re unemployed for 6 months because literally no one is hiring, when your choice is between a 50% pay cut or a 100% pay cut. Be wise; be smart. When it’s a great time to be in tech, plan ahead for the times that are tough.
Finally, my last point is to remember that there is a world outside of tech. It’s hard when you’re in it to see that. When tech was smaller, and more insular, it was easier to remember that this is a job.
But now, tech is everywhere . Apps are everywhere. The Internet is everywhere. More people are writing code, building companies, and figuring things out. But, tech is not the entirety of life. Get outside of the tech zone, and connect with people who aren’t in it. It will change how you think and how you develop code. And it provides a much needed break from the echo chamber that is tech.
Good luck, and have fun!
Rishi
Manage your career
Dear new developer,
- 1.
Knowing your goals
- 2.
Communicating those goals
- 3.
Progressing toward them
Let’s talk about each of these in turn.
Knowledge
Choosing goals is hard. We are lucky to live in a world with many opportunities. You can focus on one of a hundred different types of software development. There are other technology-related career paths such as product management, technology instruction, or engineering management. In all of these, software engineering skills will help you succeed.
In a world of opportunity, how should you choose? I pick an interest and follow it. This could be a language, a technique like debugging, or a broader skill like writing. Set a concrete goal such as being able to build a website using Ruby, manage a team, or write a book.
You can pick a broad scope, “I want to learn about DevOps,” or a narrow focus: “I want to write CircleCI orbs that help deploy our software.” Either is fine; you want a way to filter choices. It can even be something abstract like “I really want to work on an interesting problem.” Even that will help you say yes or no to opportunities—whether jobs, projects, or new technologies to learn.
Once you possess certain fundamental skills, such as problem-solving, learning, and listening, you can change your career goals. For instance, I transitioned from being a web development contractor to a startup founder. I sacrificed earning potential and free time, but used many of the same skills.
Depending on your previous level of commitment and achievement, such change may not be an easy transition. You may pay a price in terms of compensation, status, or ego; you may have to spend free time learning new skills. But no decision is permanent. Pick what is interesting. Commit to it for six months or a year. Such a precondition will serve as another opportunity filter, helping you decide what to ignore.
Another way to choose which opportunity to pursue is to plan for a decade or more. You’ll want to add milestones within that time period, as ten years is a long time. Technology changes quickly, so you’ll want to be able to adjust your plan too. I don’t have much experience with this process myself. I didn’t do this when I was younger, preferring to follow my interests. When someone asks where I want to be in five or ten years, it’s similar to where I am now—solving business problems with software. That or “retired”—but I can’t say that in an interview.
Communication
After you have chosen a goal based on an interest, communicate your desires. If you don’t talk about what you want, you will have a hard time getting it, unless you can accomplish it only through your own efforts. Even then, you’ll get further sharing your ambitions. People want to help but need to know how.
So, discuss your desires with your manager, your communities, your friends, and your coworkers. Don’t overshare, however; avoid mentioning the goal every day.
If you’ve talked about your ambitions with your manager and they’ve provided opportunities for you to work toward them, let them know how you’ve taken advantage. If your boss explains there’s no chance for you to work on that interest in your current position, do some research on your own time. Share that research and explain how you achieving the goal will benefit the company.
The longer you are at a company and the better the work you do, the more latitude you will have. Managers want to keep employees who deliver quality work happy. The alternative is often hiring someone new because an unhappy employee left.
For example, if you are a web developer and want to be a database administrator, volunteer for database projects. Mention this goal to your manager at your one on ones. If there is a database team at your company, ask if you can meet with them regularly. Working toward this goal doesn’t mean you can skip out on the web development work for which you are paid. Instead, you can tweak your work environment toward your interests. Good companies want to see their employees grow.
Progress
You can’t simply communicate your desires, you have to act on them. Again, if you are that web developer hoping to become a database administrator, present on databases at a meetup. Heck, even attending a database meetup is progress. Run a brown bag lunch on databases at your company or read a book about the technology. Study for a certification. Apply what you learn to your current duties.
Take note of adjacent areas that pique your interest. These could be future topics to investigate.
Sometimes you can’t make progress at your current employer. Maybe the opportunity isn’t there. Maybe the company really needs you in your current position, and you don’t have time for anything other than your expected duties.
You may have to switch jobs. That’s okay. Don’t burn any bridges, but when it is time to move on, leave. Find a new job with your skills and knowledge, but don’t forget to communicate your ambitions during the interview process. Give notice to your current employer and head off to a new adventure.
What’s the alternative? Floating through your career, buffeted from position to position with no plan, or worse, moving from one job you’re afraid to lose to another.
That doesn’t sound like much fun.
Sincerely,
Dan
Know your runway
Dear new developer,
When you are considering a big career jump, whether to a startup, a sabbatical, or further schooling, calculate your runway , which is how much time you have at your current level of spending before you have no money. Any time when your expenses will exceed your income, you need to know this. To figure this out, determine your current savings and your monthly net outflow: expenses minus any income not related to the job you are going to give up. Dividing your savings by your outflow gives you the months of runway you have. At the end of your runway, you will have no money; that makes living difficult.
No matter what you are considering, it’s better to know this number ahead of time, rather than run off the edge of a financial cliff.
Calculate runway once a month. Also, think about how long it would take to get a new job. This will be a guess, but you can ask folks with similar experience who have found jobs how long it took. Before you transition, decide on the number of months of runway which will trigger a job search. For instance, if you begin with six months of runway, you may set a trigger at two months. If you reach that level of runway, seek other sources of income.
Whatever you do, get a job before you need to. Desperation makes interviews even harder than they already are. You may end up accepting an ill-fitting job; this sets you up for future stress. If benefits aren’t important, consider contracting as a stopgap to allow a more relaxed interview process while at the same time lessening your financial bleeding.
If you have six months of runway , but the jump is expected to take longer, you have some hard choices. You can try to pursue the opportunity part time while you have a full-time job. You can quit or pause your startup or education midstream. You can try to increase your income, by moonlighting or joining the gig economy. You can decrease your expenses by moving to a less expensive house or cutting other spending.
Decreasing expenses is what you have the most control over, but it can be tough to do. However, other options are distracting, so cutting your spending is my recommendation, unless you are cutting expenses to the point that you are hungry all the time.
Whew. Sounds stressful. Why would you ever put yourself in a situation where you had to make these kinds of choices?
Spending savings for a career transition is an investment in yourself. When I joined a startup as a cofounder, I leveled up my skills in DevOps, customer empathy, community building, and product management. When I took a sabbatical, I learned how much I loved building software—I remember sitting in an Internet café reading an article about RDF, an XML technology that was the shiny new thing at the time.
Activities that draw down your savings lead to new opportunities and valuable personal knowledge. Just keep in mind how long you can afford such an investment so you aren’t unpleasantly surprised.
Sincerely,
Dan
How to manage one on ones
Dear new developer,
Hopefully, you’ll work at a place where you’ll have regular one-on-one meetings with your manager. In addition to serving as a communication channel, such meetings strengthen the relationship .
One on ones tend to be 30–60 minutes in duration and are scheduled regularly, either weekly, biweekly, or monthly. If you are meeting face to face, you can have them in the office, but going for a walk or out to lunch is a great way to mix it up. If you are using video chat, it’s best to have a great Internet connection, a quiet space, and video turned on. There are nuances you can only pick up from someone’s facial expression.
These meetings allow you to easily give and receive feedback. If the only time you meet with your manager is when you’ve screwed up or when a raise is on the line, you’ll dread feedback.
A regular one on one also helps both parties get to know each other. This rapport helps during stressful times. I had a meeting with a manager who pointed out how I had made a pretty big mistake. It was a hard conversation, but easier than it might have been because we’d gotten to know each other.
I want to understand where we are heading so I can know what to learn.
I want to know how I can best help you and the company.
I would like to understand your priorities better.
Framing it in this manner illustrates the value of the meeting, but in my experience, the agenda of a one on one should be owned by the employee. That doesn’t mean that the manager never brings discussion items, but rather that the direction of the one on one should be determined by the employee.
Set up the meetings at a time that works for both parties. 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 meetings back to back can make it easier for a manager. Slotting them outside of contiguous “in the zone” time blocks can make sure that you can get work done.
The meeting must happen regularly . They don’t have to take the entire scheduled duration, but the manager should never cancel them and only rarely reschedule them. If they must be shifted, find a new time promptly. This meeting is important for you as a new developer. If your manager is stretched too thin or is for whatever reason not treating the one on one as an important meeting, suggest decreasing the frequency. Realize that this is a signal from your boss that they can’t or don’t prioritize interactions with you. However, a meeting that actually happens once a month is better than a weekly meeting that is constantly cancelled.
What can you do if your boss isn’t interested? Think about other ways to get feedback, either from other team members or in an asynchronous format from your manager. You could, for example, send him or her a weekly status report. Your manager’s guidance is critical for your early career growth, and if they can’t carve time out for you, you may want to seek a new position.
How should I have handled situation ABC?
I’d like to learn more about NoSQL databases; what are the opportunities?
I’m struggling with <problem>, 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 professional challenges, discussions, or opportunities. Chitchat about what you did over the weekend is a good social lubricant, but I’ve found it can go awry. But if that’s what you want to discuss, and you feel that will strengthen the relationship, well, it’s your meeting. As a manager, I’ve found that discussing reports’ personal hobbies can lead to good conversations and a stronger rapport. As an individual contributor, I’ve also struggled with managers who would occasionally hijack a one on one with their own worries and prevent me from bringing up my issues. If that happens, gently try to bring the meeting’s focus back to your concerns.
I like to record action items for myself and my manager in the document. Sometimes the action item is as simple as “bring this topic up again in three months.” When the next one on one happens, I can see what we discussed last time; everyone can see if there has been any progress. This document is also great for preparing for your performance review, sharing with a new supervisor, or even just reviewing occasionally to gain perspective.
I have learned one on ones are the right place for me to ask for what I want. It’s awkward, because I’m a people pleaser, but if I don’t ask for what I want from my supervisor, how will he or she know? That doesn’t mean I can ask for the moon, but if I see interesting opportunities in areas adjacent to my current work, I ask if I can take advantage of them.
For example, if you run across products you think would make everyone’s lives easier, ask if you can investigate them. If you see a interesting conference, ask if you can attend. I remember at my first job I was interested in learning about database administration. I asked my supervisor about doing an internal internship in that group, and they allowed me.
What is said in a one on one should be kept private, unless sharing it is discussed and both parties agree. Keep the agenda document between the two of you. Of course, there are exceptions, such as illegal activities, and Roy Rappaport does a great job of breaking down the alternatives in his article, “The 1-on-1 Disclosure Framework.”3
It’s worth acknowledging that there’s a power differential in every one on one meeting. The manager has a lot of influence on the employee’s role, salary, and continued employment. The employee, on the other hand, does not affect the manager’s job directly. Trust is imperative, and if it isn’t present, no amount of chitchat will help.
If you can’t trust your manager to do right by you, try building that trust with smaller asks during the one on ones. If those go nowhere, my advice is to find a new job. A job where you can’t rely on your boss is not a pleasant job.
The one-on-one meeting isn’t about being buddies or friends, but rather about building your professional relationship with your supervisor. This will help both parties thrive and work toward company goals.
Sincerely,
Dan
Write a brag document
Dear new developer,
You will encounter good managers and bad managers in your career . One common thread is that all managers are busy—busy with meetings, busy coordinating with other teams, busy putting out fires, busy helping. Busy busy busy.
But your manager influences your current and future job opportunities. Promotions, compensation increases, and title changes all are earned by you, but controlled by a manager or a system to which the manager is a gatekeeper. A good manager will want you to be challenged and grow and learn.
However.
The only person who really cares, deeply and truly, about your career is you—well, maybe your mother too.
You can help your manager help you by letting them know your accomplishments. This may feel like an undue burden. You may think: “surely my manager can keep track of what I’ve accomplished.” And supervisors may know some of the stuff you’ve done, some of the time.
But what you want is to show them everything you’re proud of. This lets them know what a great team member you are. It also gives them ammunition to fight for resources you deserve: pay raises, interesting projects, and learning opportunities.
One place to share your achievements is your LinkedIn profile. However, this will be limited because you shouldn’t share too much detail or reveal company secrets. It is a good place to document projects and successes at a high level.
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?
You can pull this document out when your performance review rolls around. When combined with your cumulative one on one agendas, you should have a good idea of your successes and challenges. Having such a record of your accomplishments which you can share with your busy manager will help them help you .
Sincerely,
Dan
Be adaptable and authentic
Morgan Whaley is a senior prototype architect at Charter Communications.
Dear new developer,
Honestly, my #1 piece of career or technical advice to new developers is
Be adaptable and authentic.
I don’t think there is any one magic bullet to helping someone “break into” a job, or business, or new city. Humans are all different, and the beauty of diversity in industry and environments is when everyone truly brings themselves and overrides the homogenization that we accuse modern cities and tech of becoming.
If something isn’t working, there’s “no harm, no foul” in changing approaches, or taking a break, or simply admitting something isn’t working.
I see a lot of people who treat that first job like it’s a task they gotta beat into submission, and they tie so much self-worth to it, which is completely understandable, but the more you resist a situation and don’t remain open to possibilities, the more you are going to run into brick walls.
Morgan
PS Also, LEAVE YOUR HOUSE AND GO TALK TO PEOPLE FACE TO FACE OH MY GOD, PLEASE IT’LL BE OK.
Are you ready to work remotely?
Dear new developer,
Remote work is great. You avoid commutes, have control over your work environment, and save money on lunches. However, it has its downsides. You need a fast Internet connection, iron discipline, and the ability to work through communication obstacles. You also must be okay with solitude.
My desire to work remotely has changed over my career. For my first job, there’s no way I would have been happy working out of my house. I enjoyed the collaboration, the camaraderie, and the office full of interesting people.
There is a fundamental difference between being physically present and being on a video call, phone call, or screenshare. Anyone who has tried to walk a parent through resetting their router knows that. If you are a new developer in a 100% remote work environment, ask if there are opportunities for in-person interaction. When I once joined a company as a remote employee, I spent the first week working from corporate headquarters and made trips there every month or so. This helped me build a relationship with other employees and made it easier for me to know who to ask for help when I needed it.
A 100% remote job is different from “work from home once a week” or “work from home when you need to.” Fully remote work requires a different workflow and communication strategy. Some people are never going to want to work from home all the time due to these differences, and that’s okay.
Here is a one-question test for anyone considering remote work. You can ask yourself this, and if the answer is yes, a remote position will work well for you. If the answer is no, then you’d be happier on-site.
That question is “Are you comfortable asking a dumb question?”
You must ask questions that appear dumb when you get up to speed in any new company or project. Developers of all levels do this. These questions aren’t actually dumb, but because you don’t have context, they can feel dumb. Usually, there are two levels of queries. The first is “who can help with this?”; the second is asking the actual question to the appropriate employee. You can shortcut this by asking the question in a public chat or meeting, but this may be even more intimidating.
In a remote company , you must accept that you are interrupting people by asking such questions. Whereas on-site you can see if someone is hunched over their computer with deep focus, in a remote situation you can’t see other employees’ nonverbal cues. You don’t know if you’re asking them when they’re on a break or heads down doing deep work. Chat system statuses can provide some insight but aren’t always accurate and don’t convey the same level of information as you’d get walking by someone’s desk.
But you’ll need answers, so you’ll have to interrupt. The alternative is trying to figure it out yourself, which will often waste time. So be prepared to ask this type of question often.
If that thought of asking these questions makes you uncomfortable, congrats, you’re human.
But if it makes you want to run away and hide, then perhaps you aren’t ready for remote work. Maybe you need a bit more guidance than will be available in such a position. If you are interested in the flexibility and freedom of 100% remote work, wait a few years until you’ve internalized the fact that asking dumb questions is part of the learning process at any job.
Sincerely,
Dan
How to go through a layoff
Dear new developer,
At some point in your career, you might get laid off. I did.
I’ve also been through a company layoff where I kept my job. It stunk. It felt like I was sticking around on a slowly sinking ship. I also had survivor’s guilt; good teammates had been let go. Layoffs aren’t fun for anyone involved.
But, before I write any more about being laid off, I want to be clear. I am not a lawyer. Please don't take this as legal advice.
If you are the one being let go, it’s going to be hard.
You get called in for the meeting. Your boss is there. Someone from HR is there. They tell you the company has decided to part ways—with you.
Your heart sinks. You are handed a big fat packet of paper, full of information about benefits, unemployment, and legal obligations. The HR person runs through it and asks if you have any questions. You feel dazed.
This isn't personal.
You'll get through this.
It’s hard not to feel wounded when you are laid off. After all, you’ve spent most of your waking weekday hours supporting this company and its mission. But the truth is that organizations have to make hard choices. Sometimes employees have to be let go to help the company survive. I’ve seen managers agonize over these decisions. Now, it’s not harder for the managers than it is for the laid off workers—the managers still have their jobs after all—but it’s no walk in the park for them.
By when do I have to sign this packet of documents?
Is there a severance, and if so, how much?
What about other funds that are mine, such as a 401k, FSA, or HSA?
How can I say goodbye to my teammates?
What about other property which belongs to the company, such as a laptop, books, or equipment? How can I get that back to the company?
Who at the company should I contact if I have other questions?
Don't be unprofessional .
Don't get mad.
Don't try to get your job back (it's gone, sorry!).
Don't agree to anything other than reviewing the paperwork.
Make sure they have your personal email for further communication. By the way, if the company has their act together, you won't have access to your work accounts after the meeting.
You may ask why you are being let go. Don't be surprised if you don't get a satisfactory answer.
Say goodbye to your teammates. Emails or LinkedIn messages are good options. Write a quick note to your former coworkers stating that you enjoyed working with them. Express regret that you’re leaving, but even if you are angry, don’t badmouth anyone. Such a tone only reflects poorly on you.
After the meeting, take notes on what happened. Use your own computer or notebook. Writing down your experience will help make sure you understood everything that happened. If you want, add some details about anything leading up to the layoff. Some things might have been obvious warning signs—at one company, I kept trying to schedule a time to visit the home office, and it kept getting put off.
Before you sign any legal documents, it's a good idea to run the agreements by an employment lawyer. If you don't know a lawyer, ask for a referral from a friend. Yes, such a review will cost a lot of money as lawyers charge hundreds of dollars an hour, but they've seen such contracts before and are legally obligated to do right by you. The lawyers who wrote up the agreements are obligated to look out for the company. Your lawyer should be able to advise you on topics like noncompetes and nondisparagement agreements.
At this point, it's "just business," so protect yourself. Ask the lawyer for their advice. Also make clear your budget and timeline; I’ve never had a lawyer push back if I said “I only have $1000 for this. Please let me know if you’re getting close to that number.” The bill might hurt, but don’t forget that they will save you from making expensive mistakes like signing away your right to work for a competitor.
There may be some back and forth with the company over the agreements. Depending on the situation, you may have more leverage, but your end goal should be to quickly wrap up the separation in a way that feels like you’re not being taken advantage of. After the review by your lawyer and perhaps an exchange or two with the company, you can sign the agreement. Or you may not, in which case you can ask the lawyer what your other options are.
Either way, take some time to grieve, even if you can only afford a day. When I was laid off, I took a long afternoon walk which helped me process the event. Even if the company or job wasn't a perfect fit, being laid off hurts.
Then, roll up your sleeves and start looking for a new opportunity. Is it time to try contracting? Maybe something else that is risky? Or to reach out to your network and see what is available?
A layoff feels like a defeat. But you'll get through it.
Sincerely,
Dan
Use LinkedIn
Dear new developer,
Set up a LinkedIn profile and keep it up to date. It is basically a public resume. Yes, a GitHub or other code repository profile is useful as well, but you might not always have time to keep that code polished—text is easier. Once every year, update your profile with what you’ve accomplished. Hiring managers will often look at it, and you want to impress them.
Keep track of former colleagues or others you meet in a professional context using LinkedIn. If you meet people at jobs, conferences, or meetups, ask if you may connect to them. Folks have different thresholds—some people connect to anyone, others want to meet you, and some won’t connect unless they have worked with you. It doesn’t hurt to ask; don’t be offended if someone says no thanks or doesn’t accept the invite once you send it. My personal threshold is “have I met you in person or engaged with you online?” My connections are of varying strength—some connections I’d hire at the drop of a hat; others I met only once.
In the same way, determine your connection criteria. Do you want to connect to everyone? Only people you’ve talked to? A friend asked for an intro to a LinkedIn connection recently, and I couldn’t provide one because the connection wasn’t someone I really knew. Is it even useful for me to have that person in my LinkedIn network? Probably not, which means I should reconsider my threshold.
If you do end up sending requests to people you’ve met only briefly, always include a note. This differentiates you from the drive-by connector. It can be as simple as stating where you met them: “It was nice to meet you last week at the Boulder Ruby meetup. I’d like to connect with you.”
Depending on your skill set and the strength of the job market, you’ll probably be contacted by recruiters on LinkedIn. Such recruiters tend to be low-value keyword matchers. But you never know, someone might be able to place you in a job. If you do talk to a recruiter, be honest about your desires. Take what they say with a grain of salt because they are trying to sell you on the position. While you are having the conversation, ask them about their view of the job market, salary ranges for people with your experience, and good skills to learn. If they aren’t willing to or cannot share such information, they won’t be much good to work with. Whatever you decide, treat the recruiters with professionalism; please don’t troll them.
LinkedIn is an address book which someone else keeps up to date. When you are looking for a job, examine your connections’ companies, review posted jobs, and then ask if your connection can introduce you. Make it easy for them by writing up a note explaining why the company is awesome, why you are awesome, and why you want to work for them. A warm intro is more likely to lead to a conversation and interview than submitting a resume via a website. If you have a job, do the same for others who reach out for this kind of help.
LinkedIn is a powerful professional tool . It can help you find a job, keep in touch with former colleagues, and assist other people.
Sincerely,
Dan
Contracting
Dear new developer,
You have a portable skill set ; every company needs software, just like everyone needs accountants. You have a “means of production” that only costs a few thousand dollars: your laptop. You can learn new skills for the low cost of an Internet connection and your time. Especially after you have a few years of experience, you are in demand.
Please take a chance during the first decade of your career and try contracting.
Why? I like contracting because it is similar to applying for a job every few months. Whoa, who likes applying for a job? The hiring process for contractors is easier than interviewing for a full-time position because contractors are easier to let go. Having to regularly find and engage with hiring managers and clients means you must keep your skills sharp and your ear to the ground for opportunities. Honing these skills for a few years means that if and when you become an employee again, job hunting won’t be anywhere near as scary. Who knows, you might even “go feral,” as a friend of mine says, and never want to be a full-time employee again.
You’ll also strengthen your network because you’ll run across opportunities that aren’t a fit for you but might be for a former colleague. Share those and I guarantee former coworkers will remember you fondly. When you are contracting, depending on the arrangement, you may be paid for every hour you work. The rate is typically higher than it would be if you were a full-time employee. Contracting can be very lucrative.
There are two paths to contracting. You can work with an agency; they will place you at their clients. The other option is contracting directly with clients.
The first is easier . The agency finds the work, sorts out what kind of developers are needed, and sends you to the client. You’ll be paid by the agency, typically by the hour. You’ll have the chance to experience many different organizational structures and technologies, without doing anything other than showing up. Depending on the agency, you may be able to switch between clients. The downsides of working through an agency are that you’ll receive a lower hourly rate than you would if you contracted directly—basically, you’re paying for them to take care of sales and accounting.
Contracting directly with clients is more difficult. If you do this, you’ll learn skills beyond software development: sales, customer support, marketing, invoicing, and chasing payments. All these are powerful additions to your toolkit. If nothing else, they’ll give you an appreciation for everyone who works at a software company who isn’t an engineer, because when you contract directly with clients, you perform all those job functions. Getting such a business running will take longer than calling an agency, passing their interview, and getting placed at a client. But you’ll have a lot more control over the clients you work with and more income.
I’ve met plenty of people making less money as a direct to client contractor than as an employee. They’re working harder too. Why? They don’t raise their rates, and they work for cheap clients—clients who don’t value their time. Fire bad clients by finding new ones and then ceasing to work for those who don’t treat you right. To do this, you must be always on the lookout for new prospective customers.
Depending on the market you are in, you may spend as much as 50% of your time on non-billable work, which is often seeking new opportunities. Make sure your rate reflects this. Writing blog posts, contacting past clients, and being engaged in local communities such as the chamber of commerce, meetups, or a local Slack workspace all will help you when your current contract is over.
You must raise your rates every time you have a new client until prospective clients are saying you charge too much. You can also raise rates of your existing clients on a yearly cadence. How do you find out how much to charge? I’ve found most contractors are happy to chat rates, especially over lunch. If you’re too busy, you are pricing your labor too low.
Even if you want to be a full-time employee for the rest of your career, a stint as a contractor introduces you to new ideas, teaches you new skills, and will give you an appreciation for the work of nonengineering colleagues.
Sincerely,
Dan
Engineering management
Dear new developer,
As a new engineer, you’re probably a few years away from thinking about the challenges of engineering management —but perhaps not. If you join a startup rocketship, you may be managing people in months. Moving into management is a common career path for a developer as they gain experience.
However, management is an entirely new job. A pattern I’ve seen again and again is a developer being hired, sticking around, and becoming more experienced on a team. More responsibility is handed to him or her. They meet with clients or other representatives of the business. They are responsible for technical delivery of a product. They mentor other team members on “how things are done around here.” Eventually, someone in authority asks if they would like to be promoted to an engineering manager position—or worse, doesn’t even formally ask, just heaps on the responsibility with no conversation.
If this happens to you, new developer, beware. The difference between software development and engineering management is like the difference between American football and soccer. Familiarity with one will help you understand the other. They both are about scoring points and moving a ball around. But at the end of the day, they are fundamentally different. If you move from software development to engineering management, prepare to be a novice again.
The skills that make you a great developer won’t make you a great manager. Developers solve problems; managers help others solve problems. Developers focus; managers communicate. Developers code; managers listen and plan . It’s not an entirely disjoint union, but if you take this step, know that you’ll be starting over and you’ll have a lot to learn.
You should have your hands in the code so you can follow along, but you must stay out of the critical path of software delivery.
People closest to the code should make technical decisions. Hint—that is not you.
Enabling teams to do great work is your new problem space.
You should not do the fun technical stuff at work, except during hackathons.
One warning: Your company may be great, but it doesn’t exist for your benefit. You and only you can decide what your needs are and advocate for them. Remember that next time your boss tries to guilt you into staying on as manager because you’re so badly needed, when you can feel your skills getting rusty and your effectiveness dwindling. You owe it to yourself to figure out what makes you happy and build a portfolio of experiences that liberate you to do what you love. Don’t sacrifice your happiness at the altar of any company. There are always other companies.
I don’t tell you this now, new developer, because I want to scare you away from management. I have been an engineering leader and enjoyed it. You have autonomy, you can help fix problems you see in your organization, and you get to recruit and help people grow into the best developers that they can be. But it’s a step away from some of the joyful parts of software development—building things, solving hard technical problems, and being a doer . Make this choice with your eyes open.
Sincerely,
Dan
Someday, you won't want to code for a living
Dear new developer,
I remember my first full-time software engineering job. I was able to work on a great team and interesting problems. I regularly got into “flow,” that magical state where time passes unnoticed and much code is written. I was paid well. They 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. I asked him once why he hadn't remained an engineer. 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 a state of flow. I enjoy it. But when I am coding, I have limited influence. As I grow older, I grow more impatient to effect change in the world. The best way to do so is to have more leverage.
Writing
Project management
Product management
Speaking
Starting a business
Mentoring
Leading a team
Managing
Teaching
Architecting
Consulting
Most of these involve communicating about software engineering, but coding is not the primary work output. Instead, the emphasis is on a product, knowledge sharing, or team alignment.
Working on large systems with a lot of users
Working on popular open source libraries
If either of those options floats your boat and you want to keep coding, pursue them. I don’t like the first because I don’t really enjoy the bureaucracy 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 must pursue leverage. I’m just saying you probably will. I’ve seen it happen in many companies and with many individuals. Part of it might be that more leverage typically means a higher salary.
Your salary will be higher because you provide more value. With a higher leverage position, the company benefits in ways beyond the software you write. For example, if you’re a team lead, the communication you have with stakeholders to ensure the software will meet their needs on their schedule is quite valuable.
A career is long. My guess is that one day you won’t want to only code for a living. Enjoy it now but keep your eyes open and think about other options which might be of interest.
Sincerely,
Dan
In conclusion
I remember when I turned 25. I was glum. A work colleague asked what was wrong. I explained I’d already been through 25% of my life and hadn’t achieved much. He laughed and said that I’d really only been through five years of adulthood and that I’d likely work another seven half decades, so in reality I wasn’t that far into my career.
As I look back, having worked through a few more half decades, what I can do and what I’m interested in have both changed. While I haven’t had a long-term plan, I’ve taken advantage of some breaks. New challenges have arisen. Some I’ve succeeded at. At others I’ve failed.
Your career is long. You need to manage it, whether that is tactically asking for what you need during a one on one, working toward larger career goals, or simply keeping in touch with former colleagues on LinkedIn.