As someone that writes code on a regular basis, you must view a lot (if not all) of your work as problem-solving. After all, that’s often what you’re hired for. Someone has a problem and you solve it using the code that you write. It’s like having a superpower. It’s great! (Who wouldn’t want a superpower!?)
You start doing the same with your own problems. You break them down into smaller micro-problems. You then try to find solutions to them.
Explained like this, you’d think that this a great strategy. And you’d be right! But where you have to be careful is how it affects your mindset. You start focusing on only searching for solutions to these micro-problems.
That’s why so many coding questions follow the formula “How do I do X with Y?” You want a solution to your problem so you can move on to the next one. You continue this pattern of searching, finding and copying solutions until you’re done.
This puts a lot of pressure on the online learning material as well. They need to answer these questions to stay relevant. That’s why you can boil down so many tutorials to “How to do X with Y”
That’s why this relentless focus on problem-solving can come at a cost (after all no superpower comes for free). You become so addicted to finding solutions that you’re not writing code anymore. You’re just integrating (or duck taping) these solutions that you found online together.
But there’s a creative aspect to coding. You’re not just an integrator, a problem solver. You’re also a writer, a painter, an architect. It’s important to never forget that when teaching programming.
The lost art of sketching
One thing that you almost never hear about in a programming class is the idea of sketching. The teacher makes it seem like there’s always a right answer and that it was always there. He’s just teaching it back to you.
In practice, things tend to not work out that way. There’s often no magical insight that gives you the answer. You have to experiment and figure things out on your own.
That’s why coding is a lot closer to sketching. You start working on a solution and you iterate. You keep refining things until you get a working solution.
You might also go in the wrong direction or the specifications might change. This forces you to backtrack or even restart the work that you were doing. This isn’t any different than altering or discarding a sketch.
But because this idea isn’t promoted enough, you feel bad about doing that. You should have had the right answer from the start. The problem with teaching that way is that there isn’t just one right answer to begin with.
The beauty of choice
In fact, there’s no perfect answer when you’re coding. This isn’t mathematics where 2 + 2 = 4 is the only right answer. There can be more than one good answer to a problem.
But with more than one good answer to choose from, the one you pick becomes somewhat subjective. You get a working solution regardless of your choice. So you can let your personal preferences creep into the decision process. This can be both good and bad.
On one hand, you might stick with what you’re comfortable with. Because the technology landscape is always changing, you think “It works so why change?” This is a good feeling to have in moderation. But too much of it and you become close-minded.
But it can also make you more open-minded. You have the opportunity to explore different ways to solve the problem. This is also good, but you have to be wary of overdoing it there as well. Otherwise, you’ll never get anything done!
It’s important for a teacher to expose you to that. It’s not about just the coding language or solving their problems. It’s about helping you develop the right attitude.
The design process
Even if you have the right attitude, you still can’t forget that bad answers exist. For example, there are awful ways to store someone’s password. You wouldn’t want a solution that stores your password in plain text. That’s just irresponsible. (I’d even go so far as saying unethical.)
Beyond the bad answers, a solution can vary based on a lot of factors. Things like the programming language, framework or application you’re using. Yes, they can come down to your personal preferences. But they also limit what you can do, what options are available, etc. This is all part of the design process.
This isn’t any different than a painter working with different types of paints, canvases, brushes, etc. Each has its pros and cons. Sometimes they get to choose which one they can use. Other times, they can’t.
They still do their best to create something given what they have at their disposal. That’s often what you need to do as well. You’re stuck making tradeoffs and finding solutions that fit your context.
That’s why it’s important for the teacher to show the whole design process. Seeing this rough process is super instructive when teaching programming. This is another thing that we don’t see enough of.
Programming in the “real world” is full of choices and tradeoffs. You want to understand the decisions that the teacher took to get to their solution. You won’t be in an ivory tower where perfect textbook examples will work for you. Most of the time, they won’t.
The big C
And speaking of examples, what happens when there are none? This is where things break down when you’re only looking for solutions. There are none for you to find (or maybe your Google-fu failed you).
So what do you do?
Well, you could give up (which is lame). But let’s say you don’t give up (good for you!). You need to create a solution somehow. That’s where creativity kicks in.
For some, creativity can be a bit of a loaded word. There are expectations when you say you’re creative. You might think “Well everything I do has to be SUPER original now.” That’s not necessary at all.
The truth is that there are few original ideas out there. Being creative isn’t so much about finding one of those ideas. More often than not, being creative is about combining existing things in a new way.
To do that, you need the ability to see these new relationships when others might not. And that often comes down to not being afraid of trying something different. You have to be comfortable with exploring the unknown. But also with experimenting with what you find there as well.
It should be the job of the teacher to push you into that unexplored territory. They can ensure that you have a good experience when you do it. This positive experience could then carry over for the rest of your life.
Be the traveling artist
There’s no question that a lot of this is scary. That’s why we’ve talked a lot about the teacher’s responsibilities towards you. It’s during your formative time with them that you’re the most receptive to these new ideas.
But all isn’t lost if you’re by yourself. These are all things you can do on your own. You just need to channel your inner traveling artist. You know the type… They’re always:
- Looking for inspiration
- Observing the world around them
- Questioning what they see
- Experimenting with new ideas
They also tend to meet new people along the way. This gives them the opportunity to create or join networks of peers. They can use them to seek help or find a mentor. Their work also gets validated by them which can help it endure through time.
We all have to find our own world to travel. But, in programming, it all starts with reading code. There’s no way around it. It’s your window into the programming world. It’s an unlimited source of inspiration.
But it’s also an opportunity to meet new people. You can choose to contribute to an open source project. Or maybe you can join a programming community to learn more about the code you read.
If you need to, take some time away from what you currently do. It could be from WordPress or something else. Transform into that traveling artist even if it’s just for a day or two.
Just don’t forget to come back home!