I don’t think it’s much of a stretch to say that the majority of people reading this column are senior developers (or beyond) or are quickly progressing to be a senior engineer. This column is primarily directed towards the senior developers or managers of senior developers. It’s about how can you level up yourself, but more than that, it’s about the responsibility you have in leveling up those around you. As a senior engineer your job responsibility doesn’t end at producing loads of code or being the subject matter expert on your projects.

Why this topic?

Every month for the last 17 months or so, either I come up with a topic to write about or Oscar suggests a few and I pick from something that sounds interesting. It’s not always easy to choose a topic and keep writing month after month. This was one of those months until a couple of days ago, I saw this tweet from Kayla Daniels:

There’s so much wisdom and truth to that. If you’re working as a senior developer and you’re only focused on advancing yourself and your own skills, you’re doing yourself, your company and your coworkers a disservice.

What does a Senior Developer do?

Clearly, part of the role of a senior developer is to develop code. But that’s not all. In my previous position, I worked my way up to a senior developer position. I wrote a lot of code, thought I was pretty good and ended up as the subject-matter expert on nearly every aspect of the projects I was working on. I had a few coworkers and tried to ensure that everything I was doing was clear and understood by my fellow developers.

At my current company, I came over as Directory of Software Engineering, being recommended by one of the people that I had worked with previously. One of the things I’d noticed as I started doing a lot of interviews was that there was an enormous range of skill level between developers who came in to interview, even when they might have the same title. Specifically, it seemed that most places promoted developers to the “Senior Developer” or “Senior Engineer” title based primarily on a certain number of years of service or experience, rather than any specific skills or responsibility they displayed. I decided early on that I wanted to establish some standards for job titles and what that meant.

My first stop was Google, trying to see if anyone else had written and shared anything regarding job titles, responsibilities and expectations and what each level meant. I came up with nothing. Either no one had done this before, or if they did, they didn’t want to share. So I decided to write my own and align my developers into the levels. By writing it all out and sharing it, the idea was that developers had a very clear indication of what it takes to move from one level to the next, of what’s expected. It did mean that some people we had or that we would hire would be coming in at a “lower” job title level than what they might have had at another company, but I wanted to ensure that at least within my company, the titles meant something.

I haven’t shared this list outside of my company until now, but I feel that sharing it with you might help you out, help out your company and help you level up. The way it works with my company is that developers are expected to be performing everything in the level they want to be promoted to in order to be promoted. We don’t promote and hope that you’ll eventually grow into the title, we expect you to expand your skills and responsibilities, and then we upgrade your title to match what you do. The follow is the list of titles and responsibilities that I came up with.

You will notice a theme among these descriptions: quality, mentoring, design and architecture. As a developer progresses through the ranks, they should be producing higher quality code. Typically this is less code that is more flexible and has fewer bugs. This is the quality aspect. They should be working towards increasing the skills of their peers through teaching and helping. This is the mentoring aspect. Typically junior level developers aren’t going to be asked or expected to build an application from the ground up. However, as a developer progresses, there will be more expectation that they’ll be able to not only understand how an application is built, but be able to design and architect new applications and products. Additionally, it is expected that the ability to successfully build working maintainable software becomes more repeatable as the developer grows in their skill set.

Software Engineering Job Levels and Responsibilities

At all levels of Software Engineering, it is expected that the individual is striving to learn and improve their craft. Suggestions for process improvements and changes that benefit the component, team and the company are always welcome. Engineers at the lower levels are expected to learn from more senior engineers and senior engineers are expected to mentor junior engineers. Progression through the levels is not only limited to certain times of year. It is expected that engineers who wish to be promoted exhibit many, if not all, of the skills and responsibilities required in the higher levels. Engineers should strive to improve themselves and their skills.

Software Development Apprentice

As a software development apprentice, you are expected to be able build simple functions, classes and methods with supervision and heavy review. This level is reserved for developers new to development and with no real practical, real-world experience.

The developer is expected to be able to complete simple functions and methods with moderate supervision and direction. Learning about the SDLC and unit testing is also expected.

Software Developer

The Software Developer role is for those who are just starting out in the software development field. This role should be writing simple classes, methods and functions and learning about the SDLC, including reviewing code, unit testing, documentation and coding styles and source control. At this level coding may be more of a “code by coincidence” than coding on purpose, but it is expected that an individual will move out of this level quickly.

The key to this level is that there is a lot of learning taking place and the individual should strive to learn as much as they can to progress to Software Engineer. Individuals at this level may have only some familiarity with a few of the components of the system they are working on.

Software Engineer

