Surviving as a Junior software developer

If it helps, you are never ready, you will never know enough, and the key is knowing how to cope with that.

At the beginning you may have no idea or a vague sense how to solve the problem, you will look at the feature and Google it. You will write code and may even get it working and over time, hours or days it may get ripped apart and rebuilt. Sometimes you will part of the conversation, other times you will come back to find its all changed.

In my first months/projects/jobs I had some amazing moments as I solved problems and got the feature marked off the list, or I discovered that little thing that was stopping it work.  I also has some tough moments, where my code was changed without any comment, or ripped apart in front of me, sometimes without comment or another time with the senior developer responding to my questions with condescending responses.

You will need to separate your self worth i.e. ego from your code. You will need to manage that nagging sense you are not good enough.

Coding is hard, you need to know so many things, that are constantly changing and if you are full stack that could be CSS/SASS/COMPASS, HTML, Javascript/JQuery/CoffeeScript, Rails, Ruby, SQL, GIT, BASH and that is before we talk about APIs and deployment!

Here are some of thoughts and learnings I gained from my first couple roles as a junior software developer:

When you ‘Copy and Paste’ code, understand it

Google has become our SDK, for a lot of developers. You will search the feature and see who has done it already.  Smart, why redesign the wheel! While this may get you pushing code faster, you are starting to create a gap between your actual understanding and perceived ability. This starts to set expectations with your employer and team, at some point this will crash down on you like a house of cards. So by all means find that code through Google, but take the time to understand it, know what each of the commands/methods does, understand the flow make sure naming of variables and methods makes sense in your context. Most smart leaders understand that it takes time to grow as coder, use that time to build a strong foundation not a house of cards.

Debugging – Read the error message!

The most frustrating thing for your colleagues is when you ask a question and your testing suite or your log  is already telling you everything you need to know.  Have you read the errors and if not understood them have you googled it? Yes actually copy the entire error message and paste it in the search bar and press return. Sometimes you will have to cut it down. Do you know where the logs are?  No, hunt them down. It is also true that some error messages really are not helpful, infact they appear to lie, just look through the stack trace..  I record the really abstract ones, in my computer notebook with the solutions. If I were you write (yes with pen and paper – you are more likely to remember then) down each of the errors that you come across at the beginning, they may identify a weak point in your knowledge, or slowly help you remember not to make the same mistake.

Most of your errors in the beginning will be spelling mistakes, typos and things out of order 🙂

1. Read the error message and understand it
2. Understand the failing test
3. Check the Logs, stack trace
4. Check your spelling!
5. If you have a lot of code on one line, break it out into several lines
6. Read out loud
7. Explain the problem to a stuffed toy or duck
8. Google it
9. Take a moment away from the code
10. Before asking others, separate your ego from the code

Code Reviews & Pull Requests

If these are not happening, ask for them, if they are denied look for the next job.  They are the fastest way to grow as a developer, whether you be a junior, intermediate or senior you will learn a lot by others reviewing you code. And you will learn a lot from watching others get and give feedback. Yes some people are dicks when giving feedback, maybe you should give them feedback on their feedback (you might even help out their friends and lovers! being able to give feedback is crucial for all human relationships). Innovation and learning comes out of exposing your code and being vulnerable to feedback.

The best Pull Request comments, point out the issue and then explain why it is wrong (you may need to train your seniors to put the why, telling the why, is difference between being treated as a child or an adult). Do not become a parrot and copy and paste, understand why it is wrong, you will learn and grow faster.  I also have the habit of reviewing my pull requests on a weekly/bi-weekly basis to see what errors, if any, I am repeating, to target in my next afterwork homework.

Code reviews when someone senior or intermediate reviews a bunch of your code are incredibly helpful, in seeing what you are good at and what you need to improve.  If you are alone build up a peer group, who can review each others code. Either way you should consider reflecting on your own code every month or so, at the beginning of your journey you learn so much so fast, that you maybe able to refactor your own code.

The next extension for this, is to put your code open source and then allow the world to help you improve your code..

Pair Programming

There is even a better way to learn, yes pair coding it is like having a sports coach who is giving you constant feedback, and you get better.  This is awesome from a learning perspective. Not only will you learn about the code but you will see how your colleague use their tools as well, which will may give you some productivity tips (or vice versa).  Also you are likely to cut problem solving down by 50% in terms of time. This is not just a technique for juniors of course (its great for on boarding and teaching your organization code style).  All of that said this scared the hell out of me when I started, I thought I can not remember all the syntax and options.. Until I saw that most seniors/intermediates would without a thought Google the function or command to see what their options are. I learnt that is not important to remember everything, but to remember that you can.. Now I am less scared.

Build out your augmented memory

Whilst watching most seniors, they would often lookup old projects to see how they had done something in the past. Whether it would be a Google Drive, Drop Box or even GitHub they would keep most of their old work.  Another trick I saw was the use of notes for each task or type of task e.g. on Mac they would have a Note (or Evernote) on RSpec and have all the matchers and examples, or all of the startup scripts for spinning up a new node, etc. The point to be clear is you will not remember everything, so have it somewhere useful for you, in fact your memory just becomes the index of what is possible and where you did it last.

