Posted on 19th Oct, 2021
Last updated 3 years ago
Being a developer is much more than writing code. What separates the average from the best is often the mindset. Anything you immerse yourself in, you're bound to be changed by it. This article is about 4 things that recently 'clicked' in me while I was working on a personal project (developing this blog you're on).
The post might be 'a little too philosophical', so I suggest you read it when it's your leisure time. After all, you cannot really think while you are talking.
Backstory
Before knowing about the four things I mentioned, it makes sense that you should know where they come from.
2020 brought a great deal of mental change within me; I went through several tragedies (skipping that part here). I am a different person because of it now. Better even. Around March, the time the pandemic spread, I felt that I suddenly had a lot of time on my hands. College was physically closed, and that meant that I got 8 more hours in my day. An idea popped up in my my mind - 'Let's learn to make apps'. So without much former knowledge about even the most basic programming concepts, I started. And I did learn some stuff, and made some shit apps.
However, one day another idea popped up in my head - 'Let's learn how to hack (web apps)'. So I started taking lessons on Portswigger Academy (the company that made Burpsuite, a popular web app pentesting tool). I did well, before moving on to watching videos and reading articles to become a penetration tester. For more than a year, I did that, and I got pretty good at it for a beginner, despite having no access to the much needed (but expensive) courses and certifications.
I sat for an interview for a fresher's role in a cybersecurity role, and I got selected. It was the only one that offered roles to freshers. However, by the time I got selected, a lot had happened.
One day, a friend of mine had posted his portfolio website on LinkedIn. It looked cool. And, guess what... another idea popped up in my mind.
I googled for the most popular web development framework, and chose React.js. I was below average on actual coding skills. (Maybe I am harsh on myself; I never like my work that much. Maybe that's what keeps me going). I spent weeks trying to understand it, and got pretty decent actually, enough to create my first portfolio website.
I liked my portfolio at that time, however, as time passed, and I studied and experimented more and more, I started hating it. There were lots of things I wished to change.
It had been 2 months since I made that, and after ending a bad internship, I sat down and started designing my new portfolio, followed by developing it, which took 2 weeks. I designed the assets, hunted for fonts, and also kept learning more of React.js and other stuff.
It was only when I was nearing the end of the completion of the new portfolio, that something happened with me. I looked at my yet-to-be-finished project's directory. And I kept looking. "Why is this so complicated?", I thought to myself. I knew that I knew enough back then, so why is, for instance, controlling the theme animations that difficult? The code was easy, but thinking up the code was hard.
Long story short, over a week of time, as I coded, I realised a lot of important things that I, as a developer who has 'just started out', find fascinating. I shifted my paradigm once I realised why I kept feeling overwhelmed even when I actually knew the concepts.
I'll present this shift in my mental paradigm in 4 points below. Once you read them all, come back to this section, and you will quickly see all that I had been doing wrong - mistakes that were hiding in plain sight.
Less is more, more is less
This is one of the most important things every developer should know and put in their work. Often when we are learning stuff, we tend to over-engineer things. Yes, it is indeed possible to over-engineer something.
The simplest explanation is usually the best one.
What you read above, is often used to explain what is called Occam's Razor in Layman's terms. It means, that if there is a simpler way to do something, that is probably how you should do it.
Make no mistake though, 'simple' is a complicated word. Simple is not less. Sometimes, simple is more. It is often found that if something feels overly difficult/complicated to build, and you know that you have the knowledge and yet it feels difficult, then there's a 99% chance that you're doing it the wrong way.
There's a concept called the 'negative space', which says that besides having content, you should also use spaces in designs. It should not be all full. However, you can extend this philosophy to everything in life. If something has no room to breathe, it does not look beautiful.
Extending this to programming, if what you want to achieve feels extremely complicated to implement, then it's probably not a good idea to implement it. The users may not like it. There's probably a better way. Simplicity makes people come visit your work everyday. Let me demonstrate this with a quick example.
Say you want to search and know about something specific, quick. You call up 2 of your friends, and they both suggest two different search engines to you. Assume that these are new to you. Below are screenshots of those 2 search engines. Which one would you use regularly, if you knew about neither of them before?
Allow the water to settle
I think most developers are seen as being glued to their machines, working whole day. While this is somewhat true, do you think they are productive for the whole day?
There is a difference between being busy, and actually getting good work done. Most employers, with their mindsets belonging to the 20th century, would tell you to work more. However, referencing to my previous point, I say 'More is less'. If you work like a mule, your mind is bound to get tired and run out of ideas and the ability to connect dots.
There is an old Buddhist tale, which I like, and is perfect for explaining this point. Below is my version of it.
One day, a young monk was tired of practising meditation. He had been really trying hard to meditate like his teacher teaches everyone, but to no avail. "Meditation brings you peace", his teacher said, but the young monk felt the opposite. He could not bring his mind to peace. He would sit for hours at a position for hours, trying to focus, but nothing happened.
So he goes to his teacher, saying, "You teach lies. What you teach does not work!". His teacher, being calm, asks him to fetch some mud and water. When the monk comes back, the teacher takes the water, goes to another room, brings out a bowl with a painted interior face, and fills it up with the water and mud to the brim. Then he brings this to his pupil.
"What color is the interior of the bowl?", he asks.
The monk cannot see the color, the water is too muddy. "I cannot see", he replies.
"Take this bowl with you, and do whatever you can to peek the color without spilling the water."
The monk takes it back, and thinks hard for an hour, and comes to the conclusion that no amount of moving the bowl around would help; the water becomes more clouded. Then he goes to his teacher and tells him that it is impossible.
Then the teacher smiles, and says, "Keep the bowl in your room tonight, sleep, and bring it back tomorrow to me." The monk does as he is told, curious to know what non-sense his teacher said. He keeps the bowl on the floor, and goes to sleep.
Next morning he wakes up and looks at the bowl. All the mud had settled down, and clear water floats on top. Since the water is now clear, he can see the interior of the bowl. He takes it to the teacher.
"How do you know the color?", his teacher asks.
"The mud resided. It took the whole night."
"And what was the bowl doing during the night?"
"I slept. No one touched the bowl. So it did nothing."
"It was still", the teacher corrected.
"Being still and doing nothing are two very different things. All things reside over time, in nature, even restlessness. When you feel clouded, allow yourself to be still. Your clarity is bound to return, just like this bowl. This is meditation."
Know that you do not know
What you see above is an illustration of an allegory given by Plato, which goes something like:
Imagine that you were born inside a cave, and were chained to a rock inside. The cave has an unlimited supply of food, air and water. At nights, a campfire burns outside, casting shadows people outside.
You grow up in the cave, with no idea of what is outside. 'Outside' does not exist for you, because you spend 20 years of your life in the cave. To you, all that exists in the world are water, food, and walls that become orange for sometime, and brown-black for the rest. Also, the walls show blackish figures, with arms and legs just like you.
One day, however, the chains break, and walk out for the first time. You find out that something very hot sits there, and it gives off heat. When you walk towards it, you look back to see that a black figure looking just like you has appeared on the walls inside the cave. And you realise, that the black figure is actually cast by you standing in front of the light. It is not real. You realise that all those black figures earlier were people; you are not the only man in this world, and the world is certainly not that cave.
So why did I write this here? You see, when you have a predefined notion of what's what, you tend to believe that you already know all that there is to know.
As a developer, one instance might be, that having learnt basics of a framework, when given a 'difficult' task, you see that what you know is not sufficient, so you go ahead and say, "This thing is impossible to build."
But have you consulted the full documentation? Have you read the footnotes? Have you asked people?
I admit that I too was afflicted by this. All you, as a developer, need to do, is read the documentation. Just take time, and read.
Schools and colleges have brainwashed us into thinking that if we do not know something, we are a failure. So, to not admit that we do not know, we would rather deem something straight as impossible.
'Unbrainwash' yourself. Not knowing is not a failure. If you do not know, it simply means, that there is something more to know. That's all it is. I'll be ending this point with a quote.
If all you have is a hammer, every problem looks like a nail.
Do not look at the arrow, look at the target
There is a Japanese saying that goes something along the lines of,
Do not look at the arrow. Look at the target. The arrow will find its way.
Many a times we seem to reverse the goal of development. We should make the code fit the purpose instead of making the purpose fit the code.
This point is about the goal-oriented approach of planning and coding. Before you even start to write code, do you have an idea of the finished product? Most people think that they do, however many just go along and wing it with their code. The code then becomes the center-piece, and the actual product becomes a byproduct of the code.
Maybe you do not do this. I know I did, a lot, just blankly coding, and making features along the way.
The paradigm you should follow, in this case, is to prioritise the actual product, and draw your code around it. Your choice of platforms/frameworks/packages should depend on goal, and not the other way around.
Think before you code.
Conclusion
Frankly speaking, I have zero idea if anything I said above made sense to you. Maybe some of it did. Maybe none. And that's the very nature of understanding, if you do not have even a slightly different opinion, then you are not thinking.
I have found these points to be my guiding principles, and I put these forward in the hopes that it may help you too in some way.
