6 min read

Onboarding at a new company

It's important to be introspective and identify issues with yourself
When on onboarding at a new company it's important to take it easy on yourself. This doesn't mean that everything will not be your fault; however it does mean that it's important to remember that this is a hard process. What this does mean is that using a combination of tactics of identifying your strength and weaknesses when approaching a new company is important. So let's pack this up and see what it's all about.

One of my best friends once gave me the best compliment I do believe I have ever received. "Sam I think you are the most adaptable person I know", this goes a long way for a person like me. I actually eschew the life of the single-product developer at this point in my career for a few reasons. One is that I think it's better for me to get exposed to as many environments of coding as I possibly can. The other is that I don't like to work with the same API interfaces ALL THE TIME. There's nothing wrong with the single-product developer; however, I do think there's a lot to learn from not working in that environment....especially for the new developer, which I am.

Things I identified

I did not understand getters/setters for multiple API environments. This is hard, there's no right answer to this fix. A lot of this goes down to your ability to utilize the documentation of the many repositories or modules your company is using. Is your company going heavy on vanilla javascript, es6, or using 3rd party modules to complete many of its tasks. If the answer is that 3rd parties, unfortunately that's bad news for you. You're going to slip and fall a lot learning this, and the best thing to do is just ask a bunch of questions.

My knowledge of standard patterns was weak. To combat this, the first thing I did was start practicing GoF Patterns. I needed to understand better what I was doing. Am I using a creational or structural pattern to complete my objective. I had to take a bite out of humble pie and go back to the basics. This meant doing things like creating a warmup activity to do every day. In this warmup I would do things like simple maps, or adding complexity and reducing over objects to create patterns that would be applicable to my job.l

Be Humble

Let's face it, people are going to be better than you when you're first starting. This by no means has any bearing on how good you are as a developer. The owner of my new company messaged me and gave me some really good advice "Maybe you need to lower your threshold for asking for help Sam". This really means a lot and it also means that I needed to take that to heart. It also means that the more humble you are the more people will want to work with you and help you grow your skill set. People like critque....what they DON'T like is a critical critiquer. Take it easy folks, learn about what you're being asked to do first with an open mind and a willing heart!

Things I have learned about working when it is my turn to set up a project.

It is important to develop for your subordinates. Sometimes it may make a lot of sense to you to abstract your patterns, but does it make sense to other developers? Is your company growing, maybe this wouldn't be the best time to build difficult abstractions and keep things simple and maybe forgo that extra module that does something cool. I really want to emphasize the understanding of getters and setters in this situation. It's important that your new employees can understand these.

Is your API light or heavy? If it's heavy and going to be pervasive through out the app, maybe there is a more user friendly API that won't be stuck to certain constraints. Sometimes it's best to do just do things the manual way. As a contractor we get into this "boilerplate methodology" where we use boilerplates to build apps for customers, and in retrospect this helped when the company was small, but it wasn't conducive to a growing company. When you build with a Greenfield Mindset sometimes it's best to just leave the past in the past and just move forward and build your own things.

Sometimes software libraries other people have created were originally created for projects that may or may not coincide with your current project. Don't get bottlenecked into thinking that their way is the right way. sometimes it is good to voice opinion on this early and often which leads me to my next point.

It's okay to have an opinion....with tact.

This is totally okay! You were hired for a reason, and more than likely it was to do more than just click and clack away at a keyboard showing of your insatiable skills for using the many iterative methods of code to produce arrays that fit perfectly into a frontend structure. Now, I'm not saying you should talk ALL the time, that's annoying.

Utilizing tact when dealing with co-workers is essential. My first boss told me every code review is a gift. I have learned in my time programming that even having someone with a significantly less skill set than your own review your code can be just as useful as your senior. Sometimes the best opinions come from the freshest eyes, and also the worst opinions. Save your opinion for what you know.

If you see a bad habit forming, speak up! Do not let other people suffer because you could have said something. Hell, don't make yourself suffer because you could have said something. Just address it in the right way. People WILL ask for your opinion, and when you are afforded that chance, don't hesitate to voice what you want to say. There is a saying "Don't knock it till you rock it". This applies to a new job too. Don't like the methodology? Give it a chance, perhaps it was built that way for a reason you don't fully understand yet..

Not all issues will be with yourself

This is hard to understand, but over time finding out where your co-workers strengths and weaknesses are will need to happen. Admit it, you have weaknesses to, they may be more in the social spectrum than the technical spectrum, but we ALL have weaknesses. Find out what your weaknesses are and partner with someone who's strong in that area, and ask them for help. At the same time you may be asked to fill that gap. Fill it, and respect the person you're assisting. The code review you give today could be the code review you get tomorrow.....It's a nerdy golden rule.

Do not silo your communications

This is hard to do because Slack. Don't hide out in private chat rooms unless they're needed, let as many people know what you're doing. If you're talking in an open channel chances are someone with the answer to your question is going to skim over it at some point.

Onboarding is hard, make it less hard.

What are some good ways to have fun while onboarding? Perhaps it is a warm up exercise every morning, both mentally and physically. Try stretching when you get to your desk, I did....and it helped! You can also set up and self-identify blockers for your learning and onboarding. Practice what's blocking you! Is your company using a lot of es6 one liners? Try making some of your own and practicing them for readability!

Lower your threshold for asking questions.

The best advice I had during onboarding was from my boss telling me to "lower my threshold for asking for advice". This helped immensely. Don't spend an hour grinding at something when you know the answer is only a private message away from a colleague. Trust me, your PM will be more happy that the issue is fixed in a timely manner than that you ground out the answer the old fashion way.

You're new, everyone knows that

Eventually you're going to get put to the task, but while you ARE new, do the new person things.

Have fun learning your new environment

It's a new job, enjoy it. It's a chance to make new friends, and learn new knowledge. Find the places that you want to improve, and identify them and improve upon them. Find out what your company can do for you, and what you can do for it. Most of all remember to go easy on yourself! Sometimes jobs just aren't the right fit for us, but sometimes our job is amazing, we're just one open minded step away from realizing it!

Have Fun!

Sam Clark

Sam Clark

Read more posts by this author.