It’s a slippery slope, especially with small agencies giving away titles due to their smaller scale.

Niels Bohr once said that, “An expert is a man who has made all of the possible mistakes that could be made in a very narrow field”. And this sums up seniority in most areas out there.

– The senior developer can solve almost every technical problem with little to no supervision.
– Junior developers, on the other hand, can only solve limited types of problems with a small subset of alternative solutions.

Disclosing a few essential nuggets in my latest video here. 🎥

What’s your take on juniors vs. seniors in your industry?

Highlights

00:00:07 – What is an expert?
00:02:14 – Senior vs Junior developers in practice
00:04:24 – How to define a career in software engineering
00:05:42 – Going through the learning curve
00:07:57 – What is really crucial even for seniors

TRANSCRIPT

What is the actual difference between a junior software developer and a senior software developer?

I get this question frequently from juniors who really want to figure out how to become a senior or how long does it take to become a senior, or what is the actual path to becoming a senior developer. What’s the quickest way to become a senior developer and whatnot. And, to be fully honest, different organizations are just handing titles for whatever reasons especially smaller teams and smaller agencies especially less progressive companies where you can become a senior in just a matter of a year with the right attitude, just kind of standing out from the rest of the audience. This isn’t really the case for larger organizations where they do have a pretty well-predefined company hierarchy but it’s definitely the case in a smaller company.

What is an Expert?

So, Niels Bohr once said that, “An expert is a man who has made all of the possible mistakes that could be made in a very narrow field” – meaning that, experts are really people and I’ve already talked about experts and how flaky this word is so don’t quote me on that. But, seniors and experienced people are the folks who have already gone through all the use cases in a very narrow field. They’ve made all the mistakes. They know what are the implications, what are the problems, what are the best practices and what will happen when you make mistakes.

And, as you can imagine, this means that to become an expert you have to go through the path that leads you to all those mistakes and as tricky as it may sound, it really means that you simply have to fail – fail often, fail a lot, without of course compromising prediction software. But once you go through all that part you can learn from your own mistakes and really figure out what are the best practices and the best ways to make it work.

Ideally, you aren’t going to go through this path before you even start a job by working on pet projects, by reading lots of programming books and going to, reading, listening to podcasts and going to events and just trying to reduce the number of failures when you still need to go to all those different use cases – meaning that, you need to work on a large set of projects within an organization, understand the different issues, and a bunch of other things.

Senior vs Junior Developers in Practice

So, a difference in a practice or how to compare, kind of a junior or a senior, is a senior developer can solve almost every technical problem with little to no supervision and all that all is going to be well documented well tested with inline comments and everything else. So you can easily assign a complex task, a small project to even a mid-sized project to a senior developer and you are going to expect that they will comply with it. They’re going to follow the regulations. If there is a problem, they are going to indicate it early on or commented well, documented and everything else.

Junior developers on the other hand, can only solve limited types of problems with a small subset of alternative solutions – meaning that, if you give them a pattern and if you give them a framework and say, you need to replicate it 10 times, it is definitely doable. If it’s simple, if it doesn’t require too many dependencies – these are usually a junior developer’s job.

When the Devs Approach a Task

So, think about, you give, let’s say, rebuild WordPress or build a blogging tool and you give that to a junior developer on one hand and the senior developer. So, the junior developers are probably to say, if they know what programming language, what framework, they are going to say, “Yeah, I know Java so I’m going to build it with JSF or its print framework or something else. I’m going to make it work and you know is going to use Oracle because that’s what I use and he’s going to have different roles and yada yada.” But then the senior software developers are going to say, “Wait, first, why do we need to do blogging tool? We already have plenty of those. It doesn’t make a lot of sense. To make a decent blogging tool, you have to invest a lot of time, resources, QA. It’s expensive.”

