read

This is a continuation of the series of articles on the valuable lessons I've learned while working at Flite.

You can find a list of the articles in the series here.

Arbitrary Measurements of Seniority

I had a wonderful coworker that my product manager would affectionately call Grizz, so what's what I'll call him. Grizz had been working at the company for 10 years, so he knew the ins and outs of the platform. I would say that Grizz was a Senior Engineer but it was neither the years he spent nor the platform features he worked on that made him senior in my mind.

It's not a giant secret that the industry at large has a hard time defining what "Senior" is. Stack Exchange has a lot of opinions on it from "it's just a platitude" to "it takes 5-10 years" to "don't try to put me in a hierarchy".

A podcast I listen to even tried to categorically go through the requirements of a senior engineer:

  • Proficiency in a Front End Language and Framework (JS, Backbone, Angular, Ember, React)
  • Proficiency in a Backend Language (Java, Go)
  • Proficiency in a Scripting Language (Python, Ruby)
  • Proficiency in a Shell Scripting (Shell, BASH, CSH)
  • Proficiency in a Task Runner (Grunt, Maven/Ant)
  • Proficiency in CI, Provisioning and Deployment (Jenkins, Chef, AWS)
  • Proficiency in a persistence framework (MySQL, Postgres, Cassandra)

Even if I do satisfy these seemingly arbitrary metrics, I read an article a while ago that I more inclined to agree with. (I can't find this article right now, but I'll correct it later when I manage to find it again).

The article talked not about the idea of Junior, Mid-Level and Senior developers, but more of the realm of solving problems. I found the article inspirational, but I'd like to give my own spin on these ideas.

Group 1: Quick Winners

This group is given tasks, typically as part of a larger project, that exist on the continuum of "change this to use a function that exists in firefox AND internet explorer 9" to "debug and refactor multi-threading issue".

The difficulty of the task is irrelevant. The point being is that the task domain is mapped out for you and you are solving an already existing problem.

Early on at Flite, I would say I would lump myself in this category. I was the king of quick wins, quashing bug after bug and pushing out feature after feature.

This is not necessarily a bad place to be. It is vital that an organization have engineers capable of knocking out tasks with high velocity.

Group 2: Problem Mappers

These are the people that know what's going wrong in your products. They see where things are going wrong and instead of just plugging holes in the boat or bailing water, they stop the things that is making the holes.

At this level, you're more likely to be proactive about prevenative and improving measures. Code reviews become important to maintain a level of code quality and mentor others. Style guides become very useful for uniformity and easy of debugging. Continuous integration becomes vital to avoid regression.

Theses are the engineers the refactoring of older features and deliberate on new features. They are the bread and butter of any organization and without them, the quality of the codebase would disintegrate.

In addition, these people will make themselves available if need be for others to learn from them. In most cases, this means learning specific pieces of code or styles of development.

Group 3: Precogs

While this group may not be able to literally see into the future, these engineers make the rest of the team feel like they have this ability. These people are the earthquake researchers of your team. They seek to understand what problems will eventually befall you or the solutions that you will eventually need.

This can mean a number of things. Maybe it means that they know they need to gather requirements from a larger sample of people for acceptance testing. Maybe it means they suggest to expand cdn hosting to Eastern Europe before major feature launch. Maybe it means they see a need for an analytics report that combines 4 other reports people use frequently.

In addition to all of these wonderful things, people in this category have the amazing ability to bring those from other groups up to their level. Some might even say the best and strongest ability of these types of developers is their ability to mentor others. Unlike the previous group, these people help others learn not just how to code better but how to think better and work better. They display a level of empathy and understanding that inspires others to do the same.

Where am I in all this?

The question that everyone is always asking. When I came into Flite, I was definitely in the 1st camp. Give me a bug and I'd squash it flat in record time. Browser compatibility issues? No problem. Job scheduling flub? Pshhhhhh. I knew, however, that there were many other things for me to learn and I did my best to seek it out and be as inquisitive as possible.

Fortunately, I was lucky enough to work with a person like Grizz. He helped me "level up", if you will, into a much better developer. I gained a keen sense of how our stack worked, how to write technical documentation in a more intuitive way, how to give better code reviews, important parts of a style guide and how to implement high coverage, intuitive tests to prevent regression. I also did my best to quantify the best ways to improve the platform through profiling and analytics. I deployed my own services and gained a greater appreciation for operations.

While I still don't know what a "Senior" developer is, I believe I've helped nail down for me what it means to really positively effect the systems and people around you.

Blog Logo

Kurt Bartholomew


Published

Image

Tangentially Related

The musings, lessons learned, and possibly appropriate opinions of a scruffy rapscallion named Kurt

Back to Overview