My very first software development job was for my parent’s company. I had been poking around on a Commodore 64 for a couple of years and even had a few working pieces of code on Floppy disks that I would take over to my friends house and copy for them to use (Old School Github). Mom and Dad bought a new computer system that did not do what they needed it to do. My sheer luck, the system was written in a dialect of BASIC. Since I pretended to know BASIC, I stepped up and was officially a software developer.

That was more than 36 years ago and I am still at it. I never did finish my CS degree. I was never formally trained in any aspect of software development. What I know I learned two ways. 

This article is a collection of things that I have learned over the years that I wish I had known starting out. I hope it helps you as you are just starting out.

Have patience with yourself, have patience with others. As a junior developer you are not going to know everything, and you are going to make mistakes. If you are lucky enough to have landed a gig at a company that is willing to nurture you, take advantage of this. Good companies will understand that you are learning. They will assign you a ‘buddy’ to help you figure things out. They will point you in the right direction when you are looking lost.

Let me repeat this, you are going to make mistakes. You are going to submit a pull request that has a blatant logic bomb in it. You are going to write code that if actually rolled into production would delete half the database. You will at some point write a security vulnerability. That’s all ok. That is why we have code reviews, so other developers can help you spot these things and become a better developer. 

Here’s a secret, the senior developer on your team has done all of these as well and chances are good that they have done it within the last two years. :)

Be patient with yourself. You will get there. If you stick with it, you will eventually shed the “Junior” in your title, but it will take time and work, and lots of mistakes.

The only constant in software development in the past 35 years is that everything changes. Languages come and go, frameworks change so fast as toe be ephemeral, even best practices evolve over time. As a junior developer you get hit with a double whammy. You have to learn the current tech stack just to be useful, but you also have to start learning the changes to that stack as well. On top of that, you have to keep an eye on new technologies coming down the pipe that may or may not be useful to you.

Mastering the ability to learn is vital to the success of your career. We discussed this exact topic with Olivia Liddle, a professional training, in an episode of No BS Engineering titled “Learning to Learn” , give it a listen and learn something. 

Languages, frameworks, platforms, IDEs, testing frameworks, these all come and go. You may get three to four years out of the knowledge you learn while mastering a given framework, but when you move to a new one - and you will - then that investment is lost.

Concepts like Object Oriented Programming, Functional Programming, Design Patterns, S.O.L.I.D., and others will serve you across languages and frameworks. 

This is not to say that you should not be the best Java developer you can be, or that you shouldn’t bother learning the ins and outs of your tech stack and tools, but temper that learning with mastering the concepts behind the language and tools you are using. That knowledge transfers to other languages and other stacks.

Whomever said “don’t reinvent the wheel” was an idiot. I would never put a bicycle tire on a NASCAR racer, they invented special wheels just for those cars. Software developers reinvent the wheel all the time because they need a specific type of wheel wit special attributes. 

What you should not do however is try to write everything yourself; try to reinvent all the wheels. Look around you, explore other people’s code on Github, or Gitlab. PHP developers have a great resource called packagist, JavaScript developers have a similar tool called npm. Whatever your language, check out it’s package and dependency management tool so that you can see what others have created. There is a 99% chance that what you need already exists. Try that first. 

If you can’t find something that meets 100% of your needs, is there a project that you can fork instead of starting from scratch?

Sometimes, yes, software developers reinvent the wheel, but when we do, we know why we are doing it and can defend the decision when called to do so because honestly, this is always the most expensive choice. 

Have you ever watched one of those movies where  a software developer (usually called a hacker) is sitting in front of 2 screens and on both of them code is scrolling by at a fast pace while the hacker nods knowingly like they are reading and understanding what they are seeing? Yeah, that doesn’t happen. A more common scenario is that a software developer will fork a repo, clone it locally, open their editor of choice and start reading through the code.  Reading other people’s code is probably the best way to learn how to program. If you know what the code does then reading the code shows you how someone else solved the problem.

Just like a great writer reads more than they write, a great software developer will read code, theirs and other peoples, more than they will write code. As a junior developer this goes double for you. Since you do not have a body of work to copy and paste from, you need to see how other people solved common problems so you can understand how to solve them yourself.

Remember my origin story above? This was pre-Internet. Yes, we had BBSs, but there wasn’t a lot of sharing back then. Literally, I had to buy books, read them, write code, and try things until it worked. It was me, the author of the book, and a stuffed monkey I talked to. (He was my first mentor)

These days, software developers have a plethora of options for information and sample code, Stack Overflow, Stack Exchange, Reddit, the list goes on and on. Still, finding code is only one half of the problem. Deciding whether the idea you have as a solution is a good idea is the other half. The only way to solve that half is to find a good mentor. 

Find you someone who you can use as a sounding board. Someone who wants to see you succeed and is willing to invest their time in you and your success. It may take some time to find the right mentor, keep at it. You will find them if you try.

Once you find a mentor, remember the golden rule “Thou shalt not waste thou’s mentor’s time.” Call on your mentor when you need them. A good mentor will check in on you but still allow you to ask them questions  when needed. Do not bother your mentors with simple questions that you can easily answer by searching the Internet. Instead, ask them when you get stumped. Ask them about directions to go. They are your spirit animal in this stage of your career, not your Uber driver. They will give you direction and advice, but you should not expect them to give you answers. 

Welcome to the wonderful world of software development. Graduating from college, bootcamp, or however you got here was not the end, it was just the beginning. There is no end until you exit the field. You should continue to learn, grow, and discover. A software developer is part artist, part scientist, part life-long learner. Embrace these traits, go forth, and create something to make someone’s life better.