DEV Community

Cover image for Go from Junior to Senior developer in a couple of hours
Thomas Hansen for AINIRO.IO

Posted on • Updated on • Originally published at aista.com

Go from Junior to Senior developer in a couple of hours

I have 25 years of experience as a professional developer, and 40 years of experience in total. I have been Head of Development, Project Lead, CTO, Project Manager, Senior Architect, and held every possible role you can imagine over the years. Today I am the CEO of a service provider delivering cloud services to hundreds of software development companies all over the world. I’ve coached entire departments, held courses, and taught more times than I can count – And I can teach you the most important thing I know in 5 minutes.

Being a senior software developer is not about what you do or what you know, it’s about what you do not do and what you do not care about. You’ve got it all wrong if you think you need to learn everything. Going from Junior to Senior developer is about what you do not care about.

20 years ago Joel Spolsky wrote an article called Fire and Motion. It’s probably still one of the best articles ever written for software developers. Joel is the founder of StackOverflow in case you didn’t know. The article gives away the dirty secret of our industry, which is that 98% of everything you’ve ever learned is basically garbage knowledge. It’s garbage because those wanting you to learn it has financial incentives to having you spend time learning it.

If the chief evangelist of some massive GraphQL service provider tries to explains to you how I’m wrong and he is right, ask yourself what his incentives are. If the marketing manager from some NoSQL database vendor tries to tell you I’m crazy, ask yourself who pays his salary.

A senior software developer will use the least amount of force required to solve the problem at hand, period. He doesn’t care about NoSQL, Kafka, or GraphQL – He cares only about solving the problem at hand. In fact, most senior software developers I know wouldn’t be able to even configure Kafka or GraphQL at gunpoint. This is why most senior developers aren’t interested in talking about message brokers, Sagas, OOP, or DDD in their lunch breaks; They simply don’t care. Such exercises are for the inexperienced developer. And the more DDD, OOP, OOD and SOLID you can recite by heart, the more likely it is that you’ll never become a true senior software developer.

I have created a shortlist of technologies you need to stay away from. You can start reading my list here. Simply reading through these articles will shorten your path to becoming a senior developer by 50%.

Being a senior software developer is not about what you do or know, it’s about what you do NOT do and what you do NOT care about

The senior developer prefers not even coding at all in the first place. If he or she can use some tool that results in him or her not needing to create code at all, he or she will use it without even thinking about it. In a way you could argue that being a senior is about being lazy. The senior knows that the more code is being produced, the more future work will be required to keep the project running. The more constructs and ideas is added to the project, the more difficult it will be to hand over the project later. The more design patterns scatters the project, the more energy will be required to maintain it.

A senior software developer is lazy, and that’s a GOOD thing!

Shameless plug

At Aista we’ve created a tool for software developers. In a way it’s the equivalent of FoxPro or VB6 for the web. It doesn’t have Kafka support, and the only NoSQL database it technically supports we ripped out of it months ago. It doesn’t allows you to implement long lasting cross micro services transactions using Sagas, and it doesn’t even contain OOP constructs or mechanisms. This is its purpose in fact too. Dead simple software making your life easier and more pleasant, resulting in a happier life, more productive work, and better profits for your employer. Because in the end …

Your employer pays you to solve problems, not because you’ve got a CV covering everything known to man. If you solve his problem faster and less expensive, he’ll promote you to a senior, period!

However, if you spend 3 weeks configuring Kafka or GraphQL, he’ll probably fire you. I would know; Been there done that!

Top comments (14)

Collapse
 
simplegeek profile image
SimpleGeek

This is an interesting perspective. I agree that junior devs sometimes focus on things that senior devs have rightfully learned to ignore. "Boring" tech is boring for a reason - it's an effective way to solve a problem. SQL and jQuery are great examples of tech that gets bashed for being boring, but you can still solve problems very effectively with them. They're reliable and understandable tools.

