Part 1, Learn you something Important

Context

In 2010, I got my first start up job. After working in a large public company for close to a decade I was completely out of sorts. I was asked to come in for an interview. The office was tiny and crowded, open office style, cheap furniture…everything you would expect from a newly minted series A ( plus some angel investors ). Back then Series A wasn’t shit, you were given money to breathe and not much else.

The CTO was a 20 something and the lead developer was the same. I was a 30 something with a family, it was a weird situation but it was happening. I was the only self-taught person on the engineering team. The rest of the team had CS degrees from big schools. It was apparent to me that I was hired to do grunt work, nothing creative or thoughtful. Just the shit the other guys did not want to touch. I was invisible. I did what I was told and I did it as well as I could. My code was torn to shreds, sometimes publicly in code reviews. Some of the guys were constructive others did it to stroke their own egos, I took the view that this is only making me a better engineer. I asked questions about design and learned to separate petty insults from constructive feedback.

Observation

After a few months a couple of the engineers showed me some marginal amount of respect but the organization overall could care less. I like being the center of attention, but I also understood that this was a new environment with a whole lot of new variables. If I was going to pop up on anyones radar at the company I had to become valuable. I realized I was not going to out “software engineer” the leads ( they all had tons of experience ) — so I waited and observed the day to day situation.

I started realizing that the organization was struggling with GIT . I would hear folks complaining about merge conflicts, I noticed some folks where holding off on merges to avoid issues. It started becoming clear that the team knew a ton about Rails, Ruby, Javascript, AWS but we needed deep and advanced GIT knowledge and no one had invested the time to learn it. We had a Senior Consultant that would help with DevOps from time to time and he was the go to person for GIT related issues. As such I decided to learn more about GIT. Let me pause here and say I was not really passionate about GIT but I realized a need and decided to pick it up and gain deeper knowledge so that I could gain some more social capital within the organization.

Back then there was an awesome video tutorial service called PeepCode and they had a great session on GIT. I joined up and took the courses. I watched Youtube videos and read a ton of blogs about GIT CLI and various ways of resolving conflicts. I learned about rebase, I collected like 10 to 20 git log one-liners each would surface some valuable piece of data. I learned about refs and reflog. A lot of the stuff, I was not really sure about but still I tinkered around and gained some understanding.

Taking action

Next, what I did was every time someone got stuck on a git issue I popped up and began making helpful suggestions. I did this without condescending, without mocking. Just monotone words that might spark ideas. With time I became the goto guy for these types of issues. My learning of git snowballed, I did not really intend to become the resident git expert but I headed that way.

One night right before doing a large deployment the CTO noticed a bunch of code on master that was accidentally committed. He was trying to make sense of the commit history by viewing it on Github. I inserted myself and started running my git log one-liners. He immediately saw the value and soon I was driving using my computer to dissect the branch. The CTO seemed relieved and thankful that I jumped in and helped with the Git side of the equation. Long story short, we recovered some commits and we hid a few features that escaped and got merged in.

Within the next few days I was invited to have breakfast with the founder. From that point on a few things happened. My code reviews were no longer a public beating, the CTO intervened and decided that all code reviews would be done in private behind closed doors.

Take Away and some ideation for you to begin working on.

The take away here is not to join up as a noob and learn git. Although learning git can be super important. The technique for the newcomer here is to be patient and observant. Look for a piece of tech that is mission critical and others are not focused on it. Become the knowledge base for it. This will not be sexy, it will be painful — but it will remove the newcomer scent off of you.

Here are some handy tips and pragmatic approaches to help you gain ground:

Maybe at your company git is not the issue. At many full-stack companies the biggest issue is having someone that knows CSS and the tooling eco-system around it well. If you are in that environment and you realize people have no idea how to do complex work with styling, you can learn that.

Another good area to focus on is Analytics. Engineers cannot wait to build a data pipeline but fall short of learning the data visualization aspects. Learning the front end charting eco system and/or tools like Domo or Tableau can make a huge difference in where you go in an organization.

Learning the data-viz part of analytics will immediately get you meetings with the CFO, CMO and other folks in the organization that can get you titles and promotions easily. By no means am I advocating leaving your bread and butter programming skills, I am advocating adding to them. That is the an important way to think about everything I am saying. We are not modifying we are interested in extending

Next article: Part, Work faster and better

This article is part of a series.

Start Here