Senior Developers vs. Junior Developers, What's The Difference?

What does it mean to be a junior developer or a senior? How do juniors progress to become senior developers? The answers may not be where you think. This is not all about detailed technical expertise, there is more to it than that, this is not just about learning how to code or the technical skills of how to become a great programmer.

In this episode Dave Farley author of best selling books "Continuous Delivery" and "Modern Software Engineering" explores the idea of junior vs senior developers and describes the differences, and some of the advantages, of each stage in a developers progress.
-

⭐ PATREON:

-

CHANNEL SPONSORS:

-

👕 T-SHIRTS:

A fan of the T-shirts I wear in my videos? Grab your own, at reduced prices EXCLUSIVE TO CONTINUOUS DELIVERY FOLLOWERS! Get money off the already reasonably priced t-shirts!

🚨 DON'T FORGET TO USE THIS DISCOUNT CODE: ContinuousDelivery

-

BOOKS:

and NOW as an AUDIOBOOK available on iTunes, Amazon and Audible.

📖 "Continuous Delivery Pipelines" by Dave Farley

NOTE: If you click on one of the Amazon Affiliate links and buy the book, Continuous Delivery Ltd. will get a small fee for the recommendation with NO increase in cost to you.

-

🔗 LINKS:

#developer #softwareengineering #programming #software #coding

[curtismelnick]

Loved it. One of my favorite sayings is "Experience is what you get when you don't get the result you were expecting".

[NotMarkKnopfler]

Such a great video. Sharing this with my younger colleagues. I'm extremely fortunate - I'm by far the oldest person among my team - I'm 54, and most of the team I work with are under 27 years old. Some in their early 20s. Nevertheless, I'm impressed every single day by their intelligence, and their tenacity, and have huge respect for all of them. They've accepted me into their young environment I really feel no age difference between us - they are, all of them, the loveliest of people. I'm very fond of them. This video might serve as an excellent illustration of the path from a programmer, to an _engineer_ - which is a topic that always comes up! I keep telling them they are not programmers or coders. They are _engineers_ .

[sanderd]

Communication is also a big quality of senior developers.

Senior devs should be able to detect and raise possible issues before they arise.

[nickbarton]

I'd add that a senior also has domain(s) knowledge and commercial awareness.
After all, we are about providing value to our customers, a senior must understand this and have the knowledge and skills to deliver value.
Maybe I'm describing a consultant engineer (my job title).

[rredington]

27 yrs developer. I always tell the juniors: wear a user's hat. Solid solutions are built with experience, discipline, and respect.

[Willvk]

Great points. The over/under confidence call out is great. It also relates to having a growth vs fixed mindset to be continually learning.

[markusmoeller]

I love the remark on Softwaredevelopment being work of creativity - this aspect is so often overlooked by non-dev people just having the coding thing in mind. And a lot of programmers do not reach that point of meta-understanding or, conceptual understanding because of focusing to much on one framework and/or language/techstack.

That difference in beginner and expert made me laugh but in the end it is true: an expert simply fucked up more (and obviously learned from it) than a beginner.

Great video :)

[theotonchev]

Agreed with everything. Personally, I also quantify these concepts using the stages of growth that a *developer* typically goes through:
1. Programming
2. Algorithms and Data Structures
3. Design
4. Architecture
5. Analysis (beyond Functional and NF requirements -- what the problem _really_ is, how it could develop in the future, etc; this guides the architecture, then the design and so on)
6. Organizing Processes and Teamwork

To me a Senior Developer is at least level 5.
There are levels within the levels, of course, but this simplified scheme is easier to track and has proven to be predictive of the observed future performance (in my experience).

[freeborn]

Extremely good description. But I'd be careful judging these things based on a resume. Me for example, I spent 20 years on the same tech stack. But I was building my own things on the side with all the latest and greatest technologies and practices. And so I was always ready to take on new stuff with an in-depth and breadth of understanding. It was no problem for me to move from a university to a stock exchange, for example. I think having a thorough interview process is far superior then judging based on resume

[lumeronswift]

