1. A few words about my job

I am working on a small team with just one other full-time junior dev and our CTO. We are building a Phoenix/LiveView app for a small business from scratch. This has given me the opportunity to work on a variety of things, including areas in which I had little prior experience, such as LiveView and frontendy stuff.

Needless to say, I have been learning a lot. And while I am amazed about how much more technical knowledge I have now compared to when I started, I feel like I have learned (and am still learning) even more outside the code as such. Here is a collection of these non-code things I learned.

2. The importance of Git

My team uses GitHub, which is likely what most dev teams use to collaborate. It has been a huge advantage for me that I have been pushing code into GitHub repos from the very beginning of my coding journey and that I have been collaborating with others on GitHub. Thanks to this, I was familiar with the basic Git commands and - for the most part - knew my way around the repo, rebasing and the less pleasant things, such as merge conflicts. If somebody asked me what I recommend new developers learn before starting their first job, Git would be my number 1 recommendation. There is a ton of resources online and it is extremely valuable to have a solid Git routine.

My main Git tips are:

1. Rebase your branches off main as soon as something new gets merged into the main branch. Nobody wants to deal with a merge conflict on a branch that is multiple commits behind the main branch.

2. Try not to have multiple branches/PRs open. Finish one thing, put it in for review and move on to the next. Unless of course, you are stuck or a PR with higher priority than your current one has been assigned to you.

3. Don’t copy code between branches. Just don’t.

3. A good process

One thing I learned from my dev husband (Hi Alan!) is the importance of having a good process in place. By that, I mean finding a good way to tackle work and responsibilities consistently every day. A routine if you so will. Everybody is different, so what works for me might not be the best fit for you, but here are some more general tips:

1. Find your prime work times. I’m that weirdo who likes early mornings (and also Mondays), so I try to get some deep work in early in the morning before my family wakes up. I’ve noticed that my brain stops functioning somewhere around 5 PM, which is why I try to stop before it grinds to a complete standstill.

2. Establish routines. What do you do when you first switch on the computer? What works best for you? Find out and do it consistently. I have made it a habit to check the main branch of the repo before I do any work and rebase my branches if need be. I also start work on a new ticket in the same way every time. Having these routines in place is one less thing to think about.

3. Make notes for yourself. I find it helpful to write down the next steps for the ticket I am working on and to leave notes for my morning self every evening before I shut down for the night.

4. Set-up

Less than two months into the new job, and I don’t recognize myself anymore. I vividly remember telling somebody less than half a year ago that mechanical keyboards were weird and that I hated the sound of my husband typing (Cherry Brown). Guess who is clicking away on Cherry Blues now? I also invested in a bigger screen. But you know what: it’s worth it. Having the ability to see my ticket, my code editor (in a larger window now) and what I’m producing on localhost has improved my life tremendously. Here is a picture of my current setup. Luckily my little desk has a drawer. Otherwise, I would have needed a bigger desk. Shout out to my son, who let me borrow his Squishmallow as a rubber ducky substitute. Now I am slightly less crazy because I’m talking to the Squishmallow and not myself when I’m coding.

5. Communication

Working on a team means working with other people. Hence, good communication is essential. Communicating effectively can be more challenging when everybody is working remotely and most communication happens asynchronously via Slack messages. No immediate feedback. No facial expressions showing that your joke was received well or indicating that there might be a misunderstanding. Based on what I heard on various podcasts, learned from my mentors and figured out myself, I found that these strategies work well for me:

1. Be assertive yet friendly. I don’t like beating around the bush, but stating things clearly doesn’t mean one has to be rude.

2. Add some emojis. They help to express the sentiment behind the words.

3. Ask questions instead of criticizing right away. I sometimes assume that the other person is off in the wrong direction, but I have to learn afterwards that they were right. By asking questions, I a) learn something and b) don’t look like an idiot for making a wrong suggestion (though admittedly, I have done that …)

4. Use the hamburger strategy. This one is particularly good for code reviews: you start the review with something good, add questions/suggestions and top it off with another positive statement.

5. Ask for help (after you’ve made a reasonable attempt to figure things out). It’s okay. It shows teammates that you are not perfect and might encourage them to ask questions themselves. Plus, it can be an awesome opportunity for knowledge sharing. By asking for help and advice, you also show your team lead where you’re at and where you might need some mentoring. Remember, it doesn’t help the team effort if you are stuck for days and too scared to ask.

6. Somewhat related to the previous point: tell your team lead/manager what you need. It is part of their job to support you, and if you are upfront about what you need, you make their job easier.

6. Work-life boundaries or the curse of notifications

This one was a hard lesson to learn. I knew that I could only work so many hours per day. I’m an early morning person who tends to fate later in the afternoon. I’m not productive anymore. There is no good reason for me to work until late. Better to rest and be fresh in the morning. Sounds reasonable. But it’s so hard! There were many days where I stayed on the computer much longer than I had originally intended. And what made matters worse: I had all my notifications on. So even after I had switched off the computer for the night, I would still see if somebody messaged me on Slack or would get an email notification about a code review on GitHub. This didn’t make for very relaxing evenings and/or weekends. I wish I could say that I have this one figured out completely. I’m getting there, but I’m still relapsing sometimes. If you want to be smarter than me, follow these seemingly simple tips from the get-go:

1. Set up your GitHub notifications: avoid having GitHub notifications sent to you by email. Instead, set aside specific times during the day when you check your notifications directly on GitHub.

2. Set up your Slack notifications so you don’t get email notifications outside your working hours.

3. Remove Slack from your phone. Trust me. I thought for the longest time that I could have Slack on a separate screen and would be able to resist the temptation to check my work Slack. Spoiler: it didn’t work at all.

4. Don’t work passed the point of exhaustion. When you are getting to the point where writing code feels like walking through molasses, stop. Make notes, so you know where to pick up in the morning and shut off the computer. You’re done. Let it go!

5. Don’t let FOMO ruin your boundaries. If you have flexible working hours and are getting your work done, there is no reason to adjust your work-life patterns to those of your teammates. If they decide to work on the weekend, then that’s their choice. It does not have to impact you at all. Special tip: if you are prone to FOMO, it REALLY helps to stay away from Slack and your work GitHub repo on the weekend!

Final thoughts

I hope some of these tips are helpful to you. I’m now heeding my own advice in my second job, as my first one ended rather abruptly. The company I was working for ran out of funds and the whole dev team was let go.