As a Software Engineer, coding is now significantly more deliberate and less “code by coincidence”. The individual should be comfortable with basic unit testing concepts and be able to write simple classes, methods and functions with some instruction but without much supervision. The individual should be paying more attention to details and beginning to emphasize development testing of their own code to eliminate all classes of obvious problems (syntax errors, invalid function calls, etc) and should be working on increasing the value their tests provide to the application. Software Engineers at this level should be quite familiar with several of the code components and possibly advanced understanding of a few.

Senior Software Engineer

The Senior Software Engineer has an advanced knowledge of many of the components in the system and has likely written or been a key developer on several, and may be the expert in some of the components. The individual can design and develop classes, methods and functions in a repeatable fashion and rarely is writing code by coincidence. The Senior Engineer will program unit tests written that are valuable in ensuring the system is functioning properly. The Senior Engineer is developing with an emphasis on building and maintaining quality software.

At this level, mentoring is occurring for more junior level team members. The Senior Software Engineer should be able to create designs and plan for more complex interactions between classes, modules and functions but may still need help and supervision and review of some aspects of the design. The Senior Software Engineer will be heavily involved in reviewing other developers’ code and making suggestions to ensure the quality of the final product. At this level, the engineer can take the lead role in design and development of small to medium components of the system with the expectation that they are reviewed by peers and more senior members of the team.

Staff Software Engineer

As a Staff Software Engineer, the individual will be mentoring junior developers. The focus on quality has increased beyond that of a Senior Software Engineer. Advanced unit testing, including a good understanding of mock objects and other testing concepts is expected. The Staff Software Engineer should be able to identify anti-patterns, poor development practices and other issues that would lead to increasing technical debt and fix them.

The Staff Software Engineer is able to design and develop modules of moderate to high levels of complexity with minimal supervision. The ability to design and think through how software works is critical at this level. The Staff Software Engineer is likely a lead on every project they are working on, or else involved with ensuring that Senior Software Engineers are properly leading the projects. They are responsible for ensuring quality for their team for the modules that are assigned to them.

The Staff Software Engineer has a thorough understanding of the entire system or application and is at expert level on many of the components.

Principal Software Engineer

At the Principal Software Engineer level, quality is of utmost importance. Engineers at this level are likely practicing and encouraging test-driven development with the rest of their team. They are able to plan, design, implement and lead a team through the full Software Development Life Cycle. Unit testing is a given and identifying incorrect and useless tests by review is expected. Suggesting and implementing valuable testing procedures is required. Suggestions for problem-solving and process improvement are also expected at this level. Mentoring should be continuing and Principal Software Engineers should be mentoring other mentors as well.

Research, finding and suggestions of new software engineering practices and tools is expected. Principal Software Engineers are consistently successful in the delivery of projects and software components as well as successfully motivating the troops. This individual is critical to the success of the projects which they are assigned and will likely play an important role in design and decision making on other projects and products to which they may not be directly assigned.

Beyond Senior

As you’ve probably noticed, I went ahead and included two levels that go beyond the senior level, placing more emphasis on quality, mentoring, design and architecture. I wanted to provide a path for people who are good at tech, really like doing it, and don’t feel that management is the career path they want to head down. It’s not uncommon at larger software companies to have an advanced tech path, and I wanted to provide it at my company as well. Too many employers see senior developers as the next managers even though they may not be good at it and may not have any interest or aptitude for management.

With Great Power…

At each level I’ve outlined the responsibilities, actions, and characteristics that I would expect to see from a developer at each level. Starting out, the emphasis is on learning and improving one’s own skills, understanding how to build good software that is maintainable. Once we reach the level of Senior Software Engineer, the focus starts to shift outward with the Senior Engineer mentoring the more junior members of the team. As I mentioned, Kayla’s tweet was what gave me the idea for this article, but also deserving of credit was this tweet in reply from Laura Thompson:

Before I continue, I want to say, if you’re not following Graham (@greydnls) or Laura (@lxt), you should be.

If you’re in the role of Senior Developer or Senior Engineer or something higher, your responsibility, your challenge, is to bring up those around you. It may mean that your total output in terms of code may diminish, but that’s ok. Suppose you’re the Senior with eight other developers. If you produce only half the code you would have, but each of those other developers improves by 10%, it’s a huge win. And the reality is that a 10% improvement of a junior developer who has a good attentive mentor is on the low end. I’d expect it’s probably closer to 20-50% improvement, if not even higher. This points at mentoring being a huge win for everyone involved, from the junior mentees, the mentors, the team and the company.

How Can You Do This?

