A line of code written by a junior engineer is just as effective as a line of code written by the most senior engineer out there.

To the compiler, it either runs or not. Regardless of who typed it in, who designed it and who hit the “run” button.

One of the biggest challenges an observer might see in the software industry is that the industry did not quite fit in the conventional way of industrializing a profession.

It’s very common amongst software engineers that delivering a feature or fixing an issue doesn’t quite fit the regular 8 – 5 work hours or even the environment where an engineer works – sometimes stepping out of your desk for a walk for an hour is a part of solving the problem you are working on.

That is because a software engineer is an artist, thinker, philosopher, and a negotiator all at the same time.

A software engineer is required to visualize solutions almost all the time, user interfaces, patterns, high- and low-level architectures and even the symmetry of the code written all at the same time.

A software engineer is also a thinker for a living. Solving problems day in and day out is a fundamental part of this craft, and it comes in all different shapes and sizes – managing memory resources, optimizations, or simply making something logical and easier to maintain and understand – problems are everywhere, and so are their solutions.

Being able to effectively negotiate and communicate ideas to both very highly technical people like the engineers on your team, then switching gears to explain the problem to a usually non-technical folk on the business and management side to get your point across. It requires a tremendous effort of being able to speak about the same thing in two sometimes three different languages to get everyone on the same page.

But luckily, these skills are not really bound by a person’s title or how long they have been in this industry – I have seen some of the most beautiful software written by folks who would be ranked as “juniors” or “entry levels” in the ways the industry ranks an engineer today.

The biggest proof is that the most popular software we use today was all started by engineers who had no experience at all, they built it in their garages and their dorm rooms like Google, Facebook, Microsoft and so many others – it was mostly built by engineers in their early 20s the ones we would call today “interns”.

And the skills that I mentioned earlier are also not bounded by how long someone has been in the industry either, in fact the newer a person is to the industry the more likely they are to bring a new perspective that would redefine the standards and pave the way for a whole new way of how we look at our problems and how we solve them.

Compilers continue to remind us of this universal truth about our industry – compilers don’t ask the person hitting the “run” button how long they have been in the industry or what rank they are in the place you they work, compilers look only at the code written and decides whether it works or not, fast or not feasible or not – and that’s all, and that’s it.

I believe that any measurement of someone’s pay grade, rank or level of appreciation based on their seniority, experiences or whatever they have written in their resume shall be a completely fallacious if not fully influenced by what they actually can and cannot do – which can only be decided by one thing – the compiler!

Some software companies have come to that realization, so they started properly interviewing software engineers by doing katas or fully days of pairing with the person, to get a full grasp of how they solve problems, deliver features, how fast they adapt and how fast can they think on their feet and deliver value.

Every other measure shall be just a nice-to-know or a nice-to-have but nothing that should have any impact whatsoever on the final decision of whether someone shall be hired or whether they qualify for a particular title.

When we hear the term Ageism we think about older individuals being treated unfairly due to their old age. But ageism could also manifest and show it’s ugly face when a junior 20-something year old engineer is being paid less despite the fact that they answered all the questions, solved all the puzzles and did a rain dance on top and yet still get paid less and ranked lower just due to his “experience”.

It’s another way of saying, you are very smart and you know all the answers, but you’re young so you shouldn’t be paid your intelligence worth, you should be paid your age worth – that’s a hidden form of ageism.

Our software industry requires a serious restructuring of how we measure the skill-sets of engineers and how we evaluate an engineer’s work and effort and the true link between what an engineer brings to the table and how they are appreciated and rewarded for it.

An engineer reward or rank should not in any way be influenced by anything other than what they create – therefore what is being created shall have proper measures for evaluation.

This makes the equation so much easier. Because measuring the creative work of an engineer is much easier than trying to measure the engineer himself.

Simple things like, does the code run fast enough? is it clean and easy to read? Is it modulus and pluggable? Does it cover all edge cases?

These measure is what should dictate a person’s rank, rewards or position at any company, these are the measures that will help the industry assign the right talents in the right places, and help us all move forward towards the next phase where we become more focused, more precise and more fair about how we treat each other and how we invest in the growth of each other by learning from the talented amongst us.

As a person who conducts interviews on monthly basis, I highly urge everyone who conducts interviews to focus on the skills and the technologies not how long someone has been in the industry, these measures mean absolutely nothing if not accompanied with actual talent and solid skills not just tales from the past.