So, they’re going to really look for a rationale if it really makes sense, if it’s proprietary, if it’s limited, they’re going to say, “OK, you know if it handles tons of different unstructured data, we are going to use a noSQL database like MongoDB whatever. Then, we’re going to do a set of simplified layers if it connects to other javascript applications. We may as well be with Node.JS or it’s going to do it with static pages or a bunch of other different things. Right? So, you can definitely kind of wiggle through the choices and figure out what is best for the business.

How to Define a Career in Software Engineering

And with that in mind, really, the career in software engineering is defined by the depth of knowledge and the breadth of experience. So we have the depth of knowledge – you really need to understand a lot about a different field and then you have the breadth of experience in dealing with different types of problems with your knowledge and just to plan your knowledge stack into different sorts of use cases. So, that’s pretty much how it goes in a nutshell.

Junior developers, again, they are usually familiar with lower subset of paradigms, use cases problems and they don’t yet know how to apply new paradigms here. And, most of them, if they have a problem, they’re going to get stuck, or they’re going to ask a senior or they’re going to read something on forums which is not necessarily quite helpful.

Simply, pretty much you have to go through all that experience yourself and just get comfortable understanding what are the pros and cons of different tools, paradigms, design patterns, solutions, strategies, frameworks, and be able to analyze and understand what are the implications of using each and every one of those in different use cases because there is no right tool for every job. There are different tools for a reason. They serve different purposes for different audiences for different types of programs.

How to Determine Seniority

Sometimes, a performance may be an indicator. Traffic could be user base, could be a bunch of other things or security, adaptiveness, number of people available in the organization who can build something other available tools online. What are the pros, what are the cons, what are the business implications of a specific case? And senior developers seem to have lots of experience to be able to comfortably make those assumptions and make actual strategic consulting in order to, again, make the right decision at the end of the day. So, that’s more or less, the difference between junior and senior developers.

One other note that I’d like to make is that sometimes, senior developers in an organization could be less experienced programmers who have spent plenty of time within the organization because seniority in software engineering for the most part, in most companies, isn’t related to the programmings skills you’ve got – programming knowledge, clean code, faster execution refactoring, fewer regressions, no technical debt and things like this.

Going Through the Learning Curve

But, in some organizations, there is the learning curve when you develop. Or,  meaning that, if the learning curve is really steep, then new developers or even senior developers may start as mid-levels because they can’t grasp the knowledge of a business and the business implications, the business context, the business structure, the business model, may be very unique to a certain extent, leading to making it hard for a new person to join in and at the same time, or, on the opposing again, you also have less experienced people who may be acclaimed as seniors simply because they may not be as strong on the technical standpoint but they may take the right and make the right decisions depending on context.

They may say, “well I only know, (just as a very rough example), I only know two or three technologies, or two or three frameworks, whatever it is, but I know that in this case, we need to do this because it’s a very complicated case. We’ve already worked with those plants three times over the past five years. We know that they are very specific here. This is going to help us do this. This is going to improve our efficiency here. We already have internal systems that do this and whatnot.”

What Is Really Crucial Even for Seniors

This is also the reason why CTOs are not necessarily the best developers in the company. And quite the opposite actually in plenty of companies, CTOs are probably, kind of mid-level skillset or so technically. Or, at least above average. But, they simply have the ability to represent the entire information technology infrastructure, how it tailors to the clients, what the clients need, business requirements, business expectations, being able to pick the right solution depending on timeframes and budget and resources and other things that senior software engineers also have to understand for the most part. The more they understand them, the more possible for them to step up the ladder even further

So that’s about software engineers. Again, there are different concepts and different ways to represent each one of them and companies may vary. They have different layers and different forms of assessments. But, if you’re a junior engineer who wants to really become more senior, practice makes perfect. And also, understanding business requirements, understanding how important is to produce clean code, learning – continuous learning – is really crucial even for seniors and just becoming better and better with every single complete project.

