Growth is the most common characteristic of life. It’s in everything around us. From the smallest organisms to the forever expanding universe around us. Everything aims for growth in one direction or another. Some of it happens naturally without any manual interference, and some of it requires the extra effort to change from one state to another.

But growth without a measure is hard to track. Some may consider their growth non-existent if they don’t have the measures to realize it. But more importantly, growth can be in any direction. You can grow in the wrong direction, building the wrong skillset, investing the wrong industry or spending any effort towards something far away from one’s goals.

What that means, is that growth requires a compass to ensure efforts are going towards the right goals, but more importantly it requires a standard for measuring the progress to adjust and understand one’s own momentum of growth.

Having a compass and a standard is like knowing the path and walking the path. The path that one has to take to grow in any field or any direction. But the most important part of the entire process of growth is the passion to power through. Knowing the path and walking the path can all fall apart if one doesn’t have a purpose behind their growth. A passion that fuels their efforts to give it all a meaning.

To put all this into perspective, in the software industry — it is very common to see engineers that have been in the industry for decades who are still trying to find the compass and the standard. A lot of them may have the fire to power their passion towards growth, but often times it can be aimless or purposeless.

You may ask some of them, why do you want to be a better engineer? And you may hear answers such as, promotions, rewards, recognition, and maybe more salary. Nothing solid, just temporary goals and imaginary titles. More money that’ll eventually either be spent or inherited, and bigger titles that will eventually end up with an “ex” before them.

I’ve written before about purposeful engineering — working towards the survival of the humankind and its evolution. A purpose that goes beyond just buying the house and having the kids. Something more fundamental and more impactful. So I will keep the discussion about purposeful engineering outside of the realm of this article.

This article is mostly about understanding one’s development and growth plan, so they know where they stand as an engineer — and what kind of powers they have and what can these powers enable them to do.

With all this confusion and aimlessness going on in our industry, I’ve decided to devise a Standard to measure the progress for software engineers regardless of which domain they contribute to. The Standard Measure shows an engineer their progress and their growth and inspires them to go onwards towards more progress and higher capabilities.

The most important condition I had in mind to devise The Standard Measure — is to ensure every engineer gets an immediate value as they make any form of progress into any direction following their compass.

In the software industry today, you may hear titles such as Jr. Engineer, and Engineer II and maybe Senior, Principle amongst so many other titles. These titles can be earned in so many ways, and there’s no true measure behind how one can obtain one title or another. I have been in this industry long enough to see an intern that has much more impact, leadership, and knowledge than a Sr. Engineer. And I’ve also seen the opposite.

I’ve come to realize that titles are meaningless in an industry that doesn’t respect tradition and pays more attention to innovation. In our industry, someone who spent 20- or 30-years writing software may not be worth what their title says they are worth from an immediate impact and value perspective.

So, titles need to be flexible, and adjustable, and it shouldn’t be bound by how long someone spent doing something as time varies between one engineer and another, and it shouldn’t be bound by a particular technology, especially if the technology isn’t what’s being used in the current projects being developed and engineered.

Making titles a constant that can’t be adjusted up and down based on the context is the cause of so many situations where a non-qualified “Senior” or “Principal” engineer is taking the lead on a project with a technology and a pattern he never used. Which makes it a burden on the “Juniors” on the team to educate their lead and help them not to make the worst decisions.

It becomes even more problematic, when the “Senior” of the team is too proud to learn from the “Juniors” — it creates an environment of exceedingly toxic interactions, and eventually it causes projects to tank and engineers to quit or transfer to other teams.

Titles shouldn’t be constants. They shall be contextual and limited to express the level of experience one has in a particular field, pattern or technology which are all time limited. An outdated technology expires all titles attached to it.

And titles should also be indicative of the person who could actually bring about a value and inspire change and provide guidance. Titles should not be for those who stayed long enough to earn it. That is a call for no-growth mentality and its side effects of “resting and vesting” behaviors. It will inspire only those who would work just hard enough so they won’t get fired and sticking around long enough will give them that leadership level position.

