What’s the difference between Junior & Senior developers?

Today we’re sitting down with our CTO Matt Gerrior to discuss the differences between Junior and Senior developers. Remember, years of experience is just a number. As Matt explains, Seniors exhibit ownership and take a proactive team view, while Juniors should focus on learning about the product, so they can contribute to it.

We’ll talk about duties / responsibilities, character traits, and answer some common other common questions. Hope you dig it!

1 Total Views 1 Views Today

8 Comments on “What’s the difference between Junior & Senior developers?”

  1. Whats the difference between a Junior & Senior Developer?………………How many stickers you have on your laptop.

  2. And… 0:54 cut! There we have it. Junior is someone who is in the way. Wait till Junior hears about this, a hell will break loose. ๐Ÿ˜‰

  3. But… How do we get those stickers!? Awesome vid btw, really insightful especially just for me getting into my first job as a junior. Thanks you guys!

  4. 0:24 – I don't know how many times I heard this opinion (even I confess, from my own mouth). That's why studying is good: we can realize how much ignorant we are.

    This fallacy we usually hear in college or any course to encourage ourselves to start learning. Well, let me tell you this: it is a lie.
    It's better you to forget this and just keep studying to FOLLOW the bests. You will ALWAYS have someone ahead of you, deal with it and try to keep up.

    This lie sometimes even encourages the feeling that a company might "not be seeing your true value", and that's why you need to forget it. In the worst cases, the Junior would be eager to underestimate and dismiss someone with 20 years of experience while not competent enough to even understand WHY they've done things in that way.
    The eagerness of having an opinion might obfuscates the merit of what you have right in front of you.

    So even facing a code which has been running immutable for 10 years, they will tend to criticize it, instead of learn from it.
    "Why they did that in that way??? lol", without realizing that the specific code maybe was written for Java 3 but it's still running perfectly at the very last version of the SDK without a break. Simply because it was done for computers with less resources, less memory, less connectivity to "patch" it and dial up restrictions. :p
    Most of what holds the whole internet and the whole financial system of the world today up is STILL WRITTEN in Cobol.
    Working for 30.. sometimes 40 years without breaking. Dealing a lot closer to the binary then we do today, but without facing even an "exception". Can you imagine how many "go to's" they have?

    Like, juniors are those who just have started their paths, so they won't know what paths the language pass through to evolve, or even how much turns the project took.
    But one thing is true: "old programmers" did a lot more than you with a lot less to work with… so they tend to "think" in a lower level than you… actually understand what the algorithm of that new method of the language/framework does, how much memory it takes and how much time it takes to perform the task… but also SOME alternativeS.
    It's a game of what it takes vs. what is does. Experienced programmers play this game VERY well.

    For example, with an extension of lodash, you can use the "omit" dependency to reduce an array filtering from 3 lines to just ONE. WOW, that seems nice.. we are talking about 3 times less code, right? A lot less for the future programmer to know, while spreading an awesome initiative of both the programmer and the framework! But, what it takes?
    Well, the _.omit dependency adds 1500 lines (yeah) of code to the project, so you would need to do at least 500 calls of the very same "tweak" to even START to consider it. That's A LOT of filtering!
    So why not just write a prototype function in an "utils" file.. with 5 lines, to do the same that the omit helped you to achieve? It would require a bit more knowledge, but would also perform the very same 500 calls but with 1455 less lines of code than the alternative… consequently running faster with less memory, server and time costs. Adding value WHILE LEARNING.
    In other example, why just don't write your own JDBC connection class without those ~40 methods to connect with ~10 different database brands when you just will need to connect to one of them?
    Sometimes the Big-O doesn't matter, sometimes it IS KEY TO SUCCESS. IT WILL DEPEND OF THE PROJECT.

    When we say "less code means less bugs" NEVER forget that you have THE FRAMEWORK to consider too.

    As much as we dedicate years to programming and maybe a specific language, we see enough code to realize that it's not like "old programmers are lazy and don't wanna change". Well, let's reason… why not think that they've seem A LOT, walked every step of the language you are (just) starting with and pass throw enough with it to realize that every decision has it's impact – and that their successes and failures are WRITTEN in their names.
    So if a code is there, intact for ten years, let's cheat our moths a bit and discover why. That's what the "junior's job" is.

    NOBODY with experience will adopt a dependency that have 1 week, 1 month… or even 5 years…. when having the experience to rewrite EVERY line of code of that specific method, for that specific class, for that specific feature, to that specific module, for that specific integration, build for that specific environment, required for that specific project, which have that specific end, to achieve that specific goal… perfectly.
    That's the difference between who uses a dependency, who forks it and who writes it.

    Oh, so we why not adopt a library which does more and less what we need and hook some workarounds to fit the customers requirements? Ask to your Senior about his experience with it, he probably has a lot of refactoring stories to tell.
    So "the code being rewritten for 20 years in the same way" will not really be written in the same way. Take your time to know why you are NOT seeing their difference: compare the first with the last one. See why it – usually – shrank.
    And KEEP IN MIND, what it will SURELY have better maintainability, performance, scalability, re-use and reliability then ANY code you produce at this stage.
    Someday you will see it CLEARLY, as the Senior ALSO did already.

    THIS is the attitude that experience brings, and also why the senior act immediately to discourage the opinion pointing the obvious: "what they need is to know the product".
    He knows the difference between "adapt the code to the project" and "adapt the project to the code" is: SUCCESS.

    Resuming, what's the difference of the Junior and the Senior?
    Basically, the conscience that "studying" is a recursive process of realizing how much ignorant we are.

    I hope you get more and more interactions, just like I did and I will keep doing.

  5. senior devs have been around the block a few times and knows how to deal with bullshit and tell others their ideas are dumb in ways that won't result in an HR violation.

  6. Computer programs are information machines. You put information in the machine and it process that information to get the new information out.
    So senior is the one who engineers the machine and junior is the mechanic who creates some parts by the request of the senior.
    In other words the junior dev can not create the whole thing alone! Simple as that.
    CTO who can not understand that is a junior CTO ๐Ÿ™‚

Comments are closed.