I haven’t been in the software development industry for loads of time, but thanks to some amazing people who championed my growth, I slingshotted in quicker than some other peers who did it all on their own. (Props to you individuals, by the way, that wrestled it all out by yourself–you are unstoppable!)

After thinking a bit about my experience I came up with five things I wish I had known when I started developing:

1. It’s 100% normal to feel like you’re drowning

I stumbled my way into coding; it initially started as a hobby.

At first, everything was bite-sized and easy. I was blissfully unaware of how little I knew. Once that bubble popped, my lack of knowledge was overwhelming. Everywhere I turned there was something I could not do.

I remember the first time I tried poking around in the Codex. I ran away thirty seconds later because it all seemed like Greek! I literally did not have the capacity or supporting framework to “get it.” I wish I had known in advance how often it would feel like drowning and that it was fine.

2. Just Keep Learning, Just Keep Learning

Go after all the low hanging fruit that you can. It might seem like a waste of time to spread yourself so wide, but if you are truly a newbie and have no context for the developing world, the wider you go, the wider your foundation will be. Although you won’t be fully aware of it at the time, you’ll fill in the gaps of your understanding so you can level up.

When I felt like I was drowning, I continued to chip away at the pieces I could master and walked away from the pieces that made no sense to me. It paid off in the long run.

You can only handle so much drowning before you give up. By moving on, I kept my overload threshold in the green and experienced small wins that boosted my confidence.

Every so often, I would return to the Codex and give it a go again. When it still wasn’t useful for me, I moved on. I remember the day I was working on something, jumped around several Codex pages…and realized it made sense to me. Suddenly, the Codex was in my toolbox. By expanding my understanding in other areas, I built a framework that allowed me to tackle the previously impassable problems.

I wish I had given myself the permission earlier on to move on when it suited me. While there is a satisfaction to mastering something, I have found the field to be so wide, deep, and complex that it is rare to master something the first go around. Spending all your resources to come out utterly defeated is more costly than saying, “I don’t get it, so I’m going to move on to something else and return to it another time.”

It changed my experience from perpetually drowning to recognizing that I need to play in the wading pool a bit longer.

Note: This should go without saying, but don’t put yourself in a situation where you have committed to do something that is beyond your abilities for a client…because then, you don’t have the permission to walk away from it.

3. Hone in on your trusted sources

The internet is amazing and Google a robust resource, but not all of the resources out there are reliable.

As helpful as Stack Overflow is, quality control is not always a guarantee. Many of the solutions provided are hacks, instead of the industry standard approach to the problem. When you’re starting out, it’s hard to know who you should and shouldn’t listen to. It’s imperative to find good sources that you can soak up. This might require reaching out to experts in the business and find out who they trust.

My introduction to coding started with a free online coding tutorial resource. It was great for the most basic things. However, the further I got down the rabbit hole, I discovered that some of what they were teaching was completely wrong. Fortunately, friends who are professional developers pointed me to some credible resources.

It is hard to unlearn something foundational if you learned it wrong the first time. You only have so much time and you can spend eternity reading about all the different approaches.  Find approaches you can build on so it’s not considered time wasted later.

Team Treehouse proved to be an invaluable resource for me. They are trustworthy and they are actually good at teaching–a huge bonus because not all developers are good at breaking down what is natural for them into bite sized pieces for newbies.

4. After you learn it, build it

I cannot tell you how often I’d go through a tutorial and think to myself, “This makes complete sense. I get it!”

I followed with the tutorial and find myself at the end with the desired product. Ta-da! I learned it, right?

More times then I can count, I noticed that stepping away for the weekend would be enough for me to completely forget it. I found that after completing a tutorial, it was really helpful to go through and build the entire project again without the tutorial.

That was the real test of what I had actually learned, versus what I was regurgitating. It is great to follow along with a tutorial, but that’s only the first level. You need to practice it several times before you get it. The more you build it, the more muscle memory you create.

I wish I rebuilt the same things over and over instead of moving on to the next skill before mastering what I initially focused on.

One final point on building: going through other people’s tutorials is a great way to gain knowledge. However, reproducing something that already exists does not activate your creative thinking.

I discovered if I tried to implement a skill in a different context than the tutorial, I understood the steps to build one specific solution, but didn’t always grasp the concept in its entirety and how it could be applied to different situations. After you master a project on your own without the tutorial, try it again but with a different outcome as the goal. This will keep the skill pliable for you.

5. Get excited about pet projects

One of my biggest struggles when learning to code was that I had no idea what to build on my own. I desperately wanted to practice and try things out, but I had zero idea where to start.

As I mentioned earlier, you can only drown for so long before you give up. The antidote to this is passion. If you are really passionate about what you are building, you will have more endurance to push forward when the going gets tough.

Additionally, the great things about pet projects is that they are often side projects. You probably have other pressing matters that need attending, and so your project will get put on the back burner. This is fantastic!

When you return to it you will see your work through the eyes of a new developer. You will learn first hand the importance of commenting because you’ll probably have forgotten about why you did some of what you did and what all the moving pieces do.

As you improve your skills, you’ll find that when you return to your old work, you’ll be embarrassed by some of your approaches. The upside: you’ll have an opportunity to practice refactoring. These skills are super important and less painful to learn on your own project then in a group project where you’re impacting your peers and clients.

---

I wish I had known all of this sooner.  What about you? What things do you wish your baby developer self knew?