A lot of the best work in development is done in visual maps - if you can efficiently draw up a full picture of the process and interactions and scopes, you can more easily work with business as well as technical teams as well as project managers. Junior (and I still feel a bit junior myself) devs tend to hear "we need to fix X problem" and then focus on that specifically, rather than taking a holistic view.

[brownhorsesoftware]

This reminds me of the MBA at the bank data center who decided he would write the code to generate a business account summary report himself in APL. It brought the mainframe to its knees and ran for hours. I took pity on the auditor tasked with running the report. It took me 10 minutes to rewrite it in the data retrieval scripting language and submit to operations where it ran in just minutes. The MBA was furious but everyone else couldn't thank me enough.

[CarstenSaager]

Some years back I said when mentoring Juniors, was that programming is more linguistics than math. Our job is to find true representations of human ideas in a machine executable form.
I was then still under the impression of a brilliant engineer who was a trained linguist.
Now I am on the more mathematical interpretation, but it is only the second step, just like we use math to describe things, math in software development describes the linguistics or insights we gained of the problem

[jvf]

What are you saying, the difference between junior and senior, is "ju" and "se"

[ub]

1:30 Diversifying to multiple platforms is generally good advice for the dev. However sometimes you'll get a careerist who decides to re-write the entire code base in the paradigm and platform he is currently learning, in order to bolster his CV, without adding any value to the project. I've seen a dev do this for over 2 years until a technical senior DBA finally called him out on it. He effectively added 0 value for two years until somebody even noticed. This was at a gov lab.

[bobbycrosby]

Multiple tech stacks seems weird. Lots of them are almost identical with extremely nuanced gotchas. People love to tout the numbers of tech they "know" when they're all so similar and/or they've never used it for a significant period of time and/or in a production environment and/or in maintenance mode.

If your goal is 3 actual different tech stacks with actual, full product lifecycle knowledge, I don't realistically see how you accomplish this in less than 10 or so years. A year per stack isn't enough. 3 might be.

[roderickmckinley]

Not even a software developer, but I love this channel. Great insight that applies elsewhere!

[alphaphoenicis]

Absolutely agree that writing code to solve problems is generally not very hard - especially with your typical line-of-business apps. Junior developers are challenged to find a solution to a problem - seniors are challenged by finding a solution that best solves the problem. Seniors also have a healthy dose of cynicism when considering the promises of tools or patterns, and are more aware of the costs of maintenance and refactoring incorrect assumptions. These are hard skills to learn outside of direct experience - and leads to the dangerous newly minted seniors throwing every "best practice" pattern into their next solution.

I have often felt, especially in the last 5-10 years, that many engineers are uncomfortable with the current state of excellent tooling and frameworks - they feel that a simple problem requires the same levels of effort (and lines of code) as a 2000s era solution. Honestly the expressiveness of the tooling has improved to the point where if there is much more code than a plain English description of the solution, then something has gone horribly wrong.

[rustythoughts]

I think being senior also includes being effective at enabling others in the team: one of the benefits of being able to solve problems in many ways is being able to engage with less experienced or able developers on their terms, not requiring them to adapt to you; being able to fill the gaps or smooth the edges of the work of less experienced colleagues approach so that it can succeed on their terms. This drives real collective ownership which is a critical part of long term team success, consistent team output, effective handling of incidents, etc. And it also enables learning, being shown that your ideas are right but can be improved, being shown how your 8/10 can be a 10/10, is more effective for learning than being made to feel your work is a dead end and being pushed to try and deliver in a space of solutions you don't really understand. This also builds trust and confidence so that when you do need to lead people into a different solution space they're much more willing to follow you.

[keithp]

This is the best explanation of the difference, even when I was junior my approach leaned towards senior🤯

[cheetah]

The fundamental difference between a junior, intermediate and senior is responsibility. A junior is invested with no trust. They are given simple tasks that are not in the critical path, and their solutions are reviewed in depth. They often have a mentor. An intermediate has developed the respect and trust required to write code independently based on a story without much oversight. They are given story level responsibility. Senior developers are responsible for the product as a whole, the architecture, the design, delivery and quality assurance. While the whole team is technically responsible, it falls to seniors to enforce standards through mentorship and guidance.