For two years I was coding instead of programming!

What I learnt after changing my perspective towards programming. (Insights from personal experience)

Ever been stuck on how to start coding out a certain problem or even getting lost within your own code! So that has been me for a very long time. After a period of two years into majorly JavaScript, the imposter syndrome started kicking. This was caused by things like;-

• Rejections of job applications (which I think everyone should get used to).
• Failing to figure out why your code is breaking after just a small change.
• Reading successful stories of programmers landing good jobs just months into being self-taught while you are still struggling to have a pull request merged (of course comparisons are not good but damn, we are human).

But here is the biggest frustration I had always had. I really couldn't get started on a fun project or an idea without first googling how to solve it. Well, googling should be every programmer's skill but I was really feeling bad and not proud that most times I had no or less input in a solution that I had come up with. I couldn’t see my input in it until I started thinking about programming in a different way and I thought you could pick a leaf or two.

Having a pen and a programming book always before starting on a project!

Yes, a physical book. (Ok not so physical, sometimes a tab or pad but as long as it's something to write and sketch on freely.) Why? You’ll know the importance at the end of this article.

Most times when I wanted to start the project, I usually knew what I wanted to achieve in the end but rarely thought of how to achieve it, in other words, the process. Knowing what I wanted in the end automatically made me aware of what to exactly google about but all I was googling was solutions (finished ideas/projects) but not the process (how the solutions were achieved) and all I could marvel at was how whoever wrote about the ‘working solution’ really thought through it. In an actual sense, I was a coder but not a programmer.

Programmers think of how to arrive at a solution, coders write down the solution in their preferred ‘gibberish’ language.

I was determined to also write a ‘working solution’ one day and after I had my successful first article of a ‘working solution’ published out in geek culture, I read through it and actually up to now still do not believe that it was me who wrote it because of how it explains the process of what I wanted to solve. Ever since that article, I have come to learn a few tricks that have made me enjoy working on solutions, push through the ‘stuck’ moments and also be proud of my work.

1. Work on something you are curious about

Being a programmer, the number of things you would love to try out can be limitless but very many of them will stop halfway if you were not really interested in knowing how it works.

Having the urge to know the mechanics behind something will always give you a lot of unanswered questions which eventually will begin your quest into finding the answers and most times one answer keeps building on another and getting you closer to your solution. It also makes it fun, something like a quest. I was typing into the Google search bar and it made me wonder how really google knows the word I am typing. That curiosity led me into a rabbit hole that produced this article.

If you have always wondered how a certain system or feature works, feed your curiosity and don’t stop until you’ve replicated the same system or feature. Along the way, there are numerous things you could discover and also learn.

It is fun to work on a project you are curious about than one that was recommended to you.

2. Make use of sketches, notes and diagrams

This is the most important step although it comes second.

Thinking is not enough. Help the brain think better by sketching ideas, making notes, linking bubble diagrams.

That is where the programming book or tab and pen or pencil comes in. Think about how best the solution can be arrived at, write and sketch it down and when you get stuck, that is when the googling comes in (I’ll talk about that in the next point).

At least make an effort to google only when you are stuck.

Writing down the process gives you a map, makes you visualize your mental model, makes you feel part of the solution (even if you got a little help in times you were stuck). To me, sketching, writing notes and drawing and linking diagrams is what I consider programming.

My sketches and notes of this article

You don't need to have the whole solution written out but at least have a mental modal written down on paper that is guiding your coding. I have always gone back to my programming sketchbook and it really made me feel happy about how good I became at thinking about solutions.

If programming is design, every programmer needs a sketchbook.

3. Only google when you are stuck

There is no better pride in having a working solution or code that does not break than knowing that you put in most of the effort.

You may have a number of projects, solutions, contributions or even reviews but nothing satisfies more than having your input in all the effort. While you are working on a fun project, solution or task, make an effort to think of a solution before looking for one. Even when you don't find a working solution, you're better off than someone who didn't attempt at all and most times the solution you find will stick in your memory. I have once come to believe that if I do not know how to think about a solution then I am not a programmer. I endeavour to think before I start googling for a process that will help me solve the problem.

4. Using good and self-explanatory variable names

I know you may have heard about this but let me stress it more since I found it a gem. Since I code in high-level languages i.e Python and JavaScript to be exact, I like it when I read my own code as if I am reading English. Seriously why would you make your own code boring to read? Things I avoid while naming variables;-

• Abbreviating words; If I choose a variable name and it is not so long, I will write it as is. I would rather number than num .
• Using ‘_’ instead of camelCase; Unless it is a team project that follows certain rules, I'd rather declare var previous_letters = '' than var previousLetters = '' .

Choosing the right variables helps you read through the code easily

On top of the variable names, I comment on my code so that it rhymes with the sketches, notes and diagrams I made. This makes me read the code without referring too much to the notes and also makes me remember the logic that cannot be read out in plain English.

“Any fool can write code that a computer can understand. Good programmers write code that humans can understand” — Martin Fowler

After I thought about how better to approach my programming with the above ideas, I am always proud of my final solutions and inputs and at least started feeling like I am really not so badly off as I thought in programming. I hope you find an insight or two in your programming journey.

If you found this article enjoyable and insightful, please give it a clap. cheers:)