Switching jobs sucks

You don’t realize how much switching jobs sucks until you do it. I moved on from my first post-college jobs after almost 4 year, and its been more of a shock than I expected. Once you have been working at a company for a few years you start to know everything that is going on. You know how to be productive. You know who is important, what projects are important and have a good idea of where things are going. You know if your job is secure and how to do well. But once you switch jobs, all that goes out the window and you have to start building up your organizational knowledge again. 

The best way to increase your compensation is to switch jobs every 2-3 years. But while that saying is correct it underplays the cost to you of switching jobs. Yes, you are getting paid more. But you gave up your political position in your last company. You lost years of domain expertise and a large number of valuable relationships. If you left on good terms, which everyone should, you will still have those people in your network. But they will not be in your corner for the next political battle. 

Early in your career switching regularly is probably the best option. But as you move up in the hierarchy you may need to stay at companies for longer terms. At the beginning you can get promoted every years, Developer 1, Developer 2, etc. But you reach a point eventually where it takes longer to move up. Going from engineering manager to vice president is much harder to do than moving from senior engineer to engineering manager. You will need to know more people and have a better political position to reach vice president than engineering manger. 

Always squash before opening Pull requests

When you are working on a feature it makes sense to make incremental commits as you proceed with the work. Then when you are done you want to just open a Pull Request and wait for approvals. But it is important to squash your commits into a single commit before merging  into the master branch. The reason is if you need to revert your code change, you can revert a single commit and move on. You don’t want to be in a position where you have a serious bug in production, and you are trying to figure out if you reverted all of the commits. Save yourself the panic and trouble by squashing before you commit to your master branch. Some services like github will automatically squash for you, use that feature if you have it. 

Useful git commands for squashing

# git --amend amends your last git commit 
git commit --amend

# rebase is the command used to actually squash commits 

# git rebase -i HEAD~4 rebases the last 4 commits including the head commit
# the -i toggles interactive mode which opens an editor
git rebase -i HEAD~4

When you run the command git will open a text editor that asks you to choose what to do with each commit.

Example screen when you start an interactive rebase. All commits are picked by default.

The default is the vi or vim editor. In this window you want to change the command for the commits you want to squash. 

Interactive rebase menu

Then the next window will give you a chance to modify the commit message for your new combined commits.

Update the commit message for the squashed commits
Final commit after rebase

Design Documents for Distributed Companies

How do you hash out architecture and design at a remote only company? Slack chats and phone calls are a slow way to communicate with an entire team. And miscommunication with people 1000s of miles away can cost you the time and money you were hoping to save by working remotely. 

The Design Document workflow

Some companies have a design document centric workflow. At the beginning of a project instead of writing Jira tickets or tasking out stories, an engineer will spend some time writing a 3-10 page document which describe the plan of attack for the project. This doc will include assumptions, design decisions and constraints, as well as a summary of the changes to be made. The document is not an exhaustive specification, but can include proposed interface or library changes. Then the team will have a review session to read and ask questions about the design. Next after some revisions, and possibly a follow up session, development will begin. 

Google Docs or any other shared document tool is sufficient to support the document review process. If you want to make the process truly asynchronous you could rely only on document comments and skip the meeting all together. 

Typically, a design document should be required both embarking on any significant project or feature addition. Adding a new button to a web form would not need a document, but building a new web service or adding a major feature would. 

When I worked in a distributed consulting company we used this workflow for proposals and Level of Effort estimates. But software design was usually handled by discussion and whiteboarding followed by implementation with half-hearted documentation occurring at the end of the project. A design document process would have helped share design between the east and west coasts keeping more of our projects on the same page. 

Big Tech vs Little Tech: The problems are the same, but the process is better.

I spent the first three years of my career at a small agency/consulting firm. We did a combination of standard application development and technical management consulting work. We had problems with code quality decline in older projects, issues with pushing out solutions quickly, and we had very poor feedback loops into our software. 

We tried to write quality software and did plenty of testing. The biggest gap was that we sold cloud native architectures to our clients, but we never actually ran cloud native software ourselves. 

One the companies strengths was that our Project Managers would interface with your Product Owners and business analysts to make sure we were building the right software for clients. And because our clients were bureaucratic  cable companies we needed a lot of Project Managers to work with the clients’ bureaucracies. So we ran all the latest Scaled Agile frameworks and helped train our clients to use them. 

I moved to one of the biggest tech companies recently and here we also have problems with code quality in older projects, but this company has much better feedback loops and takes a little more time on developing and vetting solutions. 

Its funny that we spent a lot of time at my last job building continuous delivery pipelines for our clients, but I still never got to work with one. Here at BigTech we have full CD to production despite running one of the biggest websites in the world. 

On the process side, Project Managers don’t exist at all. And there is a lot less ‘Agile’ process on my team. Engineering design is handled with more formal design documents and design review meetings. Designs are written in documents instead of being hashed out on whiteboards during a meeting and only partially documented after that. 

Always be Interviewing

A lot of people feel that they are underpaid or that their job sucks. But when I tell friends to update their resumes and start applying to jobs they dig in their heels. If you are not applying  you don’t have options and don’t have any leverage to get a bigger cut of the money your employer spends on salaries. As Software Engineers we are constantly bombarded by job opportunities on Linkedin and other job boards. If you want to be lazy you could just respond to one of the recruiters that contacts you each week. I have gotten most of my interviews by cold applying on jobs boards. All you need is a good resume and a slightly customized cover letter. It takes me 15-30 minutes to apply to each job, including the time I spend customizing the cover letter. My resume is usually the same for each position because I apply to similar jobs. 

How to pick which jobs to apply for.

When I am looking for jobs, I don’t just apply to anything that my credentials line up with. I am looking for particular companies in particular business sectors, that are using technology that can help me move my career forward. For instance in my last job search, I applied to local Denver startups that used technology that I am interested in. I did not apply to any companies that use Nodejs or C#/.NET as their primary stack because I don’t want to do more work with Nodejs and C#. I mainly applied to companies that had existing Ruby on Rails monoliths that needed to break them up and move them into the cloud. I also targeted companies based on their size and product type. My targets were companies with 50-200 software engineers and with software based products.

Where to find jobs.

I find jobs through the Linkedin, Glassdoor, stackoverflow and buildincolorado jobs boards. I search for ‘software engineer’ and the city I live in as my query. Then I go through around a hundred listings noting the jobs that look interesting and align with my tech stack. I make a list of jobs to apply to and once it hits around 10 in length I will spend an afternoon applying to jobs.