Beginner software engineers are clueless at work — even with the best mentor on the job. They lack the overview of the bigger picture, corresponding technical layers, operating as a part of a team, utilizing internal tools and a lot more to that.

It may get depressing and troubling, especially in more agile teams and startups.

My key technique is reverse-engineering business and tech requirements.

🎯 Break down the project goals into layers and components.
🎯 Analyze and simplify each one of them.
🎯 Quantify and assign to milestones.

After all, we use reverse-engineering in our lives at any point in time.

📈 School? Investment in a better education or a future.
📈 Career? A step toward a safe workplace unlocking a better lifestyle.
📈 Family? Fulfilling your emotional dreams.

Applying the same principle at work puts your mind to ease and lets you focus on what matters the most in a structured and analytical manner, as an engineer would do.

But that’s just my 2 cents. What’s the technique that worked for you?

Highlights

00:00:20 – The difference between a junior and senior developer
00:01:14 – My no. 1 tip and how developers work with it
00:03:06 – An analogy between engineers and managers
00:04:09 – Here’s the shortcut that I’m suggesting
00:04:21 – Problem 1: Jumping the gun too soon
00:05:18 – Problem 1: Thinking way too much
00:06:10 – Recap: Understanding the bigger picture

TRANSCRIPT

So, here’s my top trick (tip) for junior developers and entry level developers who want to become better at building software applications. I saw a question on Quora that says, “What’s Your Number 1 trick or tip for becoming a better software engineer?” Assuming that this was someone who is entry level, still at university, at their first job or something, and they want to become a better software engineer, which is something admirable, something that I’m really striving to help people with.

The Difference Between a Junior and Senior Developer

So, when trying to answer this question, I was trying to counter question myself with the following. Now, what is the difference between a junior developer and a senior developer and an experienced software engineer out there? So, when thinking about this question, the few answers that came to the top of mind are, experience, the ability to solve complex problems, the ability to predict different types of problems that would come up, experience, context and the ability to see the bigger picture. So, if I tried to take apart some of those, to break them apart into modular pieces, then I have to synthesize that and build them into something more comprehensive and more sane, more or less.

My No. 1 Tip and How Developers Work with It

Now, I would say my number one tip would be building or rather reverse engineering the final platform you’re about to offer. Most people tried to do this. Most junior developers that I’ve worked with, they’re pretty hesitant, they’re fairly chaotic in building software applications because they lack the experience. They don’t know how to start, they don’t know what are the best practices and they simply lack the experience to build a software application.

So, they need to take the more structured route in order to stay sane in the profession because otherwise, they would be fairly clueless, really unaware of what’s the best way to do whatever they’re supposed to do at work. So, in order to do that, they need a level of organization, they need the ability to create some form of a framework which they should follow onwards. So that’s kind of one of the best tips that juniors should follow.

Reverse Engineering as a Project Manager

As an example, rather the best way to do that is through reverse engineering approach which helps people kind of figure out the final solution and then reverse-engineer to the components and kind of elements and modules and everything else they need to build. That’s essentially how project management works too and especially the Waterfall Model. With Waterfall, you have a client they come with a list of requirements, they need a budget, an estimate, and timeframe. So what managers usually do is they try to ask all the right questions, gather all the required context and then speak with the Dev team in order to get the complete features set in order to complete the project. So of course, it only makes sense, that’s a standard scenario, and the developer should follow a similar approach.

An Analogy Between Engineers and Managers

Now it’s also important to make an analogy, to make, kind of, a parallel between junior and senior level engineers and project managers. Why do I say that? Because with the very same scenario with a project that needs to be estimated, a junior project manager won’t be able to ask all the right questions and that’s completely okay. So, there would be some mistakes here and there. You know you would fail once, twice, three times but every single time you’re going to get better.

You’re going to learn to understand the context. You’re going to learn to build a scenario to build the kind of the least of all used cases that you need to consider and ask your client in order to assess what they actually need. So, what is the most optimal way to build so that they have all the features but at the same time, you know, you don’t budget them with something completely insane given the fact that they want to use 90 percent of the features that you’ve planned to build.

