6 Lessons from Learning to Code

With the end of the 2018 quickly approaching and the production build of Chromatic FM starting to look like a real product, I’ve spent some time reflecting on my first year of 24/7 intense coding on a solo project. As a 31 year old Sales / Marketing / Business minded, former non-technical CEO, I was the very last person I’d ever expect to go down the path of learning how to code. Engineering speak was as foreign to me as the sounds heard from the streets of Beijing or Paris. As such the following lessons I believe are useful if you are in the process of or thinking about making the dive into the world of software development.

1.You don’t have to be a “math person” : The preconceived notion that you have to be a “math person” is a roadblock that kept me away from coding my whole life. I was never bad at math but I was never incredibly good at or passionate about it. My old technical business partner was a child math prodigy and all the developers who I’ve worked with over the years seemed to all be math geniuses so obviously I’d never be a good coder. WRONG. While there are math operations involved, most development I’ve run into in my first year consists of very basic logic statements (if this → that, while doing this -> do that, looping etc) and if you have the ability to add, subtract, divide, and multiply, you have the potential to be a good developer.

2. Learning takes consistent, repeated practice : You don’t go to the gym once a month, do a curl or two, and expect to look like Arnold in his prime. Pro athletes perform the way they do because of the training effect. It is your body’s natural growth mechanism when stress is applied (see diagram below).

The training effect in fitness — Steve House & Scott Johnson

Fitness is an apt analogy because the training effect also applies to your brain. In the fatigue phase, you are intensely focused on trying to learn a new coding concept or trying to solve a problem for ten hours straight. When you hit a coding roadblock, after a recovery phase (sleep) your brain creates new connections overnight and the following day the seemingly impossible problem from yesterday is easier and the process repeats. Most seemingly super human feats both physically and mental are accomplished this way over a long period of time. Repeated, consistent, gradual cycling of stress and rest.

3. You have to learn to sit with extreme discomfort : This is one I continue to struggle with as I believe it’s one of the hardest parts of development to overcome. Your mind is your own worst enemy and never is it more prevalent than in solving engineering challenges. In fact, I can’t really think of an analogy here because it is something I’ve only encountered in coding. Often you come up against a challenge that just simply seems impossible. Or a bug that just won’t go away. I can’t tell you how many times I go to sleep at night after ten hours working through the same problem that just persists. This is a terrible gut punch feeling. There’s a voice consistently telling you: “Nope, see you’re never gonna be a developer, you’re stuck” and the problem will seem like you’ll be stuck on it forever. Sit with that discomfort and 100% of the time you solve the problem eventually. Sometimes it actually isn’t you, it’s a dependency somewhere that you have to get rid of but most of the times you either missed something super obvious like a colon somewhere or accidentally capitalized a character or you majorly overthought the solution and the real solution was one line of code. Which leads me to the next point:

4. Any problem can be broken in down into basic components: There is no such thing as an impossible problem. Period. I mean we landed men on the moon! Come on! Literally everything in the universe is broken down into basic parts that have their role in the bigger scheme. When you get stuck, use print statements and break points to trace these basic components and draw out how the work together. I’ve found that like a big jigsaw puzzle if you lay out all the parts you can start to see the big picture emerge.

5. Rest is key: The brain is a powerful tool that is constantly generating new connections and to push it too much means you won’t give it time to create those connections. In computing there is the concept of background processes, the programs or functions that get kicked to the background while something else is running in the foreground which I believe is another apt analogy. There are tons of cases where I’ve been stuck for weeks then, in the middle of a hike or ski tour when the coding challenge is running in my background process, I suddenly come up with the solution, usually a totally obvious one that I kick myself for not seeing earlier. Putting your code challenge in the background of your brain is how you solve most of your problems. I’ll repeat. Do something else that relaxes your mind and you will come up with solutions. It’s so consistent it’s like magic. In fact if you take anything away from this article, take this. When in doubt, put it in the background!

6. Put on a lecture: A lot of times I get stuck on a problem I simply don’t have the skills learned yet to be able to tackle it. When this happens I stop beating my head against the wall and start learning. It’s especially hard to do this when you have a deadline but sometimes it is the only way and the most effective way to clear the roadblock. The web is filled with free and cheap lectures on every language and tool you could ever need. There’s been many times where I basic lecture on a new concept completely clears the mental blockage from a problem I didn’t have the solution for. Here are some resources I use to keep consistently learning:
https://www.w3schools.com/
https://www.raywenderlich.com/