Cover Photo by Gabriel Bassino on Unsplash
A professional in a business that has a net positive ROI beyond their lifetime at a given company.
Short Answer: A professional in a business that has a net positive ROI beyond their lifetime at a given company.
Such a contributor will leave the company in a better state than when they began.
This goes beyond code, you will have changed the team and the business.
But that isn’t the whole story.
A truly senior (perfect) developer doesn’t exist. There will always be gaps in knowledge, not one person can know everything. When moving outside of an area of expertise there are always going to be new things to grasp, learn and understand.
We are all growing, we are all beginning our journey. If we stop changing, if we are the same person tomorrow as we are today — we are doing something wrong.
I prefer this approach instead:
A strong technical foundation is required coupled with the ability to see the bigger picture, question and understand the effects of personal short term actions.
- What is the likelihood that I have increased the stress on other staff members around me?
- Will I personally contribute to resource loss due to potential additional support requests?
- Will I cause a mismatch between customer expectations and reality?
- Can I recommend and implement tooling to ensure that my colleagues around me are more effective?
- Can I be more effective with my resources by pursuing other tasks?
- How can I step up to alleviate the stresses of the people around me?
- What can I do to help bridge the knowledge gap that the business requires?
Notice the above language — this is about taking responsibility for the situation in front of you, manipulating the world and giving purpose to oneself.
There are countless articles and studies on the link between the perceived lack of control and anxiety. If an individual truly believes that their contributions will not matter in the grand vision of a project this can cause them to give up. Stopping them from growing internally and professionally.
Balanced autonomy, the ability to quickly drive decisions by oneself, coupled with a fast feedback loop is extremely important — it provides direction.
Although it is unlikely they will have access to bringing in direct sales or contributing significantly to the month to month cash flow their power is within product creation and people.
Change will always have an impact — we need the majority of our efforts to help drive the team forward.
This could come in various different forms.
- Building, adding new features and taking action. Knowing what corners can be cut to deliver. One of the greatest assets for a start-up is to be able to have a fast feedback cycle with real consumers.
- Adding automation testing and reducing the cost of manual testing and provide more confidence in the code where change is possible in the future.
- Mentoring junior member by communicating in an accessible manner that answers the questions on why an approach is taken rather than just simply how.
- Gratitude. The fact everyone has converged to a single cause is incredible, especially as we have gotten here from completely different paths.
- Sacrifice. Understand that some weeks or months are harder than others there is a flow to a career that isn’t linear if you aren’t moving or learning you are dying.
A reckless individual will cost more then their compensation, even in a company with consistent cash flow the cost on the lives of those around them will be impacted — this could be invisible and unnoticed.
It isn’t about pay, it isn’t about being the most productive in a given team, it is about being responsible, learning from your mistakes and being consistent.
A senior developer is a professional, they get the work done every single day and they commit to guide and mentor junior staff.
On an opposite end of the spectrum a junior developer such a person is considered an investment, they are malleable, passionate and want to prove themselves to those around them.
The overriding price of a junior will be increased by the decreased productivity of the contributors around them mentoring them — an invisible but real cost.
This is why more developers with real work experience or even code bootcamps are more attractive to employers.
The days are dead of a commercial-less graduate having doors opened for them.
Such roles have become a ridiculous lottery.
On average the software development workforce doubles every 5 years, this means that at any one time at least half of the professional developer population has less than 5 years experience.
Therefore there is an inbuilt knowledge gap in the system — by an exponential decrease in contributors with double the amount of experience.
- How long can this be sustainable?
- How long can this scale?
- When will the moment of critical mass occurs when the knowledge gap is too large?
Especially when the demand for technical jobs is scaling on an unprecedented level, there are more jobs then seemingly qualified individuals to fit.
The need for senior developers will continue to rise to teach the new generations. More specifically I predict there is going to be an increased need for individuals that have that focus on training up talent to be effective but in a compressed period of time.
One of my old clients told me something that has always stuck in my brain.
“Don’t assume that as a CTO or as a Senior member that I will always make the correct choice.”
In one of my roles, I was given the opportunity to review code for a number of prospective candidates. This was one of the most professionally enlightening experiences I have ever had, we have all been in that position at one time or another.
Code reviews for new candidates are not about code quality it is about structure coupled with an underlying approach. Ensuring that a given candidate is capable to follow a pattern, curious enough to explore different methods and has sound logic for the application is key.
Condescending elitism has no place for attracting and retaining talent.
At an early stage of a career cognitive pattern recognition for development approaches, implementation and repetition are key.
Spoon Theory, which is a metaphor tied to disabilities such as Chronic Fatigue Syndrome (CFS) describes an individual who has a set number of actions they can take action upon before they are exhausted.
I firmly believe that for software development the same theory holds true especially for cognitive choices, we only have a set number of choices in a day to decide how and why our code should act. Hence why pattern recognition and experience are key, trying to embed the experience into almost a kind of automated muscle memory.
Everyone’s journey is undoubtedly different but months and potentially years can be saved in learning by being correctly taught structure, duplicatable patterns and a mental framework for learning and digesting these topics.
Especially when delivered by a person that has seen projects succeed and fail, who has experienced good and bad times.
We gain the most knowledge from the bad times.
I’ve been fortunate enough to gain metaphorical battle scars from startup life.
- I’ve been made redundant multiple times.
- I’ve had to experience cutting my salary in half in order to keep my job.
- I’ve had to let go individual contributors which didn’t hit the mark.
- In the first year of my career, I worked 80–100 weeks in order to become competent.
Dare I say it — such an individual in the position may only be the only real way for a developer to enter into the domain of 10x. Scaling primarily through the growth of effective talent over the course of a career by sending ripples of value throughout their wake.
This kind of seniority within software development isn’t about title ego it is about reducing the technical pressure that is placed upon the rest of the team. It is about giving junior members permission to ask for help when they have questions, giving them a path and structure to follow when they make their first steps.
Maybe I’m describing what a developer should be, maybe the word Senior is too much of an ego trip — maybe a flat-ish team architecture is preferred.
But playing devil’s advocate if there aren’t targets or a hypothetical path to follow we will stop growing, moving forward, we will die professionally.
Is it better to spread all of these responsibilities to all developers and use that to reinforce a strong work culture?
Maybe as a result of using this approach natural leaders will come out of the woodwork and this force will ensure that team members will gravitate toward them.
Perhaps a hierarchy where junior developers know the right person to speak with is a good thing or maybe would this would be too much pressure on a single individual.
Regardless there is hope when an organization is cash flow positive and a given developer’s value is worth more than the cost then the only business choice is to retain that asset for as long as humanly possible.
Follow along with my posts and my project world class remote.