I'm not sure Joel was necessarily criticizing all the higher levels of abstractions and tools that come out, though - I think he was pointing out that you'll never get anything done if you spend all your time running down every hot, new tech solution that comes out. Just my take, though, and it is an excellent article. :-)

To get back to the main subject, the seniors I've known that I felt truly deserved their title have had superior debugging skills, superior ability to read through, understand, and reason about other people's code, a good sense for what makes maintainable code, a greater technical skill set (knowledge of the language/ecosystem, how to solve its problems) and the ability to teach those skills to others. Wouldn't you say that these skills are really part of being a senior dev too?

Point well made, though. Always follow the money!

Collapse
 
polterguy profile image
Thomas Hansen

I think he was pointing out that you'll never get anything done if you spend all your time running down every hot, new tech solution that comes out

Of course. Some new tech is interesting.

Wouldn't you say that these skills are really part of being a senior dev too?

Yes, and of course I am exaggerating - The point still stands ... ^_^

Collapse
 
cheetah100 profile image
Peter Harrison

The difference between junior and senior is responsibility. A junior isn't responsible for anything. A intermediate is responsible for their own work. A senior is responsible for mentoring, product design, and the whole product. You don't learn it all in a day.

Collapse
 
polterguy profile image
Thomas Hansen

This is of course true, but you never learn it if you keep on chasing all the "latest new tech stuff" ...

Collapse
 
nombrekeff profile image
Keff

Sure buddy, sure!

Collapse
 
nombrekeff profile image
Keff

I think it's not all about speed of delivery. Just because you provide a solution fast it does not mean it's good. I would much rather that you spend a bit more time and deliver a robust system, than delivering a inferior product in half the time.

Even if the delivered system is powerfull and cool I would not make you a senior because of that, that's bullshit!

Collapse
 
polterguy profile image
Thomas Hansen

I think it's not all about speed of delivery

Actually, you're wrong. Speed leads to quality. However, thank you for the comment, you gave me an idea for my next article ^_^

Thread Thread
 
nombrekeff profile image
Keff

Would you mind expanding on why you think that?

Thread Thread
 
polterguy profile image
Thomas Hansen

The experiment with pottery shows that if you create 10 pots in the same time as somebody creates 1 pot, you end up creating better quality at the end of the time frame. Hence, more speed, better quality in the end, and more learning ...

Thread Thread
 
nombrekeff profile image
Keff

This makes no sense to me if i'm completely honest... do you mean that by doing 10x more work you're learning 10x faster, hence becoming 10x better at what you do? That could make sense, but I still think that spending a bit more time on something results in a better product

Thread Thread
 
polterguy profile image
Thomas Hansen • Edited

Check out the ceramics pottery experiment. It's a universal truth. If you can do 10 projects in the same time as your neighbour does 1 project, the quality of what you're delivering will soar, while the quality of your neighbour's product will fall behind. Quantity is a pre-requisite for quality. And I didn't say it made sense, I didn't say it was easily understood, but it's a scientific fact, proven many times over and over again ...

Resulting to a conclusion, which is as follows; Basically, the only difference between Tiger Woods and me is that Tiger has swung a bajillion times, while I've swung some few hundreds of times ...

If you find it difficult to believe in, bring it up with Alpha Zero ... ;)

Thread Thread
 
nombrekeff profile image
Keff

I see. This makes a bit more sense, basically practice makes perfect. I'd change speed for practice, but I kinda get it...

Thread Thread
 
polterguy profile image
Thomas Hansen • Edited

I'd change speed for practice

This is the largest paradox about the pottery experiment. All participants had the same amount of time available - Still those delivering 10 pots outperformed those only delivering 1 pot (in the same amount of time) on neutral quality metrics ...

Basically, their last 2 pots were significantly higher quality than those only delivering one pot ...

And yes, I know it totally doesn't sound logical or reasonable, but it's proven over and over again ...

Collapse
 
decker67 profile image
decker

Clickbate + Advertising