On Being a Junior Developer

Junior developer (for purposes of this post)is a developer with < 2 years experience programming in industry who have an interest in sharpening their technical skills.

I recently graduated from Stanford with a degree in Computer Science. I’ve been programming for 4 years and feel comfortable claiming ~1.5 years industry experience through summer internships, failing as a solo founder, being a lead engineer for a startup, various freelance gigs, and my current position at a mobile health startup I helped found in December. What follows is the list I wish someone had written for me as a developer starting out in the tech industry:

1) Read other people’s code

Perhaps the best way to enhance your technical ability is to directly read other people’s code. Github is a fantastic resource; and it’s even better if you have an all star developer already within your work environment that you can bounce questions off of. Here are two things I think are particularly valuable:

Focus on naming conventions; good programmers define variables with names that enhance the readability of the code and also provide intent, but also don’t couple the variable name to a certain data structure type.

Try to load the whole system into your head and understand it. Notice how the various components are decoupled, design patterns, and also how they have spelled out their unit tests. Holding well designed systems in your head is very much like visualization within athletics. Visualizing yourself in a certain athletic situation or doing a specific technique correctly has been linked to improved performance. Do it for coding too.

2) Plan things out

Before you ever start coding you should sit down with a whiteboard or pen and paper. These drawings don’t have to be complex, but should provide you with a holistic view to how all of the components you are about to code or touch should interact. In addition you should be exploring different design choices at this stage, it’s much easier to erase a whiteboard and start from scratch then be a week into your coding and realize what a mess things have become due to lack of planning.

3) Have an opinion

As a junior developer you should have opinions and you should have reasons as to why you have that opinion. Even asking yourself the question of “why did you make choice X?” as a thought experiment is a nice way to have a robust answer and solution to your problem. The reason you need to have opinions instead of simply following along is because you are literally learning into understanding. Ask yourself the tough questions so that when a senior developer reviews your code you have a legitimately robust solution.

4) Ask questions

In the very early days of my current startup the backend developer wrote an abstract base class for all of our Models in Django, which essentially acts as our very own wrapper on the Django ORM. I was reading over his code and was very curious as to why he had gone through the trouble of doing this.. after all isn’t that what an ORM is designed for? His answer:

“I did that because it makes it easy for us to change the underlying database without having huge migration issues”.

He had been bitten hard by database migration issues before (in particular a postgres to noSQL solution) and was prudent enough to take preventative action.

Ask questions about peculiar things, there is often wisdom and learning to be had.

5) Explore new technologies

One of the more unfortunate trends I see with some of my graduating Stanford CS friends is that they are often afraid to try new technologies. They have a computer science degree, not a ‘programming for industry’ degree and it terrifies them a little bit. All Stanford people have known while growing up is being the top of their class and naturally gifted. When confronted with a situation they aren’t good at they often freeze up for fear of failure. As a junior developer it is in your best interest to fight those instincts and cast your net far and wide. Every piece of technology you touch influences you in some way, and having used various technologies exposes you to new paradigms and ways of doing things. Touching a new technology / programming language is expanding your ‘world view’ of programming.

Note: The classic debate is functional vs OOP; however even something as small as giving Node.js a try can have benefits. After playing around with Node.js I now generally use their two part callback for asynchronous code because I really like that decoupling.

6) Embrace unit testing

One thing I didn’t do enough of at Stanford was unit testing. I had one TA who bugged me to do it (I still didn’t); however the rest of my classes never did. We weren’t graded on unit tests and we got to reset our projects every 10 weeks. University just isn’t built for cultivating a testing culture.

As a junior developer you really do need to embrace unit tests. I will advocate for Test Driven Development (TDD) not only because it improves my confidence that my code is functioning properly but has also really improved my function prototypes as I generally ‘call’ the function before its even built. I’m not particularly fond of BDD; however any form of testing you can do is better than nothing (trust me when it comes for v 1.1 of your app you’ll want those regression tests too).

7) Refactor

