When I got my first internship as a software engineer, my manager will tell me we want to build an endpoint for an email service, it should do the basic CRUD functionalities: create an email, retrieve an email, edit, delete. Then he’ll create a ticket for me then schedule a time with me where we will sit down and he’ll basically tell me step by step what I need to do, tell me the fields my tables should have and their types like the email table should have a name field which is Varchar, blah blah blah. You’ll create your serializers, create your views, hook up your urls. He basically solved the problems for me and left me to implement.
Then I got my first job as a full time software engineer, I’ll be given a task that said, create an endpoint for this and that, we’ll need these fields and senior engineers will take me through how the problem will be solved. Now I just get told the problem and I have to figure out how to solve it and implement it.
As you grow, your problems also evolve. That can be fortunate or unfortunate depending on who you ask and this is where the friction comes in. For most beginners, you go through tutorials that focus on implementation of the problem and not how to solve it. The onus is not on the tutors of these tutorials to teach you how to solve problems by the way, the onus is on you. When you’re learning a programming language, you learning syntax and some idiosyncrasies of the language. If I know English and I decide to learn French, all I did was learn French, if I can’t solve problems in English, I’m not going to solve problems in French.
Leslie Lamport said, “coding is to programming, what typing is to writing” and that couldn’t have been more apt. Most people know coding instead of programming because that is what most tutorials teach. The first time it hits you is when you try to break the tutorial hell and build your own thing, you realize you actually don’t know what to do, mostly because all this time, you have not really thought of how the problem was even being solved or the logic behind the features you’ve been building. You have not been programming, you have been coding. Programming is language agnostic, a person who knows how to solve problem in Python doesn’t need to know how to do so in Golang. He just has to know how to code it.
Programming is beautiful, solving problems is beautiful. When a problem is solved too fast, it leaves you unsatisfied and unimpressed, when it takes too long it becomes annoying and frustrating. When you begin, you sometimes not aware of how difficult the problem is.
You start out slow, with little momentum, with little intensity and then it starts getting to you as you struggle to solve it, the problem reels you in, you begin to lose yourself in it. It becomes your focus, it becomes all that matters, the world fades into oblivion. The answer teases you, when you feel like you’re getting there, it changes position, it takes another turn and you become more lost in it. You increase your momentum, you increase your intensity and you keep up the rhythm.
Then finally, you get to that eureka moment. Your breathing increases, your heart rate rises and your strokes quicken, you’re almost there. And when it all comes together, there is gush of emotions that climaxes it all, you become elated but for a little while and then you realize the beauty was all in the journey.
Top comments (0)