All of the above sounds good in theory. But what is it truly like to standardize the measurements of growth? What is it truly like to have a true development plan to measure progress and earn contextual titles? Let’s talk about this in detail.

For years now, I have been developing what I call The Standard. Which is an engineering guideline that covers all different aspects of software development processes. Starting from the single line of code an engineer has to type in, all the way up to requirement gathers and business development.

And for that Standard, patterns started to emerge driving data-driven decisions on performances and improvements for each and every engineer in any team that follows that Standard.

For instance, if we determine that any software, regardless of what the type of software or what industry it is, it requires dependencies, processing, and exposers components. And if that is the case then we may have a clear picture of what the most minimal task could be in any software development process.

The unit of work, the equivalent of carbon in the structure of our universe, is what will allow us to have a better picture of where someone is in their engineering growth process. Because that unit of work is what can help us build different blocks and measure our growth and development.

So, based on the tri-nature of everything theory — if building a simple system that requires an exposer such as an API controller, and a processing component to perform the logic of that system, and a dependency to retrieve or store required data then we may have what it takes to build a plan for growth.

Let’s materialize this a bit further.

If we are building a simple API for a schooling system that retrieve all students in some storage. We may need to build a dependency, processing, and exposure components to complete the development of this requirement. Let’s talk about where people stand in terms of their ability to complete or develop these components.

Coders

A person who knows how to build less than all of any of these components would be a “Coder” — as in someone who knows how to build bits and pieces of an entire flow, but they can’t or don’t have the experience to build the rest of the flow on their own.

Coders are individuals who know how to read and write code. But they can’t visualize or build all the pieces required to deliver a functional requirement. Think of it as someone who knows how to build an API endpoint but doesn’t know how to secure it. Or provision the infrastructure needed to put it out there in some development/production environment.

Let’s say we are in a .NET shop, where everything is written within the .NET ecosystem. A person with 20 years of experience in the engineering industry but didn’t build any components within that ecosystem or within the same pattern is considered a Coder. Someone who is still learning how to work with the platform and build different components within that platform.

This doesn’t just put things into perspective and makes it fair for those who have been involved in the system from the beginning. But it also takes the pressure off of someone who have been given a larger title where they will be expected to lead and answer questions. Processes tend to work much better when there’s clarity on responsibilities and roles that are driven by data points and true impact/value.

In reality, a Coder is someone who can build any of the basic components that fulfil a requirement. In an API development that retrieves a list of students for instance, A Coder may be able to build a Storage Broker to contact storage, or a Foundation service that can retrieve and validate data or a Controller to expose an API endpoint.

But a Coder doesn’t know how to do them all yet. They can do bits and pieces but not the whole end-to-end requirement. That’s what makes them a Coder. They are still at the code level where components are being constructed.

Programmers

But if we figured out the building blocks of every software development process, then we may categorize on top of that the kind of super-blocks that we can engineer on top of these smaller blocks.

If building a dependency, processing and exposure components makes someone qualified to own an entire requirement, then we may as well give them a title that matches that level of skillset. Let’s call them Programmers.

A Programmer is a Coder that can stitch multiple components together to fulfil a requirement. A Programmer is someone who can code, provision, and deploy a piece of software to fulfil a particular requirement.

You can’t be a Programmer if you aren’t actively a Coder. Being able to write code and actively building components is the foundation of every other contextual title we are going to talk about in this article.

Programmers that completed all the tasks required to fulfil a similar requirement should be able to drive anything that matches the same pattern. Which means someone could be at a Programmer level when it comes to retrieving all entities from storage as an API. But they are still at a Coder level when it comes to persisting these entities, updating, or deleting them.