One of the problems of being a junior developer is that you haven’t been in industry long enough to be bitten by poorly written code that becomes impossible to maintain. Being a developer isn’t about writing code, it’s about producing working software while simultaneously hitting business goals and maintaining expectations. When you start with a blank slate everything is golden: you get to build from the ground up, features get spun out faster because they don’t interact with other parts of the system as much and the sky is the limit. If you are simply slinging code without any regard to maintainability, after about 6 months you will have accumulated a huge pile of technical debt. New features can’t get put out as fast, it takes longer to know what a certain function does and changing one thing wreaks havoc on another component of the system. Unfortunately the demand for new features from your users doesn’t simply decline with your technical debt; in fact it is likely increasing. This puts developers in a bad spot because they have a tangled pile of code and non technical folks requesting new features at rapid fire pace who have no idea what it means when you say ‘spaghetti code’.

So what happens next? The developers say the old system is slow and everything would magically be better if only we could rewrite the thing from scratch. So new developers are brought on to maintain the old stack and your ‘best’ developers begin creating the system from scratch. Bottom line… this is a huge waste of resources and doesn’t work anyways (it always takes longer to rewrite than you think, the new stack is always trying to catch up with the old stack, lots of QA time, etc).

But here’s the kicker, who wrote the initial version in the first place? Developers. 

I want you to imagine for a second a business development employee approach you and say “Yeah, that old partnership that is supposed to be our flagship deal is slow and I messed up that relationship pretty bad. Don’t worry though, if we go get another partnership while still trying to string the old one along we can be back to full speed!”. That’s unprofessional, and frankly so is unmaintainable code.

The solution to this is preventative medicine. As a developer you should be constantly rewriting and refactoring your code. Don’t ever check in code that isn’t a little better off than before you started. Maintainable code is code that is easily readable, extendable, and testable by outside developers.

Unless you have a very very good reason to put in that ‘quick fix’ don’t ever sacrifice a local maxima of productivity for the long term health of your codebase.

Lean Prototyping & User Testing

I'm Writing A Book!

If you like my content or want to know more about prototyping and user testing check it out!

