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 lttle thing that was stopping it working. 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.
Here are some of thoughts and learnings I gained from my first couple roles as a junior software developer:
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. Do you know where all 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.
Code Reviews & Pull Requests
If these are not happening, ask for them, if they are denied look for the next job. They are 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..
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. 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.
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 ask 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!
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.
Personally I like a mix, I use books (yes they are made of paper), videos (they are so many approaches that you should try a couple companies to see what works for you), and I have a couple people who I learn with.
A good book on this topic is Make It Stick
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 did some fun play by play videos that allows you to see some of the experts code.
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 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.
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.
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..
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.
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. https://speakerdeck.com/nmeans/you-are-not-an-impostor. 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. 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 e.g. Erlang or Haskell. Learning a function language will force to think in a very different way, but do this after you are comfortable with a primary language.
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 ;-)