As it may have become more obvious now, the titles and levels are relative and very tightly bound by someone experience which may vary from one technology to another. And from one architectural pattern to another. This way, titles are a true representation of a person’s current status of growth — not a state in which they stay in for a while.

Developers

Now, let’s take this a bit further.

Multiple technical requirements or user stories may constitute a feature. A Feature is more than just a requirement. It drives business values. Visible, living, breathing value that can be quantified in common measurements like ROIs, customer satisfaction or any other measurement.

Features are something someone who has not been involved in the development process can observe and utilize.

Programmers who have completed multiple requirements to fulfil a feature are at the Developer level now. A Developer is someone who can drive an observable, quantifiable and measurable business value through software. They can build end-to-end features from the beginning till the end of which it matches their expertise and capabilities.

For instance, someone who was able to build an API and experience that end-users are able to use are considered developers. They are the feature crew — the leaders and mentors for programmers and coders.

Developers, however, don’t see where a feature fits in within a larger platform or an enterprise solution. They may develop an experience that helps an end-user see all records of students in a school. But they may not be able to see where that fits in within other features to drive a particular value. That’s where Engineering comes into play.

Let’s talk about that.

Engineers

Engineers are the drivers of end-to-end solutions. They gather requirements, drive design discussions, architect solutions and implement functionality. Engineers are the ones who see the entire picture end-to-end. They are the ones pushing back with clients on driving better features and better experiences.

Engineers go through the entire process of software engineering. They will create components. Fulfill requirements. Develop features and drive scenarios for end-to-end solutions.

So, an engineer is the guy you want to talk to when it comes to building a schooling system. Including all possible scenarios, features, requirements, and components. From design, to development to deployment.

Engineers are coders, programmers, developers and architects. They are the moving force within any software team. A team without engineers is like a car without an engine. You may have all the components in place, but without an engine you won’t go anywhere.

It’s a mandatory requirement for an engineer to know how to turn a raw requirement into design. And how to drive the design into features and how to turn these features into requirements and code.

But while Engineers are the moving force within any software team. They may not be able to ignite a project. People come to ask engineers to design solutions they have already thought about it’s idea and purpose. Engineers don’t have much say in that. They are told to build a schooling system and that’s exactly what they would do.

But there’s another category of engineers who actually ignite projects an drive change in the world. These are what I call Entrepreneurial Innovative Engineers. Let’s talk about those for a bit.

Entrepreneurial Innovative Engineers (EIE)

Every popular startup you can think of in our world today has started with an Entrepreneurial Engineer. Microsoft with Bill Gates, Apple with Steve Jobs, Google, Facebook, SpaceX and so many others. They all started with people that went through the entire process from coding to requirements to features all the way up to solutions. And then they have realized that they can now go into the ideation realm where they can turn anything they could think of into code.

This advanced breed of Engineers are the ones changing our world today. Always have been. We use their software everyday to perform every task you can think of. Reaching out to our families, running our businesses, and maybe just watching a movie or having some fun with video games. They were all started by these advanced Engineers.

And those Engineers are our assurance of a better future. They are the ones pushing the envelop further. They are the ones engaged into solving our most complex problems. They are our gatekeepers from a dark future where air would be hard to breath. They are the ones who want to make humanity an interplanetary species. They are our hope for a better tomorrow. Without those innovative free thinkers of engineers there would be no tomorrow for any of us.

My Standard Measure is an attempt to put all of this into perspective. Draw a roadmap to produce more and more of these innovative engineers. Creating a pathway for those who have the fire to walk the path but carry no compass or standard to guide them through that long, hard and daunting road.

Each one of us is a coder in one place and an engineer in another. These names and titles vary and are very relative based on the context as they should be. Our very systems that we have today to reward based on titles and years of experience rather than value require a serious revision within these guidelines and that shall be one of my missions in our industry today.

My attempts to Standardize our engineering industry and bring some sense to the cyber chaos of which we live in today is my very purpose with these articles, and hopefully someday they become fruitful.