Also for the tasks that you need for setting up your computer, the environment and creation of an App, I store all of these on Github, to help me not forget a step, and also to keep my personalized setup (colours, BASH paths etc) somewhere, here is mine. You never know when you computer will die, or need to be erased, or you just get laid off!

Separating self worth from your code

Receiving feedback from colleagues can be tough. Some think code is very rational, logical and lacking of emotion.  Thus the feedback can be equally logic.  And some developers can be very cold how they deliver it, maybe they just have not developed the communication skills or patience to be a good teacher/coach/leader.  I even had a couple experiences when “seniors” ganged up to give me feedback, and frankly it was pretty painful to receive.  When I asked why and tried to understand I got cut off and then “shussed”.  I walked away from the situation and then learned not to ask a question to a couple developers at the same time. That said if someone is a dick to you, you do not have to return it. Be the adult, because today they could not be.. I have also had some awesome experiences when my colleagues talked through issues with my pull request, explained the why and what good practice options there are. You want as much feedback as you can get.

So you will need to toughen up a bit, process and work through their comments, and when you do not understand either research it, until you do, or ask. I have to say asking another human is generally faster..

Asking when you need help

There is a balance between asking too few questions and too many.  On one hand you may take too long to solve a problem and build that feature –  on the other hand you may well “piss off” (make grumpy) those senior to you.  This is tough, my general rule is to ask if you cannot figure it out after 40 minutes.

In my first job I think I did not asked enough, I know I would have grown faster if I had.  That said when you are interrupting someone who is in the zone, it feels, well, difficult. Also when they are in zone they often look grumpy, constipated or are frowning and generally look unapproachable.  You will learn the clues on their face over time on when to ask.  Of course my personal view is when my colleagues ask me for help, I will always help.  I have this crazy notion that collaboration is fun, yes even face to face! In the end I find it easier to work in a place where I like the people and they like me.

Growing your knowledge base

Sorry but you are going to have to do homework! Most non-developers have no clue how much you have to learn and then how fast it is outdated.  My solution for this was to do between two and three hours every night, then maybe a longer stretch on one weekend day.  But there is always one day completely off.  When you are hungry its hard to forget that you are actually running a marathon and not a sprint.

As with all learning, you will have strengths in some learning styles.  As a developer you will have to pimp all the styles.  I try to mix and improve all my styles. Really understand what learning style best works for you.  Do you prefer to build and hack together, do you prefer to read/process, do you enjoy watching videos, do you prefer to learn with others.  What makes that new thing stick in your head? Understand this as you have a LOT to learn and process.  A good book on this topic is Make It Stick

My personal choices include:

Books

You can find my books and ratings on my goodreads profile.  So far I find the ones actually published are superior, there are a lot of just e-books out there and I found have found their quality a lot lower. That said the just e-books tend to talk about the cutting edge technologies.

Videos

There are so many approaches that you should try a couple companies to see what works for you.  I started out with Lynda.com, then moved onto PeepCode and CodeSchool – who are both owned by Plurasight now.  Whilst I found that some videos helped with my understand, I did not remember them as well as book reading, which I retained for longer.

People

I have a couple people who I learnt with, we would meet every week and talk about a piece of code.  Like a book club.

This is a marathon not a sprint

That thing called work life balance at the beginning of your career is frankly bollox (bullshit for non brits).  That said you should make time to rest and not think about code.  Reflection will allow you to actually learn the big stuff or that thing you could not connect at first, to spring understanding on you (Bong).  The unconscious mind is a very powerful learning machine, it needs sleep/dreaming, a different context and maybe something creative, like music, painting to be fully powered up.  Yes and exercise, dammit, it also helps. And if you are NOT single, consider those that will love you a lot longer then your job or career even, yes that includes you dog (or cat), plan that time. And if you are single, you are more likely to die or suffer a nasty disease, so make time to meet someone and live longer..

Watching other developers code

If you watch someone who has many years, you will not only learn their style in coding, how they write, refactor, and maybe even test. You will also learn how they use their tools and this can just make you a lot faster. Peepcode (Now Pluralsight)  did some fun play by play videos that allows you to see some of the experts code. Or go a meetup or a conference and find people who let you watch or pair.

Reflection – Knowing your code and improving it

Every week I look back at my some of my code and research similar problems to see if I could refactor it.  I sometimes look for web applications that solved the same problem and see how they approached the same problem and I consider the why, benefits and drawbacks.  I go through my refactor book and look at my code and question it.  I find the creation process can be different to an editing process, it sometimes seems a lot easier.

Working on one thing at a time

I found early on I would try to solve the whole feature in one go rather then breaking the problem down into is component parts.  Now I divide the feature into a number of tasks and complete the tasks one by one (I even add them to Pivot Tracker or add a checked in github or write them down on a pad of paper!).  This allows my brain to be wholly focused on the problem at hand, rather then holding the whole code in my brain. I find I chew through tasks faster, consider out of the box solutions more often as I have that spare RAM to consider them.  I also find if I draw it out, I consider the connections and external parts to a greater level.

Commit often

