This post was originally posted on my blog

Amazon is a fast-paced, decentralized and constantly changing environment. It can be a bit of a shock to new people coming into the company. Because of this, mentoring developers is a critical (and very enjoyable) part of my role. I mentor many fresh-out-of-college developers entering the industry for the first time, as well as other more experienced developers coming in from different companies. Some of the college grads ask me for tips on how to get a good start on their career.

Here are some of the tips I give that are non Amazon-specific and generally useful for any software developer.

Tip 1: Treat your career like a marathon, not a sprint.

I remember being in college talking to one of my first Computer Science professors. When he found out I was a freshman, he said, "Oh you're just right at the beginning!" He didn't mean it in a negative way, but I remember feeling so frustrated, because although he was absolutely right, I desperately wanted to prove myself and earn a level of respect and acceptance of my peers (and myself really) as quickly as I could. However some things just take time, and time wasn't something I could control.

I definitely see some of those same feelings reflected in the recent college grads beginning their careers, especially at a company like Amazon where expectations are so high. Here's what I tell them:

First off, you're at the beginning of what I hope will be a long and very fulfilling career. That's a very exciting place to be! The first thing you need to understand is that your career is going to span decades. I want you to really try to think about and internalize that. Decades. That's a long time. So you can't approach your career like it's a sprint. It's a marathon and you need to approach it accordingly. You need to pace yourself. Developing consistent, healthy habits will pay much larger dividends in the long term than short, sporadic bursts of effort that leave you exhausted.

Here's an example: For me, reading technical and personal development books has benefited me tremendously in my career. Your first instinct is going to be to binge read a 350-400 page book over a weekend. But in practice, what I've found is this isn't sustainable. You end up binge reading maybe a book every few months at best, but it usually lengthens out to become less frequent over time.

Alternatively, you can build 20 or 30 minutes a day into your schedule as reading time. That doesn't seem like a lot of time at first, but let's say you read 10 pages in that time, which is a pretty conservative estimate (but can be realistic for very dense technical books). If you do that every day, that ends up being about 300 pages a month. At that rate, you can get through a book in a little over a month. You won't be exhausted, and you'll have time for other things so after that book is complete, you can move on to your next book. Now fast-forward to a year from now. With binge reading, you've read maybe 2-4 books. With 30 minutes a day, you've probably read 10-12. That's a big difference and that's only one year. Remember: Decades. A year is 3.3% of a 30 year career. 😳 Starting to feel some perspective?

This is the kind of thinking you need to apply to your career. Building regular time into your schedule is much more effective than trying to binge whenever you think about it or are feeling frustrated and stagnant. Of course those opportunities do come up. Maybe you're traveling and read your book for an entire plane ride. Maybe you're so interested in this book, you read it for 2 hours one day. But that should be bonus, and you should naturally fall back to your regular scheduled time as the default. Also, don't beat yourself up if you fall off the wagon and miss a few days or a week. You're not a robot and life happens. Just accept it and come back to your schedule.

Tip 2: Focus on your strengths, interests and the little wins over artificial rewards like promotions and bonuses.

I've written an entire post about this, so I won't spend too long on this here. My personal philosophy is that things like promotions and bonuses should never be the central focus, but rather happy side effects of being passionate about what you do and doing the right thing for the customer and the business. If promotions are something that are emphasized at your company, then become aware of the kinds of things that are being looked at for promotion. However, start with your interests and strengths and then look for ways to leverage those skills to make a contribution that's in line with getting to that next level.

However don't make a promotion or positive performance review your primary personal success metric. Maybe I'm just impatient, but that's too long for me to wait! It also relies on someone else, and I'd rather be my own source of motivation. I much prefer the satisfaction of things like finding the root cause of a bug and pushing the fix to production or having a great technical discussion with someone that yields new insights or having a good mentoring session with someone and feeling like I really helped them. Train yourself to see the little daily wins and you'll feel a lot more satisfied and motivated at work. Tracking my accomplishments in my TODO list is my mechanism for making sure I do that.

Tip 3: Set boundaries on work hours from the very beginning...but work hard and efficiently during those work hours.

