Learning How to Solve Problems

I’m remiss that I didn’t start blogging about my Bloc experience from the very beginning.

If not for myself to be able to look back and see how much I’ve grown, personally and in programming, for other potential students to discover my blog, and use it to inform their decision and experience, as I know how much other Bloc alumni’s blogs have helped me.

If I were to write one post that I felt encompassed a huge part of my development in understanding what it means to grow as a developer, learn to program and be useful to employers, myself, and have the ability to be autonomous with my coding, it would be the ability to address problems individually.

I fully believe in my personal ability to solve any problem, provided I understand the problem. This has been a huge deal for me, because I thought that the answer to solving problems was knowing everything, and applying my knowledge to the problem at hand.

Turns out, that’s not the way the world works.

(I expect over time that problems will become more familiar to me, and that certain problems will feel repetitive and easy to solve, and that will cause me to seek out new problems. But, for now,)

Every programming problem that I face is essentially a brand-new issue that requires me to learn a new concept or subject in order for me to apply what I know to it.

The foremost strategy to solving a problem is dissecting it in a way that allows me to understand what must be learned in order for me to approach it systematically.

Easy problems, such as how to get a certain <div> to a certain position on a page, merely require a trip to the CSS docs, or a quick Google search.

Other problems, such as Codewars Katas, require me to identify the necessary concepts within that I need to learn, learn each one individually, and then see if I can cohesively apply each concept to the question at hand. (I still haven’t fully mastered this.)

What bloc has taught me so far, and what has been a huge focus of my mentor Richard, is that I learn to identify concepts within a problem. It just isn’t possible for anyone to sit alongside me as I program, as it’s an experience that sometimes carries me for 10 to 15 hours a day.

Instead, for an hour or two a week, Richard will focus on a couple specific problems, helping me identify what underpinnings make up the issue.

This specific methodology has been the beginning of a hopefully successful programming career, and I hope it informs my life going forward as well.