For every feature I now create a branch. After each task is done I push, well sometimes pull push depending on the time scale. First you will get mini morale boost, secondly you have a backup, third others can see what you are working on. AND fourth, if you need to rollback it is better to do it if you have many hooks to choose from.

Asking Why?

Children do it far more and they learn faster.. And if that other person cannot explain, go and work where they really understand and love to explain.. The best teams I have worked on love to give advice and explain their perspective, but will also be able to defend their view, and then change when new evidence presents its self..

Relationships are important

There is a direct connection to strength of your relationships and the opportunities that will come your way. Invest in the people around you. Do the right thing by people, even when it all goes wrong.  Those people are far much more likely to recommend you for your next job. Be kind.

Features and front end

Completing a feature will gain you kudos, and adding something that clearly effects the customer experience will gain you support from those that support customers and help the sales team.  Having allies in all camps will help you be more resilient (keep your job) in a downsizing and will likely help with endorsements and recommendations. CEOs tend to protect developers who produce more the observable changes i.e. new button, skin, more responsive, etc.  Where as the CTO will tend to protect those who write good code and write good tests.

Have Plan B, C and maybe a D

You are the bottom of the pile, when layoffs come, you are the first in line.  Protect yourself have a Plan B as this is very likely if you are working at a real startup.  Go to meet-ups, get to know your local community, make connections with developers, so if you do get laid off, you have people you can reach out to, so you can find your next opportunity.  Having an active blog of what you are learning helps you reflect (so learn better) and you will build a following over time.  Also work on some projects that you can put out there, so they are public on GitHub, if you feel comfortable to work on open source do.

Should I be a developer?

You may ask yourself this sometimes. I certainly asked myself this at times, when you may watch others craft so easily. This is often referred to as the impostor complex, check out this railsconf talk. Then I find myself, looking for an expression for fun, I find myself impatient at not knowing, well everything, I dream about exploring other code.  Over time I found myself reading the source code rather then a blog piece explaining it, I started to understand more and more code, I find that I want to go back and refactor that hash search removing the [:id] and put in a fetch(), because it fails loudly. I spend breakfasts with other developers exploring what we know, what we have forgotten.. oh it appears I have the bug, no not the bad one but the one you are bitten by… I notice it has being several days since I got stuck and had to ask for help and instead I am asking for opinions.  Do I know everything no, can I find a solution, yes 🙂

If you are not from a Computer Science Background

You may lack in understanding of Algorithms, Data structures and do not have one computer language down i.e. Ruby, Python, Java, or a C variant, yet.

The reality is that Employers feel more comfortable with someone that has stuck with a Computer Science Degree for three years.  That said if you can describe your journey of why you are passionate about computers this may help.

The other aspect that matters is what are considered the basics.

1. Data Modelling
2. SQL
3. Problem Solving
4. The ability to code a non scripting language i.e. Ruby, Python, C++, Java, etc

Algorithms

Some employers like to think that you understand Algorithms, but the reality for many coders is that you will never use this skill set.  The places this really matters is at scale so a job at Amazon it would matter.  This is the best learning resource I have found on them Grokking Algorithms by Manning publishers. This is also a really good video to get you started – “The Secret Rules of Modern Living Algorithms” – Documentary.

Growth Plan

You may want to create a growth plan for yourself to introduce these.  Over a year work out the things you want to be good at, there are some good free course on https://www.coursera.org. It really depends on how deep into the stack you need/want to go.  If you are out of a Bootcamp, consider building your understanding in the primary language (e.g. Ruby, Python) and data structures first. Consider than basic Algorithms, just the basic concepts, not the math and then play with a functional language.  Learning a function language will force to think in a very different way, but do this after you are comfortable with a primary language.

Side Projects

Every senior who I have spoken to says that they learned an incredible amount from creating something they were curious about, maybe on a new framework or connecting to an API. Some would just explore how one GEM/package/library worked.  This can also be helpful for building out your GitHub profile.  That said when you are doing some much other homework this can be hard.

Choosing the right company

Medium/large company There are some who think that a junior is better off, going to a medium/large company.  This approach essentially states that these companies will have the processes to mentor/coach, a bigger team to take on juniors.  That said juniors have told me that there options are often limited to be first a “customer success”, or QA, or part of a front-end team and they have to work for a couple years before being promoted to a full stack team.  You will be able learn over a period of time but may be limited to less important tasks.

Agency/Code Shop Another approach would be to work for a company that will give you access to many codebases ( like an agency or a code shop), thus you will learn very different things, different styles of coding and architecture choices.  This may lead to building lots of Apps but only to a MVP level.

Startup Another approach would be to work for a Startup and then you will get see all the code, and be responsible the whole stack.  Thus you end up be responsible for setting up the deploying to AWS which you may not in larger companies who may have a Dev Ops person.  You will have to learn a lot more and faster.  It is also likely you will make mistakes through your journey. This journey would likely teach about one codebase to a deeper level then the Agency approach.

Do you have any tips?

I would suggest you blogging your own journey, it will help you remember what it was like to be a junior and when you take juniors on yourself you can help them with your blog post and also remember not to be a dick 😉