It's very common for college grads to be single and have some number of years where they have a lot of extra time. Frequently they choose to work very long hours in the hopes that it will give their career a jumpstart. I had a very different experience. I actually met my wife when we were 19 and got married straight out of college, and we had kids relatively soon after. So I never had this kind of extra time to burn at work. However it turned out to be a blessing in disguise as it forced me to limit my working hours from the very start. What I found was that by limiting my working hours, it forced me to find ways to be more efficient in the time I did have. New developers fresh out of college are frequently amazed at how much I can get done in a very short amount of time, and it all comes from personal productivity skills I've worked hard to develop throughout my career.

Sometimes people are still skeptical of this, so one analogy I like to give is from Computer Science. Say you have an algorithm that runs in quadratic time, O(n²), and it's too slow for your use case. One solution is to throw more hardware at the problem, another is to find a more efficient algorithm like one that runs in linear time, O(n). If you ask a college grad which one they'd do, they'll usually laugh and say find a more efficient algorithm of course! To me, adding more work hours is like throwing hardware at a slow algorithm. So how come with code, you'd rather go for efficiency, but with yourself, you'd rather throw hardware at the problem? 🙃

Again, your career will span decades (have I mentioned this already?), so putting the time into making your own personal productivity algorithms more efficient is going to pay itself back many, many times over. It will also make you far more valuable which will make it easier to move around between teams or companies in the future. So stop throwing more hardware at the problem! Limit your work hours, but during those hours, work hard and efficiently. Your output is the critical success metric, not the number of hours you spent working on it. In fact, less hours spent is better, right?

Tip 4: Accept that you will not know every technology and framework and that's ok...but never stop learning!

New developers frequently feel insecure because they know there's a vast array of technologies that they know nothing about. It doesn't help reading comments on some tech blogs where people try to present an image as if they have deep knowledge of all different technologies. Trust me, they don't. The tech field is so vast and constantly changing that there's no way for any one person to know every technology and framework out there. You need to accept that this is ok and you don't need to know everything to be effective.

You want to develop a healthy balance of having very deep knowledge in some focused areas, but build shallow knowledge in a wide variety of areas. Also, this shouldn't be a one-time acquisition of knowledge, but a continuous stream of incoming and growing knowledge so you can keep up with new advances. Sound difficult? It can be, but here's my strategy:

I let my current projects drive the areas of deep knowledge. It intuitively makes sense that you should develop deep knowledge of the technologies and frameworks needed for your current work. As you move from project to project, you'll get more opportunities to add to your areas of expertise. One of the factors you may want to consider in picking a new project or team might be the technologies being used. If it's one you're unfamiliar with, it could be a great learning opportunity. When evaluating technologies for a new project, you might want to pick one you aren't as familiar with, but seems like a decent fit so you can learn it. In a team setting you'll need to get some buy-in from your teammates since they'll need to support it as well, but this can be a nice strategy to broaden your deep knowledge areas.

So that covers the deep knowledge. However you also don't want to develop tunnel vision and lose track of what's happening in the wider industry. So you need a way to keep up with what's going on outside of the area you're working in. My primary mechanism for this is Twitter. If you follow the right accounts, your newsfeed delivers various software development articles, talks and project updates directly to you. I definitely don't stress about reading everything, but I do skim lots of articles on various topics. If I find something that interests me, I might do a couple searches to learn more, but my overall goal is to cast a wide net, but not go too deep unless it's relevant to what I'm working on directly.

This becomes really helpful for general knowledge. However, it's also useful specifically when I'm at a phase in a project where I am choosing technology options. At that point, I'll remember having read something about some other alternative technology that might be a good fit for the project. At that point I can research it further and decide if it's a good option. If so, then I'll be on the path to becoming deeply familiar with that technology.

Twitter doesn't have to be the only source of articles. Email digests can be another good source. I find DZone's email digests to be pretty decent. I also subscribe to Amazon Web Service's announcement email list, since I use many AWS services at work.

One of my favorite things is helping people feel empowered to drive their own career path based on their strengths and interests, rather than feeling forced to climb some ladder of artificial incentives that's been placed in front of them. I've seen these tips help start some people down that healthy path. I hope you find these tips helpful, whether you're at the beginning of your career or have been at it for a while. If you have additional tips to add or things you wish you had known at the beginning, please add them in the comments!