Hey, it’s been a while. I started a new job three weeks ago at a company called Race Roster where I will be working fully remotely. I thought it would be a great idea to share some of my notes on starting a new job in a remote environment.
I cannot stress this enough. Life is better when you write things down. My mom tried to convince me of this for years when I was young and I was too stubborn to believe her. I started keeping proper, daily notebooks in June of last year and it has improved my skills as a developer immensely. Since then I have been promoted, led a team, received a few significant pay bumps, and started a new amazing job.
This is a good article on some of the science and methods to take notes, The science of note-taking.
While I don’t follow any of the methods described here I have created some methods of my own and picked up a few that I liked along the way. Every morning I start by creating a list of everything that is in my schedule, tickets I know I have to do, and things that I know must be done but aren’t written down anywhere. I used to just used standard checkboxes and tick them off as I completed the tasks. But what happens when I complete some of a task, but not all of it?
That’s when I read Adam Savage’s Every Tool’s a Hammer and discovered his method of checkboxes. HIs method is when you complete enough of a task to say that you have made progress on it, you fill out half of the box. When you have completely finished the task you fill out the box entirely. He also discusses the ideas of lists and sub-lists which I also like.
In my notebook, I also have symbols for things I should look up later or things that I need to remember to do, which get added to the list (it’s a good idea to give yourself enough buffer room in your initial list creation knowing that you will probably add more items to it as the day continues). For the things that I should look up later, I take either the last thirty minutes in the day or spend some time after work looking up those things and either writing definitions in my notebook or taking notes on the topic.
I also have a notation for questions, but we’ll get into that in the next section.
I like to wrap up a day by writing out “Today’s Recap”. Under that heading, I write at least three things about the day. They can be anything as long as they are work of learning related. I use these points as a way to reflect on the day which helps me wrap things up and forces me to stop working. After I write “Today’s Recap” I can only write about other learning I am doing.
Questions are just as helpful for the people training as they are for you. For you, asking questions provides you with the answers you need to help you succeed. For the people training you, your questions help them understand how you are progressing and it helps them identify any knowledge gaps you may have so that they can address them. It’s a win-win scenario.
Some people like to say, “there’s no such thing as stupid questions”, and I would like to them right now that they are wrong. Anyone who has read Randal Munroe’s What If? will know that there are such things as stupid questions. That aside, your questions probably won’t be stupid. I think the key to doing well though is figuring out what questions you need to ask versus which questions you can answer on your own.
As developers, we are naturally very resourceful. This generally means in the twenty-first century that we know how to Google things well. My strategy is to write down all the questions that I have throughout the day, whether they be small, such as “what does this word mean?”, or complex, such as “how do I implement CQRS in PHP?”. I do two reviews with myself of all the questions I write down at lunch and at the end of the day. During these reviews, I determine which questions can be answered by a simple Google query and which ones I will need to ask a person, like “when do my benefits kick in?” or “can you walk me through the Git workflow we use so that I can see it in action?”.
I take every opportunity when someone says to me, “do you have any questions?” to ask them as many of the relevant questions in my notes. At the end of the day, I look up the answers to all the questions that I thought would be searchable on the internet. Any questions that I am unsure as to the answer to or cannot find myself from what I have searched I will ask a person the next day.
Everyone you work with has a lot to teach you, as long as you’re willing to learn. Being able to learn quickly from others is what will put you ahead early on. Continuing to learn as you move past the introductory stage of your new job is the key to success. There’s a DevOps mantra that says, “it’s not about how high you are, it’s about your rate of climb”. I strongly believe that learning is the best way to increase your rate of climb.
There are many ways you can go about learning at your job, the first is from others. Learning from others can be intimidating at first, but if someone is taking the time to teach you, you should know that it is because they want you to succeed. It is also important to reach out to people from who you think you can learn something. Whether they are senior to you, in another department, or even just working on something you are interested in, try to reach out and ask them to teach you something. It doesn’t hurt to buy them lunch or a coffee if they need some extra motivation to put on their teacher hat.
Another great way to learn is through documentation. More likely than not, your organization has some sort of documentation, knowledge portal, or learning hub. Take the time to read it, and when you do read as much of it as you can. When you come across something you don’t understand or have questions about, write it down and find out who is the best person to answer your questions (this is another great way to learn from others, come ready with poignant questions). I know that reading can be boring, especially documentation, but someone took the time to document that thing for a reason. If you find any incorrect information or inconsistencies, take the time to help correct the documentation, maybe one day someone will then come to you with questions.
Make it your goal to get to know at least one person a week. Take thirty minutes out of your day to sit down with them, learn about what they do, and learn about who they are. These relationships you establish early on will help set the groundwork for your success at the company. Perhaps one day you find yourself sitting down with the marketing team. I guarantee you will have a much better discussion if you have established some kind of rapport with one or more of the members in the past. Buy them a coffee or take them to lunch. I’m sure you can send them a coffee through some sort of delivery app even during COVID.
Workplaces that have cultures where people regularly thank each other in public are places that draw in the best kind of people. Plus, people liked to be thanked for their work. At one of my old places of work, we gave tacos 🌮 to each other as a way of saying thank you or giving recognition for hard work. We used HeyTaco, which is a Slack integration that tracks the number of tacos given and received by each individual.