Lessons from my first year of coding.

Posted on April 21, 2016 in Code

Another Repost. This should also be called “Lessons from someone who shouldn’t give lessons.”

Like I mentioned in the first post, little less than a year ago I started getting interested in coding. I can’t really say why. Maybe because a lot of my friends were doing it and seemed to enjoy themselves. Maybe because I was just curious. Maybe because I didn’t like my current job. Maybe all of the above.

Problem was, I didn’t really know where to start. I fooled around in Xcode, and moved on to trying to learn through codeacademy and codeschool. It was fun, and I liked the lessons, but I was unsure of where to go next. I felt like I understood the very basics, and from my time as a systems engineer I knew some of the high level concepts of programming. But bridging those two with the middle knowledge of how to design and implement an application never came to me. I needed more practice, but less guidance.

While in NYC, I asked developer/generally smart human James Dennis about this dilemma. He suggested I try Learn Python The Hard Way, and that I follow the rules of the book exactly. The book recommends typing out every line of code, and doing so without the use of an IDE, to avoid becoming lazy and relying solely on the IDE to complete your code. At the time I was on the road and in the back of a van for 6+ hours a day, so this seemed like a perfect way to kill time. I went to work on the lessons.

The book took me about a month and a half to go through. When I came out the other end, I was hooked. The challenges were hard with ever decreasing guidance as the book progressed. I found this fun, and it forced me learn outside of the book and become more self sufficient to solve my problems. I felt much more accomplished, and now felt like I had to understand everything that was going on under the hood. I had some notion in my head that all “real” developers understand the entire inner workings of every line of code, process and bit that was changed. I knew this was wrong, but I couldn’t tell which parts were important to know, and which parts didn’t really matter. Without that knowledge, I felt I couldn’t really do well in the field.

This was my original drive to join Bloc. I needed someone working with me who could be a guide, and tell me what was important to know and what wasn’t. It turned out to be a great experience, and one that I’ll write a lot more about at some point, but for now I want to focus on some early learnings.

Combing Stack Overflow and other sites, I slowly realized everyone has some gap in knowledge, and is somewhere along the continuum from total novice to complete expert. The point is to be curious and be able to problem solve and find the information you need. The Internet has made this incredibly easy, all you need is a little patience to dig in a couple layers to any problem you need.

So, with a long introduction, here are my takeaways from my first year of coding:

Stop Being Intimidated

Software, and sometimes the people who develop it, can be intimidating. I struggled a lot with the jargon of object oriented programming, and the language of Software. I still struggle with it. I’ve never been huge on jargon and subscribe to the say it simply mentality. Sometimes the jargon is useful, but when you’re getting started, I argue that it gets in the way. Do yourself a favor and describe what’s happening in your code in any language you can. Just focus on what’s actually happening. Learn the jargon after that.

Don’t be intimidated by the jargon, the philosophical debates on spaces vs. tabs, the sweeping decrees about the best and ways to handle certain problems faced when coding. None of this is important to learning to code, or creating things for that matter. Focus first on creating things. Learn something every time you add a new feature, no matter how minor. Don’t worry if it’s messy. You’ll get better.

Know A Little About A Lot (and A Lot About A Little)

In a similar vein, I’ve reminded myself several times that you can’t know everything. You just can’t. It doesn’t mean you can’t try, but you’ll have to move forward with something (a lot) less than all the knowledge in the world about software. Rather than drilling down too far on any one topic, I’d suggest knowing a little about a lot of things to start out. Get yourself to a point where you know a little bit about all of the most common components of whatever platform you’re developing on. Along the way, if you find something you really like, learn about it in depth (Know a lot about a few things.) Just be sure not to go too far down a rabbit hole to start. Pop up and keep gathering broad knowledge first. It’ll help you keep progressing and gives you a foundation to come back to.

This is not a one time process. Keep doing this over and over again, learning a little bit about a lot of things and learning a lot about a few things during each project. Eventually, you’ll know a lot about a lot of things.

Bang Your Head Against The Wall

Stack Overflow, Quora, and the internet in general are incredible tools to find any knowledge you may need. I’ve found only a handful of issues over the past year that I couldn’t fix with a 30 minute hunt on the internet. Being part of the last generation that can remember a time before the internet, this type of easy information still blows me away.

But I want to advocate for something very different when you first encounter problems, particularly if you think they are fundamental to your app: Bang your head against the wall. Spend a couple hours on your own digging through the Apple reference docs and code base trying to solve your issue. Try a few things. Break your app. Write down some notes. Try a few more things. Break your app again. Get a little frustrated, (but not too frustrated, see my next piece of advice.)

For me, getting stuck for a couple hours is the right amount of time. These hours have in the long run provided me with a lot more learning. Several times I’ve surprised myself and solved the problem without going to outside sources for help. Even when I haven’t, I found that I learned more (and retained more) by really thinking about the issue for a while.

Getting stuck will sharpen your problem solving skills, and make you a better thinker. They also help you prepare for the inevitable times as a developer that you’ll get stuck on tough issues, and there may be no Stack Overflow answer to save me. I used to loathe these times as a programmer, but now I cherish them. The best learning happens during these times.

Embrace Your Ignorance

After those couple hours of banging your head against the wall like I recommend above, stop being so hard on yourself! Resist the boiling frustration that comes up, saying “you’ll never be good at this, you should have the answer!”

You are new at this. It should be hard. You are not required to know everything. Go find the answer from people more knowledgeable. Embrace your ignorance.

Further, don’t try to pretend that you know everything when you talk to fellow developers. Be honest about your skills, and ask good questions. This is far more impressive and productive than pretending that you have an answer for everything. Learn to say “I don’t know” when people ask you tough questions about software. Then go try to find the answer.

Just Try It

I came from a mechanical engineering background, which meant I worked almost exclusively with hardware. This meant if I screwed something up in my design, there was a big cost to buy new parts (and wait for them to arrive).

Software has no such penalties, which is an incredibly liberating and powerful feature. Use it! Don’t be afraid to break your code. You should be doing so on a regular basis. Try all sorts of things. See what it does. The worst thing that happens is that you undo your changes and try something else. No penalty whatsoever! So get out there and start writing code. It will break. At first you’ll have no idea why. But you’ll get better, and eventually write less buggy code, and learn to catch bugs faster. The sooner you start trying things, the sooner you’ll get to this point.

Copyright © 2017 Trevor Vieweg