69 thoughts on “On Being a Junior Developer”

    1. awesome post, lots of fantastic tips. jr here too with ~2.5 yrs in various roles. Just keep in mind that everything gets twisted when there’s lots of pressure and biz interests.

  1. I’ll just say that I think <2 years isn't large enough of a window. Here in the US Midwest, you're really considered junior until you have 5-7 years of experience. I've got 7 and am considered mid-level.

    Then again, there aren't as many fly-by-night startups as there are serious enterprise software companies.

    1. Interesting… are there very defined corporate ladders in the midwest for programmers? It’s probably my lack of experience, but a lot of companies in the Valley don’t necessarily have much beyond ‘beginner’ ‘senior’ and ‘management.

      1. I don’t think time is a good measure of experience at all. I’ve met people with years and years of experience over me.. they’ve been at it almost as long as I’ve been living..still do not have the development skills I have… “experience” doesn’t replace actual knowledge.
        I’ve been developing ~7 years.. employed doing it for 6.. if I were called a Junior Developer I would honestly be insulted.

    2. You could say I am a junior developer since my programming experience at a real job is quite small. However I do not like to value myself to such a worthless system. A person considered a junior dev could be well much better at things than a senior dev is. There is no guarantee for a developer to be better just because he/she have been working for a longer period of time.

      A “junior dev” could be a better programmer, have more knowledge than a senior dev. The only thing you should talk about is the experience in certain systems / languages that the company use. Even if you have 15 years of experience you maybe never used NoSQL before and should be considered a junior for the new NoSQL -project at work.

  2. Unit testing and TDD are lovely ideas but in the real world not that commonly practised. It nice to imagine we all write these modular, coherent, lowly-coupled classes that can be pulled out and tested in isolation – however in the real-world it rarely works out like that. Most testing is usually done towards the end and after the implementation, and most tests are usually written as simple use-cases that test some feature or behaviour against an expected output (i.e. regression testing).

    Wandering into a company and blabbering about TDD is a sure fire way to mark yourself as a “junior developer” that simply hasn’t been exposed to real-life software development, not to mention cause a lot of eye-rolling.

    1. I’m going to have to disagree with this comment. There are plenty of examples of companies that do TDD and plenty that don’t (with successful companies in each camp). From a personal perspective I would rather work in an environment that embraces TDD or some form of unit testing than none at all, even at the risk of labeling myself as ‘junior’.

      My own codebases are often not pure ‘TDD’, and I even write tests after the fact occasionally. It’s not the end of the world, but writing tests of any form is a huge step up from doing nothing.

    2. Have to disagree with this, we expect that junior developers can demonstrate some familiarity with unit testing during our interview processes, and we require developers to back their code with unit tests as part of the development process. QA will require an automated test suite before they start testing manually.

      If people *don’t* write modular, lowly-coupled classes, then their work is rejected by a tech lead.

      your comment makes me a sad coder.

    3. “Wandering into a company and blabbering about TDD is a sure fire way to mark yourself as a “junior developer” that simply hasn’t been exposed to real-life software development, not to mention cause a lot of eye-rolling”

      Depends what sort of company he walks into, if I walked into a company and attempted to raise a discussion (not ‘blather’), about TDD & unit testing and I was met with eye rolls and derisive comments about my experience as a developer, I would promptly leave the company. After all, who would want to work for a company populated with dinosaurs who are afraid to embrace change and accept that there MAY be a better way of doing things?

      Anyway that place sounds to me like some huge Corporation populated by guys doing donkey work maintaining legacy systems, which is maybe a fine place to work for middle aged guys with a family to support, but I’ll stick with my ‘junior’ buddies and work at exciting places where people are enthusiastic about the development process and different ways to do things.

    4. I strongly disagree with this assertion. Perhaps you haven’t been lucky enough to work on a well-tested codebase, or in a genuine test-first culture. But that certainly doesn’t mean they don’t exist!

      Most of the organizations I’ve known who did little or no unit testing always seem to say things like “yeah, we know we should get more tests in place, but we just never have time”. In my experience, the time they “don’t have” is the time they spend tracking down regression bugs.

      I’ve been deeply involved with projects in both types of culture, and I can say with utter confidence that test-first culture does exist, and that it’s calmer, more stable, and people sleep better at night. Oh, and they get more done, too!

    5. I’m going to have to *strongly* disagree with this. Today TDD is a mandatory skill for professional development, let alone unit testing.

  3. On a trivial note, you count “4″ twice.

    I admire your passion and drive. I also find it amusing that you call yourself a junior developer when (at least in all the experience you’ve outline above) you’ve been the most senior dev on all the projects. There’s a lot of learning that comes from working when you’re not the ultimate authority, and cannot pass final judgement on every decision that comes your way.

    1. Edward good points. I have been the most ‘senior’ dev in around 3/4 of my projects to date; however the projects in which I was not the most senior authority is actually where the most learning and growth has happened. In my current startup I have the fantastic opportunity to work with (and essentially under) two devs with 20+ years experience each. Working with them makes me feel responsible to work to the same high standard they seem to naturally spin out.

  4. Very, very good post. I would LOVE to have somebody like you on my team :). Actually I did have some people like you on the team in the past and they are great to work with. As a junior it’s great to have “to much energy”. Just don’t get frustrated by the lessons you learn, but actually learn them. I think your post is spot on in that regard. Maybe some things to add:
    - Know when to quit, when you hit a wall at a company. I think that it is really great for a junior to start at a big company, learn for two years or so, and then do their startup.
    - Don’t play politics, but watch them and learn. You have nothing to loose in the career game yet, so feel free to be outspoken and see what happens.
    - Try to impress. There are few things that are more motivating and satisfying than to get that super grumpy guru senior guy to nod and say “nice”.

  5. Hi ! Thank you for a great read ! I am myself a junior developer and have tried to follow these guidelines, but you remind me about #1 which I might tend to neglect.
    I have one suggestion for improving this post though : just by reading through, I can very well spot ideas from a well known technical book. When I look at the paragraph that starts with “So what happens next? ” or when I read “Don’t ever check in code that isn’t a little better off than before you started”, I think you should give Uncle Bob credit for those parts Or maybe I just witnessed a fantastic coincidence : you having the exact same ideas in approximately the same words as Uncle Bob.

    1. Ian do you have a link to the book you are talking about?

      I can definitely say that these ideas were not taken from a book; however if there is a well known book that touches on the subject I would love to add it to the post in order to give people more reading material!

      1. It’s not the book Ian was talking about but I really recommend The Pragmatic Programmer. It covers a lot what you talked about in your post.

  6. Thanks for the great article Matt. What courses do you think best prepared you for coding in the “real world”? This goes beyond just pure systems/programming classes – were there any classes in particular that you think helped train your mind for the challenges of practical development?

    1. Personally I think the CS core was the most valuable classes I ever took. I was HCI focused so I really enjoyed the user testing aspects of CS147 and CS247; however that’s not really a class to prepare you for development per say (more for product development). If we are being honest, doing random side projects outside of the CS curriculum is what helped me learn and grow the most. There are very few classes that teach the frameworks that most consumer technologies are built upon in the Stanford CS program.

      Anyways shoot me an email if you want to chat more!

  7. I’m a junior developer, although under different circumstances. I have worked in IT for years, and found an interest (read: LOVE) with programming. I worked in an establishment where they had the resources to take me under under a temporary trial position and so far it’s worked out great.

    #4 is interesting, I work in primarily a .NET shop and some people in my group (some not all) outright mock anything that isn’t directly involved with .NET. Coffeescript? Scala? Passing fads, according to some in my group. This kind of thinking seems really stagnant and an unhealthy mindset to have in an industry that is rapidly evolving and improving.

    I have some ways to go, I’ve only been programming professionally for 2.5 years, and I still have so much to learn. Eventually if/when I get promoted from Associate Software Engineer (junior) perhaps if I feel I have enough to contribute I’ll try and come up with some lessons learned.

    Nice post, and I wish more junior developers would be more willing to talk about lessons and challenges they’ve learned.

  8. Pingback: My Homepage
  9. Junior Dev as well and I’d like to add a few things in here, things I wish I had known sooner.

    Companies still want you. While browsing job opening ads it’s really easy to feel like nobody wants you. You need first experiences to get a job but you need a job to get experiences. One thing to keep in mind is that recruiters describe their *ideal* candidate, that doesn’t mean they’re going to find him, that doesn’t mean they won’t consider your application if you don’t fit the description. If you see an ad for 2+ years of experience but believe you have the skills, send an email, it only costs a little bit of your time that’s all !

    Have something to show. I learned as a self-taught and worked as a freelancer, mostly minor tasks in small budget projects. Most of the work I did while freelancing would have given a terrible image of my skills, because I was asked to do stuff that weren’t so great, but being at the end of a chain of command with no way to have my voice heard byt the end client, all I did was mostly pushing pixels in PS or Css. Once I realized how little I had to show I was proud of, I decided to work on my own time on things I could show and say “yep, I did that”. One of them was a proof-of concept for responsive HTML, even though better solutions have been created since, I was really proud to get it working, even prouder to have the smashing mag tweet about it, and obviously concerned about some of the comments I got about it. But in every interview I got, I talked about it a little, it showed I could handle some Javascript, I was concerned about performances and mobile experience, that I could do something autonomously and it’s the kind of things people look for nowadays (especially for a designer/frontend dev).

    Chose your technology based on the market too. It’s really easy to browse to your RSS feed (because you should use RSS keep yourself updated btw) and decide to pick up that new language everybody is talking about. As it turns out, businesses don’t make their technological choices for the same reasons as you do. Learning tools that are widely asked for is going to make finding a job a lot simpler. I like Prototype and scriptaculous but nobody use that, might as well go with jQuery it’s the standard, same goes with Fireworks and Photoshop, Php versus Nodejs. That doesn’t mean one of the solution is actually better than the other, everyone is free to have their opinion about that, but one will be more likely to get you a job. Once you’ve gotten some experience, have proved your skills in the industry feel free to take a look at what’s out there again and pick something else and land another job but first I think it’d much better to pick up what businesses use.

    One of the mistakes I did was learning how to make e-commerce websites with Opencart. I tried many platforms, liked that one best and went with it. Businesses mostly use Magento and well if one wants to work on e-commerce websites, Opencart Theming is a rather useless skill… You can make it a niche but you still have people to compete against and less prospects.

    Don’t be embarrassed. If you’re a self-taught like me, outline the fact that it takes a rigorous lifestyle and personality to learn a job all by yourself, to wake up and work with nobody behind your back to tell you to. It can easily be forgotten but it really matters, don’t feel like a loser for not having some fancy diploma, show how you decided to go your way and managed to succeed.

    Last but not least is to be valuable to businesses. I always thought people paid to have me spend time on their project. Like an asset like renting a server for hosting or someone’s time to take the garbage out. I was wrong. Since I got this new job (around a month ago) I’ve been trying to see how what I do (mostly Html/css coding) could be useful to the company as a business. Sure the fact that pages look good matters, but that’s not all there is to it. I tried to spot areas of improvement, pages that could use some re-design because they kind of suck and the stats say so, forms where users make a lot of mistakes and how they could be improved.

    I took the liberty to do stuff I wasn’t asked to, and tried to see how to improve how our business performs. This has already been noticed, I’ve been told some stuff I’d done (such as custom google analytics reports for 404 and 500 error pages) were really useful because of some log issue, that we’d never would have known page X in our FAQ was visited so much etc etc. Make yourself valuable to the business instead of doing what your title makes you believe you should do !

    Last but not least, be nice, I’m sure you already do that but pay attention to the little sentences like “wow whoever designed that logo is a retard”. You may some day be saying that to the person that did design the logo and will be quite embarrassed. Give your opinions as concerns rather than critiques, provide alternatives and solution. Be whoever you’d like to work with.

    Good luck becoming a senior dev, keep up the hard work :D

  10. Following on from the “Ask Questions” point, the thing that I think helped me the most was actually answering questions on Stack Overflow. If someone comes along with a better answer than you, you will most likely remember that for next time.

    1. Really great point!

      I love answering questions on Stack Overflow, especially if I’m just learning a framework. Makes me dig and really understand components instead of ‘copy and paste’ coding you see a lot of these days.

  11. Awesome post, after reading the post everything felt so relevant to my current scenario as a developer in a small startup.

    Thanks a lot for accumulating all these points in a post like this.

  12. You motivated me to write a top 10 list.

    10 things Junior Developers can do to become better programmers

    1. Read other people’s code
    2. Plan things out
    3. Have an opinion
    4. Ask questions
    5. Explore new technologies
    6. Embrace unit testing
    7. Refactor
    8. Pair program
    9. Contribute to Open Source Software
    10. Go to Hacker School

  13. Great article, I’m a Junior Developer with ~2 years industry experience and I’m finding all of your points very familiar. The only one I’d like to work on more is reading other people’s code, because at the company I work for there are only two developers so far and I am the senior one and the supervisor.

    I think the most important of these points is the need to plan everything out, after all “He who fails to plan, plans to fail”. Also refactoring is always important; I look at some of the old code that I have written and I just facepalm. It’s great to be able to go back and change your old stuff, but sadly you don’t usually get much time to in-between new features and bug fixes.

  14. As a junior dev currently working my first major dev experience at a startup, I think your post is spot on. When I first started this job, I had to hit the ground running. I learned all of those points very quickly and #1 definitely helped me the most.

  15. I enjoyed the article and loved your line “Don’t ever check in code that isn’t a little better off than before you started.” I am going to bring that to my team. It is an easy challenge, but one that can be easily implemented if you are using Test Driven Development.

    I’d like to add one to your list: Teach. As soon as you put in the time to learn something new, teach it to at least one other person. It embeds what you learned in you mind and forces you to ask questions that you would not have asked while you were struggling to learn the new concept.

    Good article and best of luck

  16. Really nice post. I think your comment thread demonstrates the need for a #8: “Don’t forget that development is a social enterprise–work on your people skills.” There is no shortage of (let’s face it) mostly young men in the development world who trade in condescension and who will find any little excuse to nitpick in an attempt to make themselves feel superior. While it might seem okay in the anonymous world of the Internets, being an unsupportive ahole doesn’t make your team or your product any better, and will get you about as far professionally as it will socially.

    1. 100+!

      Great advice – I work in a team of 25+ devs (all male except one) and it is literally a stomping ground of testosterone. It can get tiring.

  17. Interesting topic!

    I’m a junior developer myself, and I’m constantly looking around for new ways to learn. I’m not in the position where I can bounce ideas off of some developer-guru on my current job, so I try to learn by myself (coderetreats, code katas, conferences, blogs, books, open-source projects,…).

    I found this post very interesting, but it left me wanting a bit. I know there isn’t a single path to “software development seniority”, but perhaps a reading list, or a list of things you should definitely master before you can call yourself a well-rounded developer might be interesting.

  18. Great article – it’s very encouraging to see fellow juniors speaking publicly and “coming out” about being juniors. It annoys me when people don’t own up to being junior – be proud! Everyone starts out as a junior, unless you’re Zuck.

    I would add:

    Leave your ego at home. Be prepared to handle embarrassment, make mistakes, and openly encourage your peers. People will recognise you as a team player and will respect your humility which isn’t in abundance in a male-dominated industry.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>