So again, that’s the same parallel between juniors and seniors both in the software engineering field and the project management field too.

Here’s the Shortcut That I’m Suggesting

But the bottom line, the kind of the shortcut that I’m suggesting is just thinking about the reverse engineering of an application. I’ve seen and I’ve been preaching that for a while and I have some people who do one of two things and still fail.

Problem 1 and 2 When Reverse Engineering

Number one is trying to imagine the complete scenario, the complete list of features but jumping the gun too soon and trying to solve those problems without really any sort of sequencing, any type of a project plan. What I’m saying is, you know, someone says I want to clone Facebook, and I say okay, well Facebook has posts, groups, and users. So, let’s just start to build with some users and try to interact with them then let us build some simple dumb posts, then try to work in some groups and take it from there.

So, this is lack of organization like we said a bit earlier, the lack of structure, the lack of organization isn’t really helping beginner developers to take their life into their own hands and build something meaningful and reasonable without having to rebuild that. That’s kind of problem number one.

Problem number two is taking a separate approach like trying to think way too much of what a product needs from the start to the end and not the other way around. If someone wants me to build Facebook, they say, “well I need to be able to do posts, also I’ll need users, also I need groups and I also need video messages and feeds and this and that, this and that”, it gets pretty messed up. You can’t understand all the used cases as to how does everything relate to one another.

So, it gets a lot more confusing and there are way too many different outcomes while if you have a single outcome of the end, it’s easier to reverse engineer it and just try to extract every single module and then plan it as a separate kind of library, as a separate subproject or framework or whatever it is.

Understanding the Bigger Picture

So again, if there is a single, just one trick I can give software engineers especially beginner ones, it’s trying to understand the context in the bigger picture and reverse engineer it in your own kind of subproject management system or given your own time frames and so on. So again, if someone comes and says “well I want Instagram, working on Instagram (I’m only using familiar applications for a reason)”, so if you do that you need to have an action plan on how to build on Instagram over time.

With that in mind, you need to take Instagram as a final platform and you need to break it apart into the different pieces that Instagram has like just the ability to upload a photo, filters, the feed, users, connections and everything else. Everything else from that specifically, so you need to categorize it, classify it and see how are modules connected to one another, which is exactly the context and what is the best way to make it work. Then when you ask the follow-up questions before proceeding further, it’s very likely that some of those questions would be based on your initial due diligence for what does Instagram represents and what does it look like and how does it work behind the surface.

Assessing the Need for Some Constraints

So, with that in mind, you probably need to assess the need for some constraints and by constraints, I mean if you’re building that software what’s the content base that you need to support. Like how many posts should your initial build support, should these be 500; 5,000; 50,000; 500,000; 5,000,000; 50,000,000 and so on. Because this will determine also the software architecture, server level, hyper availability, different high availability and different types of architectures for building the right toolset.

So, this again will also come into play once you have the bigger picture. So yeah, the very same thing goes regardless of the solution, just get the solution try to reverse engineer it, try to break it down into different phases, trying to build kind of an action plan as to how would you approach that and then once you have that just move forward and start building your minimal viable product.

Most of the time it works really well because you understand the end goal, you understand the bigger picture, it’s easier to assess where are you now and what does the end goal look like. It’s also easier to build upon a solid foundation without having to always keep refactoring and cleaning technical debt and it’s less demotivating if you’re just building stuff for the sake of building without actually having different milestones to hit.

Recap

So yeah that’s pretty much it. Try to understand context, understand business problems at hand because it’s really important, it helps you make the right decisions, understand the bigger picture, reverse engineer it, build it into a kind of different milestones and then, take it from there. This has helped millions of young software engineers. Give it a shot. This may or may not work for you but it’s definitely worth trying.