How To Make The Best of Your New Dev Job

Creed Jarrett Mangrum
Catalant Technologies
6 min readJan 12, 2017

I wanted to share some things that I have learned about starting a new job in tech.

For context: I’m a 2014 MIT grad with ~2 years of full-time full-stack dev experience at 2 different companies in Boston.

I started my new job at Catalant in August 2016, and I’m just now realizing that it’s getting to the point that it’s not really a “new” job anymore. With the new year and 4 months under my belt, it seemed like a good time to reflect on what I’ve learned about this newness. I am far from expert in this area, but these are things that I’ve tried to do, and have so far had 2 great experiences starting new jobs. Hope it helps.

Be open to change

This may seem obvious, as this whole post is about a new job, but I think that this is probably the most important part of starting your new job. New jobs are, yes, ‘new’, but that means more than we anticipate. New jobs come with new people, new products, new commutes, new frameworks, new infrastructure, new expectations, new lunch options, etc. There is a lot of change going on.

Some companies will be more different than others, some will have homemade tree houses in the office while others will just have a ping pong table. Some teams eat lunch together, while other teams hot glue random objects together. Some companies use Django, some use Flask. Some companies use Angular, some companies use React, some places use that other framework that new framework that is the next awesome thing. Some buildings have showers while others do not.

Codpod (triple decker) and its architects/builders, with a hint of red umbrella

The more amenable you can be to change, the more you will be able to adopt the changes into your work life, and also contribute to the ever-evolving culture at your new company.

Be patient

Amidst such great change, you will likely become frustrated that some aspects of your new life aren’t quite what they used to be. Now you can’t <button ng-click="$ctrl.doTheAngularThing"></button> but you have to do the <button onClick={this.doTheReactThing}></button> (yuge differences). Now you can’t R, but you have to Python. Now you actually have to get PR approvals. Now you actually have to lint your JS. Now you have to make daily sacrificial offerings to Webpack (not the Webpack you are thinking about). Now you have to wait until someone can give you the password to get the staging environment data. Now you can’t beat everyone at foosball, because there is no foosball table.

All hail Webpack and Henry (the Champ)

It doesn’t take long to amass a list of changes. As we said before, things are different. Be patient with yourself while getting up to speed with all the new tech and process. Be patient with others who are also adjusting to working with you.

Don’t mishear what I’m trying to say. I don’t mean that you should just sit around and not do anything. “Patience is not passive resignation, nor is it failing to act because of our fears. Patience means active waiting and enduring.” (Dieter Uchtdorf). New jobs are scary. But while you adapt and adjust, do all you can to learn and make good things happen.

You are in a unique position to offer important feedback to your new organization. You are also in a unique position to be able to learn new things: things that people have done differently than you ever have. The opportunity to learn is an excellent opportunity in of itself. If you learn Angular and React, now you get to learn Vue. Learning new things makes your brain happy. I would wager that’s a big part of why you like your job in development. You will be better at learning the next time something in your career changes. You’ll be ready for when one JS framework rules them all. Which brings me rightly to my next point.

Be the change

Don’t be afraid to be different from your new different organization. If you find a different or better way of doing things, talk to people, and see what happens! Don’t be too wedded to your change, as there might be a reason for not doing it your way, but definitely never be afraid to suggest doing something different.

In terms of cultural differences, there is always room for company culture to grow and evolve. The team hired YOU for a reason, so, ‘do you’. Add some rock rings to the codpod (read: treehouse for code (read: cod)) if you are a climber. Bring in a decorative umbrella if you don’t care about bad luck and more about tasteful decor.

High high quality image of me working on the third deck of our beloved codpod (my wife thinks I’m 5)

Be teachable

There are not very many new jobs you will be taking where you will know the most about the tech you are going to be using. You will probably not know the most about the product use case. You will likely not understand the industry as others do. And as a developer, you definitely don’t know how users are really going to use whatever you build. You can undoubtedly learn something from each and every other person at your new company. The vast majority of people enjoy sharing things they have learned with someone eager to learn.

Meet your co-workers.

Ask questions.

People enjoy teaching people that want to be taught, not people who think they know everything better than everyone else.

Be direct about your needs

As much as you think your managers and teammates might know, they likely cannot read your mind. Every person on the team is very different. One of my favorite things about the technology industry is that it is becoming increasingly flexible to different lifestyles. But the people you work with cannot be flexible when you don’t ask for flexibility. If you don’t work on Sundays or the weekends, then have a discussion with your manager and teammates to let them know. If you like get to work early and leave early, then talk about it. If writing unit tests makes you weak in the knees (I guess in a good way or a bad way) let someone know. You will likely, and should, have to write tests, but if you talk about it, then maybe your company will stop writing tests………… or someone could help you learn strategies to write tests more efficiently, so that you too, can write great tests.

It doesn’t do anyone any favors for you to sit on your needs/frustrations and not talk to anyone. Remember, they hired you. If you aren’t getting things you need then you aren’t going to be able to accomplish your job as well as you could otherwise.

Be reliable

One of the greatest things you can do at your new company is show your co-workers that you are reliable. If you have had trouble with reliability in the past, then I would say that this new job is a great a opportunity to reinvent yourself as a person that your teammates can count on. Companies and people value other people who can commit to finishing a task, and then actually finish it.

Reliability is more than just doing what you say you are going to do. It’s about communication. Everyone knows that problems come up. Estimating the difficulty of a task in engineering is very difficult. People understand and appreciate if you are open about the task taking longer than you initially thought. It’s also about finishing what you start. Doing whatever it takes to learn what you have to learn, talk to whoever you have to talk to, find your way to StackOverflow, or whatever to finish what you start, or saying that it’s impossible and provide another option. It’s about being proactive and being honest. If you can make commitments and stick to them and communicate your progress along the way, you and everyone else will be much happier.

Be reliable, be happy. Enjoy your new job.

What have you all done to make starting a new job work?

--

--

Creed Jarrett Mangrum
Catalant Technologies

Writing code, learning things, and going to church. Proud dad and happy husband. Go Sox!