Your first month is a time of great promise. You are joining a company and team who are excited to have you. You represent success in a long arduous hiring process.
Everything is new for both you and your employer. There’s a lot to share and learn for both parties.
Enjoy.
There are no adults in the room
Dear new developer,
When I started working, I was shocked to learn that there are no adults in the room.
I say this not to denigrate your fellow employees, working hard to make the company successful. Rather, I’m saying no one knows it all. Everyone is doing the best they can with their limited information and understanding; well, most people—there are occasionally bad actors.
If you join a company expecting to be handed work on a platter, expecting someone knows exactly how to do that work, the way that a college professor knows how to teach physics 101, you will be disappointed. Your coworkers are usually trying to stay one step ahead of the customer.
There are sometimes domain and process experts at a company, but I’ve only worked at one organization where someone truly understood the entire business. And even at that job, the future was unknown, and there was experimentation around new programs. “Hmmm, will that work? Let’s try it and find out.”
The software industry isn’t alone in this lack of clockwork precision, by the way. I’ve talked with employees in other sectors. Never met someone who worked at a perfectly run organization. Even in places where stakes are life and death, like hospitals, there’s chaos and uncertainty.
It’s a problem—Oh my god, no one knows what the heck is going on. What kind of place is this?
What an opportunity!—Excellent, I can see that folks are grappling with interesting problems and need help. Let me put my nose to the grindstone and see how I can assist.
You’ll be happier, more productive, and a more valuable team member if you choose the second line of thought.
Of course, there are uncertainties that you shouldn’t accept, such as anything that could damage your health or ethics. But it was empowering to me when I realized there were no adults in the room with all the answers.
Just people trying to do their best.
Sincerely,
Dan
Onboarding
Dear new developer,
At every full-time job I’ve ever had, there was an onboarding process. As a developer, there are typically two types: HR and company orientation and technology and process training.
Onboarding is your first chance to interact with the company as an employee. Companies want to help new hires navigate their jobs’ invisible societal structures. This process will help you succeed, but it’s often a firehose of information.
Your salary
How you will be paid
Health benefits
Employment agreements
Retirement accounts
How to interact with other departments and teams
Bonuses
Company meetings
How to request vacation
When raises or reviews are scheduled
This onboarding should cover basically everything except the actual work you were hired to do.
Make sure you understand this information because it won’t be systematically presented to you again and can affect your job satisfaction. In some cases, such as a noncompete, it will influence your future employment choices. If you have questions about this material, email is a great way to get them answered; when the exchange is over email, you have it for reference in the future. If you feel more comfortable having this conversation face to face, follow up in writing. Consider saying something like “I just wanted to make sure I was clear about our conversation. It’s my understanding that…”.
There may be an employee handbook , but maybe not; it depends on the size of the company and of the HR department. There may also be a wiki or documents on a shared drive, which you can review as well.
Who can you ask questions of?
What is the best way to ask questions? Batch them up? Post to chat? Schedule a meeting?
How long should you work on a problem that has you blocked? If you can’t make forward progress, how long before you should ask for help?
How do you communicate progress?
How do you set up your local development environment on your own computer to start working on code?
How does code you write get to production? Is continuous integration or deployment set up? What does the release cycle look like? Who, whether a single person or a team, owns releases?
Where will you get direction from? A ticketing system or issue tracker? Your manager? Your team lead? The product owner?
How will you know when you’re done with a task? Is it when it is shipped to production? When a product owner approves it? Some other milestone?
The first month is all about getting up to speed in the organization’s environment. Formal onboarding accelerates your ability to dig in, start adding value, and help the team achieve its goals.
What should you do if there is not a formal onboarding process ? If you don’t have a formal HR or company onboarding, you’ll want written answers to your questions about how to interact with the company. However, even small companies I’ve joined have a formal process. Since a lack of one has legal consequences for the organization, only very small companies don’t have one.
If there is not a formal technology onboarding, keep notes and start a document. You’ll be helping future developers who join your team. This can be as simple as starting a wiki page.
An onboarding is usually your first interaction with the company as an employee. Take the opportunity to learn as much as you can, both about how the organization works and how to do your job as a developer.
Sincerely,
Dan
Overindex
Dear new developer,
It is unfortunate, but first impressions matter . Like many other jobs, success in software development requires working with other people. Therefore, bring your best self to work for the first month of any job. That doesn’t mean you can check out later, but in the first month, you should stand out.
Arrive a bit early every day.
Say what you are going to do. Do what you say.
Do extra research. When you have a question, don’t just blurt it out. Instead see if it has been answered (search the wiki, search the chat).
When you get an answer to a question, record that information for other team members’ use.
Volunteer to take on the extra work (but not too much—don’t set yourself up as a punching bag).
Own your mistakes. However, don’t beat yourself up when they happen.
Don’t make the same mistake twice.
Be unfailingly polite and professional.
Ask for some of your manager’s time to make sure you and they are on the same page regarding your goals. How often should you check in and report progress? I don’t know, it differs with every manager. So, ask.
Write documentation to make the next hire’s life easier.
Once you have the reputation of being a hard, smart worker, it will follow you. After a month or two, you can ease off a bit—partly because you will have that standing and partly because you’ll understand the job better. You’ll be able to continue to perform your duties effectively with less effort.
When you first join an organization, everyone is excited. If you can overindex and achieve 105% or 110% of what they expect of you, team members will remain enthusiastic. However, if you deliver “only” 90% of what they expected, the excitement might fade.
First impressions last for years. Your reputation will follow you beyond the organization. Choose wisely .
Sincerely,
Dan
Work through the trepidation
Dear new developer,
I remember the first month of my first job. Not a pleasant memory. I wasn’t sure who was who, what was what, or even sometimes why I was doing what I was doing. Even after onboarding, I was often confused. It was hard to find tasks I could do that helped my team. I wasn’t sure what words and acronyms meant, even ones that people used offhandedly like “API”. I’d read and reread instructions, fearful that I wasn’t “doing it right.”
Every day was a struggle.
Eventually, I learned my way around—around the codebase, around the organization, around my tools, around the team.
And everything got better. After a few weeks, I became more confident and able to help the team. We shipped software. Eventually, I even wrote best practices documentation about version control practices, sharing knowledge throughout the company.
And then I switched jobs. It happened again. The trepidation, I mean.
It was a bit easier because I had my previous experience to draw on. I knew the fear and uncertainty would pass. But I still needed to learn so much to be effective at job #2.
Eventually, things got better. Again, I learned my way around.
And then I switched jobs. It happened again. The trepidation, I mean.
See a pattern?
For every job I have ever had, the first month was tough. There’s a lot you don’t know, and worse, there are things you don’t know that you don’t know. Sometimes you’ll be hired into a company that is moving fast. In that case, you may have a hard time even finding someone to answer your questions.
“Today, I learned how to deploy to our QA environment.”
“Today, I fixed two bugs and discovered a third.”
“Today, we were in a meeting and I shared a meaningful comment.”
“Today I closed one ticket.”
“Today, I figured out who the Docker experts in the company are.”
Keep on working. And, soon enough, you’ll break through and find your way. I promise.
Sincerely,
Dan
How to excel at your job
Dear new developer,
Say what you are going to do, then do it—Communicate what you are working on. You can do this synchronously (face-to-face communication or a chat message) or implicitly (moving cards on your task tracking system or in an email). Keep other people, who will have a better idea of the big picture, in the loop. Oh, and then you must do the work.
Ask questions—Don’t be afraid of looking dumb. Do some research before you ask as that often will answer your question, but don’t spin your wheels. Ask meta-questions such as “Who is the best person to ask this question?” or “How much time should I spend investigating on my own before asking a question?” This will help you do the work.
Don’t make the same mistake twice—Learn from those you do make. Write down what you did wrong and how you plan to avoid doing it in the future. If it is a common mistake, share your documentation with the team. This will help you do the work better in the future.
Show up consistently—Be a bit better every day. Keep your spirits up by remembering how far you’ve come. Put in the time. Sometimes you just have to grind. To do the work. (Is there an echo in here?)
Do these things, and you will stand out as a new developer.
Why? It’s sad to say, but there are many developers who aren’t very good. I’ve seen a few in my time. I’m not sure if they weren’t good because they were burned out, didn’t care, didn’t have the skill set or the desire to learn, or were just in it for the money.
I’ve also seen developers get complacent, which is a foolish thing to do in this day and age. It’s also a luxury that most new developers do not have. You don’t need to be an expert in every new technology, but you do need to keep your skills up to date.
You don’t have to be brilliant to stand out. You do have to be good and consistent. And you must do the work (there it is again!).
Focus on these four items, especially during your first month, and you’ll gain a reputation as a delight to work with. This reputation will follow you for years. People will offer you opportunities, return your phone calls, and help you find jobs and advise you.
Sincerely,
Dan
Learn your team
Dear new developer,
You will learn many things during your first month on the job—how to deploy the software, coding conventions, homegrown frameworks, good places for lunch.
But the most important thing you can pick up in your first few weeks at a job is team dynamics. Even if you are the only technical person in the company (which I suggest you avoid), you will still have coworkers who use or run software systems. Someone has to tell you what to do. Someone has to tell you what customers you serve.
You will be operating in a team environment, and you’ll need to both assist the team and lean on the team when you need help. The best way to get what you need is to get to know your coworkers. When you know team members, you’ll both understand who to approach with a given problem and how to relate to them during tense times. To whom would you rather lend a hand, a stranger or someone who has taken the time to get to know you?
Learn everyone’s name—When I’m meeting someone new, I like to repeat back their name as soon as possible to reinforce it in my mind. Usually, I’ll ask a question: “So, Ahmed, what new technologies are you excited about?” Other ways include taking written notes or associating the name with a relevant interesting fact. Whatever works.
Learn each person’s area of responsibility—Almost everyone I’ve met loves to talk about themselves. Over the course of your first month, ask everyone you meet what they do. What challenges do they face? What excites them about the project and the company?
Go out to lunch—At my first job, I saved money by bringing my own lunch. That is a smart financial move, but a dumb career move. Lunches help teams build cohesion. You don’t have to break your budget by going out every day but join a few times a week. Consider buying lunch an investment in your career that will pay dividends. At shared meals, you learn more about your coworkers, including their personal lives, interests, and hobbies.
Say yes to other social activities if you can—The first month is when people will be most welcoming and so may invite you out. Don’t do anything you feel uncomfortable with or can’t afford, of course.
If you work in a remote team, ask your manager how you can get to know other people—Depending on the maturity of your organization, they may have a formal process, but you can also do random video calls.
In my experience, personal dynamics are almost never laid out for you when you join a team. You may get pointed to “Jane, who is an expert in system XYZ,” but that’s about it. You’ll have to play detective.
Note who talks at meetings, who does not, and who isn’t invited to the meetings at all. Pay attention to whose opinions are dismissed and whose are respected (but make your own decisions about the wisdom of those choices). See who hangs out with each other at social events and who drops funny gifs in the company chat.
This knowledge will help you know who to seek out when you need help, whether that is about the history of a certain component, how to build subsystem XYZ (I suggest Jane), or how to request assistance from another department.
Sincerely,
Dan
How to read code
Dear new developer,
Reading code is more common than writing code. In your first month of work, you’ll be reading a lot of code as you try to understand new systems you’ll be working with. Some developers even say, “don’t trust any documentation, read the code,” though I consider that a radical position.
But how can you effectively read code?
First, you need to understand the syntax of the language (or languages). How are methods or functions called? How do you define a variable? How is the code modularized? This is the first step, just like learning the letters of the alphabet.
Then you want to start to understand the meaning of the code. Most systems are too big to hold entirely in any one person’s head, so pick a part to dig into. Trace the flow of data through the system. Start from whatever event kicks off code (a user interaction, a file being placed somewhere, an external sensor firing) and follow the data flow. Don’t get distracted; if you see something you’d like to learn more about but it is not in the data flow you are currently examining, jot down a note and come back to it later. This activity is analogous to learning to read.
I also find it useful to understand the architecture of the system. This is the “boxes and arrows” drawing which relates the pieces of a system together. Having this big picture won’t help you with the details of the code you’re reading, but I find it helpful when other subsystems or components are referenced. This is analogous to the “Cliff’s Notes” of a book.
As you continue on your software engineering path, you’ll need to move between these levels of abstraction . Like reading a human language, the more you do it, the better you’ll be. Eventually, you will gain intuition around the system.
But that’ll take a lot more than a month.
Sincerely,
Dan
Learn about personal finance
Dear new developer,
If you have a software development job , you’re probably making pretty good money. I know when I started my first job, I was making more money than I ever had before. I had an annual salary of $42,000, in 1999 (which is $65,250 in 2020 dollars).
Man, it felt good to just buy what I wanted to buy and not worry about it.
One financially smart thing that I did at that first job was to set up my 401k contribution. Shockingly, it’s far better to save for 10 years starting from age 25 than for 30 years starting from age 35. It’s all thanks to the magic of compound interest.
You contribute $5000 every year to your retirement savings on January 1.
Your savings grow tax-free (in a 401k or IRA or similar account).
The annual rate of return including fees is 7%.
You receive your gains on December 31; for example, on December 31 of the first year you contribute, you have $5000*0.07 + $5000, so $5350 in your account.
The magic of compound interest
Take advantage of time and put money away early.
A Random Walk Down Wall Street—This book convinced me that index funds were the best way to buy stocks and bonds and that trying to beat the market is a fool’s errand.
Are You a Stock or a Bond?—This book taught me that you should save differently based on the kind of job you have. Do you have a riskier job, at a startup or in a cyclical industry? Save more in bonds. Shift your investment portfolio based on the risk of your income.
Your Money or Your Life—This book made me think about money as life energy, which made me more conscious of how I spent it. The advice on investing is a bit conservative for me, however.
Personal Finance for Dummies—A nuts and bolts discussion of investment opportunities and how to build a budget. This book is great for personal finance basics.
Personally , I saved as much as I could when I was a new developer, but you may make a different choice. I have a friend who invested in solar companies because that aligned with his values. I have other colleagues who didn’t start investing until they were in their 30s or later.
There are many paths. Learn enough to make an informed choice.
Sincerely,
Dan
Take care of your body
Dear new developer,
Get good sleep.
Exercise regularly.
Schedule regular checkups with your doctor, dentist, and other health-care providers.
Walk away from your desk periodically.
Consider a standing desk.
Look 20 feet away from your monitor every 20 minutes for 20 seconds.1
Use as large a monitor as possible.
Change the font on your screen to be easy on your eyes.
Don’t work crazy hours.
Use an ergonomic keyboard.
Some of these items require the cooperation of your employer. Ask for what you need, as keeping you healthy is in the interests of both parties. You might not get that 48-inch monitor, but if you don’t ask, you surely won’t.
Whatever you do, listen to your body. Take regular breaks. Buy the equipment you need, even if you must spend your own money.
When I was young, my body seemed to be an endless resource, capable of enduring anything.
From where I stand now, I can tell you with authority: it is not.
Sincerely,
Dan
In conclusion
In the first month of your job, you’ll be drinking from the firehose. You will be getting up to speed on the technologies and specific implementation details of the systems you’re working on. You’ll also be trying to navigate the cultural norms of your new workplace.
This is exhausting labor. Make sure you allow yourself some slack, both in terms of how quickly you come up to speed and what you try to commit to outside of work.
But make sure you put in the time and the effort, too. This is no time to slack. First impressions matter.