Again, it’s hard to see your code output decrease. It happens. You may be seen as your team’s “rock star” developer, the go-to engineer that everyone relies on in order to get things done. It can feel good to be that lynch-pin, but by holding onto knowledge, becoming that island of getting things done, you’re doing yourself and others a disservice. There’s a well-known term in the industry for how many or few people hold the critical knowledge about how the system or software works. It’s called “Bus Factor,” and it’s essentially referring to how many of your developers being “hit by a bus” would bring progress to a halt.

While being a bit macabre, the “bus factor” is an important concept that needs to be understood, not just by the company, but by the developers. Being hit by a bus could just as well refer to a developer getting sick, leaving the company for another opportunity, or just taking a vacation. If you’re getting a phone call when you’re on the beach about how to get the message queueing system you wrote to start back up, or how to stop emails from sending because a customer messed something up, you are the bus factor.

Additionally, the “bus factor” can be triggered by burnout. This is typical when projects are poorly managed and results in “death marches”, excessive and continued overtime, and a feeling of helplessness and despair. I wrote more about this topic in the July 2015 issue of PHP|Architect, and I’d recommend you check it out if you haven’t already. Burnout can become a bus factor even if the developer hasn’t left as the quality of their code declines to the point they are essentially making negative contributions to the code.

Some developers, sysadmins and other IT workers like to build software in a way that’s hard to understand, obfuscated or just plain weird because they feel that if they are the only person who knows how to do something, they’ve got job security. The reality is that they’ve put themselves in the position of being the bus factor and have likely ensured they are indispensable, so much so there may be no promotions, other opportunities or other career advancing opportunities available because the company cannot afford to lose them. At least not yet. At some point another engineer will come along that can figure out what was done, why, and fix it which means the original engineer will no longer be able to hold the company hostage.

Instead, I recommend working to make yourself replaceable. If you’ve developed new processes, code, systems and software, and documented them well, trained up fellow developers on how everything works so that any of them can do all of it, you’ve opened the possibility of promotions, new projects, new opportunities and more interesting work. And in seeing how you handle this, the developers that you’re training and mentoring will see you as an example of how things ought to be done, and hopefully follow in those footsteps, training the next generation of developers to understand those systems and the new ones they create.

It’s About the Mentoring

Whether you got into this industry following a degree in Computer Science or similar, or didn’t go the college route and taught yourself to code, or some other path, you’ve got skills and ideas that others can learn and benefit from. This is regardless of what level of developer you are. Sharing this knowledge and teaching others is a great way to increase your own understanding of the topic. If you’re in a senior role or above, you should be doing this already with your coworkers.

If you’re not doing it already, I’d encourage instituting “lunch and learn” sessions, where a developer can teach the others about something in software, whether it’s a new technique or a better explanation of the basics. If you don’t have anyone who wants to present, Cal Evan’s offers discounts on his Nomad PHP or Day Camp 4 Developers (DC4D) video licenses for teams to help facilitate these learning sessions. Since sharing your knowledge can help others improve, you can do this even outside your company. Get involved with your local user group and give a talk. Submit a few topics you’re interested in to a conference and speak about it there. You can record screencasts or Google Hangouts on Air of explaining topics and offer them for other developers to consume and learn from. Blog about things you know to share your knowledge.

On freenode IRC in #phpmentoring and at phpmentoring.org, you can find a great group of people in the PHP community who have a goal of connecting mentors and mentees. Some members have these relationships in both directions, being mentored in some areas by people who are more skilled and have more knowledge in some areas and at the same time sharing their knowledge and mentoring others in their areas of expertise.

Sometimes managers are hesitant to advocate for training for their people. I feel this is a huge mistake. Learning is vital. The following is cliché, but I feel it’s completely true. The story goes that a manager was trying to justify a training budget for her developers. Her manager argued that by providing training, the developers would have better skills and be more likely to leave or be poached by recruiters. She argues back that while that is true, what happens if they never learn new things, and they stay. Developers who are challenged and continuing to learn are more likely to stay in a position, all other things being equal.

Climbing By Pulling Others Up

While some individuals climb by stepping on others and pushing them down in order to gain a higher ground, a much better way is to pull others up. Share your knowledge, train others, learn new concepts with the goal of sharing that knowledge. The reason many people are senior level developers or higher is not because they’ve done everything right, but because they’ve made more mistakes and know how to recover. I’m able to help people at work sort out problems and issues quickly because chances are I’ve made the same mistakes in the past and can help them identify the problem and gain knowledge more quickly by avoiding making some of the same mistakes I’ve already made.

Closing

Build others up, share your knowledge, present at user groups and conferences and improve others. As a senior developer, you should be helping make others into senior developers. It will help them, it will help you, and it will improve your company, your community and your career. See you next month.