How to Crush it at the Start of Your New Developer Job

This no B.S. guide will tell you what you need to know to survive and thrive as a software developer at my workplace (or just about any workplace).

Congratulations on being hired. You have a lot to learn. It's not the stuff you think. And you've got to learn it fast

We don't care where you went to school, where you've worked, or about any of the things you've accomplished. That's all in the past. You are starting from zero.

Here's the deal

I assume you:

• are a reasonably competent programmer who wants to do a good job and work on interesting projects
• want autonomy to choose what you work on, make your own decisions, have your opinion heard, and influence the direction of your projects
• want to learn valuable skills that can help you progress in your career
• may or may not want leadership or management positions and responsibilities
• wouldn't turn down bonuses, raises, and other perks for doing your job well

All of that is on the table in our organization. You set your own limits on the level of autonomy, rewards, training, responsibility, perks, etc. you will receive in this job.

The level of autonomy we grant you is directly proportional to the clarity with which you understand your mission (see below) and the level of competence you exhibit.

High levels of clarity of mission and competence will be met with high rewards. But there's a flip side to that equation. If you are unable to grasp your mission or if you demonstrate low competence despite our best efforts to train you, we'll park you on unimportant tasks and micro-manage you in the best case and fire you in the worst case (I said this is a no B.S. guide).

Your mission

Your mission is to help our company increase revenues and reduce costs. That's it. Every position in our company (and every for-profit company) has the same mission. Your value to our company rests on your ability to deliver on your mission. And we are judging you on that basis. So you need demonstrate that you understand your mission and start delivering on that mission as quickly as you can.

The best way you can help us increase revenues and reduce costs is by working on the most important thing at all times. I can't overstate the importance of this point.

The simplistic formula for calculating the most important thing is "return" divided by "effort." 

This is a major problem for you as a new employee because:

1. you have no way of knowing the amount of "return" (revenue or cost reduction) any given task could be expected to provide
2. you can only guess at the "effort" required to complete any given task because you don't know how we do things yet

So, it's basically impossible for you to create much value on your own until you can make reasonable assessments of "return" and "effort." And you won't get much autonomy until you prove to us that you can make these assessments reasonably well.

Tips

Let me point out a couple of things:

1. your most important decision is the first decision (what to work on). If you get that one really wrong nothing you do after that will help you create substantial value. You could write the world's best software but if you solve the wrong problem, it's worthless to us.
2. it's not enough to find something of value to work on. You are looking for the thing that has the most value.
3. the most important decisions in your job are rarely 100% technical. Our product owner is an MBA. And he can't tell the difference between an SQL query and a file full of jQuery but he's really good at this stuff. His deep domain knowledge, ability to ask us (his programmers) smart questions, and his strong grasp of how value is created ("return" divided by "effort") are all he needs to make great decisions. Unfortunately for you, this is also a lot harder to learn than the typical things new programming hires ask about such as the mechanics of how we create pull requests or how we name things.
4. it's a mistake to assume you know the best way to make all these decisions as a new hire. But it's not against the rules to ask a co-worker for help. Hint!

How to do a really good job in your first few days

Focus on:

1. acquiring domain knowledge - start with the basics (what we sell, why we sell it, how we make money, where our opportunities are, where our challenges are, etc.)
2. asking your teammates smart questions - what do you want me to learn first? what are our priorities? what do I have to do to be a 10x programmer on this team?
3. getting into the habit of trying to maximize the value of your efforts. Start doing that math on your decisions. It needs to become a habit.
4. avoiding silly suggestions - I know you want to sound smart and make valuable contributions but you don't know anything about creating value in this company yet. This is the time for asking questions and learning, not advocating for your favorite technology, methodology, or problem solving approach. Even if you see something that seems absolutely crazy I'd encourage you to assume that there's a good reason for it and just go with it for now (but make a note to circle back to it in a month or two if it still seems crazy).

I want you to succeed but you have to be responsible for yourself

Be prepared. Work hard. Meet your commitments. Don't be late. Don't waste people's time. Ask smart questions. And take notes.

Take responsibility for integrating yourself into the rituals, processes, and culture of your team. Request training and one-on-ones with people who can help you with your mission. If you need resources, ask for them. But know when you are beginning to make too many demands on other people and dial it back.

I'll give you as much of my time as I can but I find that it's better if new hires "pull" information toward themselves than if I "push" it on them by assigning readings and giving tutorials. 

To a large extent, you are in control of how much training, orientation, and mentoring you receive above the bare minimum.

Aim to be a "zero" for your first few weeks

In his book An Astronaut's Guide to Life on Earth, Chris Hatfield (a famous Canadian astronaut) said he aimed to be a "zero" at the beginning of a new job.

In your first few weeks in a new position it's very easy to say or do the wrong thing, especially if you're trying to show people how smart and capable you are. And because it can be difficult to overcome first impressions (or get yourself un-fired), you should aim to simply meet expectations and not make any major mistakes--aim to be a "zero."

Your first few weeks are about finding your footing and figuring out what's expected of you.

Never stop learning

Mastering the information in this post will help you make it through your probationary period. But your long term success at our company relies on your continued growth and ability to create value.

You should work through all the information in this post: How to be a wildly successful programmer. There's no secret to being an amazingly valuable member of our team. I wrote it all down for you and I'll help you achieve your goals any way I can. But you have to do the work.

You should also start reading my must read programming books. I can give you customized reading recommendations. Just ask.

Conclusion

So that's my no B.S. (highly opinionated) guide to crushing it at the start of your new developer job. Over the years I've observed many people start all kinds of positions. And hardly anybody does as well as they could during their first few weeks on the job because they are focused on the wrong things. So be prepared for your boss to fall in love with you if you follow this guide. 

You can also use this guide to change your fortunes in your current position. It's never too late to change your approach to your job and reap the rewards of being a star employee.

Note: the opinions expressed in this post are mine alone and do not reflect the opinions of my current employer or former employers.

Do you have a good or bad onboarding experience to share? I'd love to hear it in the comments.

Enjoy this post? Please "like" it below.

Comments

[Chris Bertrand]

Great post. Be a zero.

[Rifai Martin]

But, I do not understand what it means to be Zero

[Chris Bertrand]

I know it's difficult when you're as smart as us!

[Hugo Pineda]

This is awesome. Thanks for sharing

[Blaine Osepchuk]

You're very welcome.

[Jaimie Carter]

Fair enough.

[Jean-Michel 🕵🏻‍♂️ Fayard]

I liked the article generally, but I think it's not 100% bullshit free since it includes the "10x developer" thing.

The concept of 10x developer is bullshit

• it's either wrong or trivial : there are 10x people in every profession
• it's arbitrary, 9x developers are good too
• it creates stress that is not necessary (and stressed teams do worse work)
• it forgets that programming is a team sport - a programmer that claims to be ten times better than anyone is a jerk I don't want to work with.

[Blaine Osepchuk]

Thanks.

I didn't mean to trigger you with the '10x' adjective. Feel free to replace it with excellent or outstanding. They are all synonyms for the purposes of this post.

[Javier Aguirre]

Thank you for the article! I shared it with my team. It's a great first post for people starting to work at a company 💯