Consistency, Consistency, Consistency

In my career, I’ve seen many processes or policies that I have liked, and many that I don’t like. As you move from company to company you start to realize what works and what might not. Whenever I make a move, I tend to take some of those habits with me to the next place because frankly it just makes sense.

This post will touch on those habits, and the things I do in my professional career (assuming the company doesn’t already have a policy or process that overrides it) that I’ve decided to keep using because I thought they were effective.

Ticket Tracking

Every commit you make should be associated with a task or ticket.

This was one I learned early on, I think the biggest problem with this is most devs / ops guys see this as more of an annoyance than something that can help them.

“I’m just changing this config setting, do I really need to make a ticket?”

Yes. Why, you ask? Because it shows what you are doing with your time and proves you are working. Most companies enforce a policy like this for tracking purposes. If every commit you make has a ticket attached, it’s easy to trace to why that commit is made and there is a paper trail. That part is obvious. However, at the end of the year when your manager / boss / lead / whoever asks you what you accomplished, that is where this becomes VERY useful. I’ve worked at companies where they didn’t enforce this policy and I still did it anyways. It helps me in a few ways:

• Helps me remember all the things I’ve done
• Shows where my time is going. For example, if I’m supposed to be working on a project but my time is being split between someone or something else because of unplanned work, I can now justify why my tasks isn’t complete, or why it’s not as far along as it should be.
• Helps other devs (and myself) remember why I made that commit in the first place.
• Documentation

This all may sound real obvious, but I don’t see this practice enough and it’s something that is far too useful for yourself and for the company you work for.

Squash Your Commits

This is a practice I almost never see, but ALWAYS reccomend. There is nothing more annoying that someone committing 200 times to a master branch and all of them have the message of “test”, “another test”, “syntax error”, “crap”, “why isn’t this working”.

When it comes to your feature branch, do whatever you’d like. There is nothing wrong with committing 100+ times to your feature branch because you’re developing. When it comes time to merge it into master or develop, you NEED to squash those commits and change the message to reflect the sum of your work. Most repos these days have a built in squash feature. If your coworkers are struggling to squash before the PR, make sure you enable squashing upon merge. This is going to keep your master branch much cleaner and make reverting WAY easier.

Do Your Own Research

What this really comes down to is making sure that before you reach out to your coworker to help you solve a problem, you’ve tried to solve it yourself first. Engineers are hired for there ability to problem solve and critically think. If you want to survive in this field, you NEED to be able to think for yourself. Far too many times have I solved a problem for a coworker that was the first result on a google search.

IT IS OK NOT TO KNOW SOMETHING. Really. It’s ok.

It is NOT ok to have your coworkers carry you through your career.

Take your time, work through the problem. Break it down into little steps and conquer those first. If you are truly stuck, and it has taken up a lot of your time then bring it up in standup so the team can help you through the problem.

A lack of critical thinking usually comes from a lack of understanding about a certain topic or situation. If you struggle to troubleshoot containers, it’s probably because you don’t understand them as well as you thought you did.

Be Transparent

As remote work it’s become easier to adopt a mind set of “out of sight out of mind”. Slack has replaced the modern office and we need to show others that we are active and responsive to them in channels. We should be trying to keep as much work related discussion as possible in slack channels and not DM’s, and we should be enabling chatops to further promote transparency which can be beneficial in building highly effective teams. No one should be micromanaged, and at the same time my lead or manager should never be in the dark about what I’m doing or the progress I’m making. Make sure you’re updating your tickets and giving good updates in standup.

Never commit straight to master

This should be a no brainer, but I’ve definitely seen it from time to time. If the new company you just went to (or the one you’re at right now) Allows people to commit straight to master, then that needs to be changed. ALL commits to master should be via PR. This is to protect your master branch, and to allow others to review your code. Even if you are setting up a project for the first time, this rule still applies.

This rule can save you from accidently blowing up a master branch or committing something that you shouldn’t have to a place you shouldn’t have. The rule above all rules is protect yourself from your own failures.

In Conclusion

If you already do all of these, then great! If not, then I hope you consider adopting some for your own. If you have your own habits that you think are useful, please comment below and share so others can possibly learn from it (inlcuding myself). Thanks for tuning in!