DEV Community: Shailen Naidoo

Rewrites are a symptom of bad initial engineering

Shailen Naidoo — Sat, 20 Apr 2024 16:25:45 +0000

I was prone to this problem at the beginning of my career, I would want to rewrite everything from the ground-up if I got this chance or I felt that the initial implementation did not "scale" well.

As I progressed in my career I started to realize that rewriting your application is a symptom of bad initial engineering. The application was not thought from a systems design perspective and the use of SOLID and other principles allows you to manage application code better in a system that is ever-changing.

If you come to a point where you need to rewrite an application then it just means that you did not spend the necessary time to design the foundation of the system which takes into consideration ever-changing business requirements.

I am looking for work as a front-end engineer

Shailen Naidoo — Fri, 15 Mar 2024 08:44:08 +0000

Hi everyone, I am looking for a frontend engineering role, I am asking the community to let me know of any available roles which are remote as I am in Cape Town, South Africa. I am ready to work and happy to chat with anyone keen on taking me on as a front-end engineer.

Why I stopped using IM platforms for communication and only use email

Shailen Naidoo — Thu, 07 Mar 2024 08:23:32 +0000

The title of this post might come as a shock to a lot of people because who on this Earth prefers email communication over something as instant as an IM service such as WhatsApp?

I have always disliked IM services ever since I started using WhatsApp years ago. There is a sense of urgency when it comes to using IM services which I do not like, every message that comes in feels as if it has to be attended to immediately and to me this creates a false expectation and reduces one's ability to prioritize what is important versus what is not.

I like to think of a digital solution to something as a virtual reflection of something that occurs in the physical world. Imagine you have 30 chats from different people and everyone wants your attention and everyone is blowing up your phone for something, this kind of thing cannot happen in the real world as it is impossible to split your attention across 30 different people and provide a valuable answer immediately.

You need the necessary time to respond and provide the best feedback possible without reducing the quality of what is being communicated. You need that sense of pause so that you feel free to respond when you can.

To me, email is perfect for creating that sense of pause as it adheres to a more traditional style of communication because it is analogous to a physical letter or post mail. There are no read receipts so you cannot know whether people have read it or not so you have to detach yourself from whether someone has seen it or not and if they do not respond you have to let that insecurity go. You are writing into a black hole without ever knowing whether someone will get back to you or not and that is okay whereas in the IM world, you are expected to respond within a millisecond of receiving a message from someone and this leads to more emotional problems being created.

I do not like the anxiety and frustration that comes with IM services. No one should ever feel entitled to a response, there is also an aspect of ego in this but it is good to create healthy communication boundaries for yourself and to enforce those boundaries with people.

@ts-ignore is a symptom of a code smell

Shailen Naidoo — Tue, 20 Feb 2024 12:22:44 +0000

I never was a fan of TypeScript, I believe that TypeScript was a response to Java developers wanting to work on the front end. I believe that you can achieve what you need in terms of type inference using plain old JavaScript and JSDoc.

TypeScript is a marketing point from Microsoft to get developers to use their tools and technologies. The fact that TypeScript allows developers to use @ts-ignore to ignore the type-checking errors is a symptom of a far deeper problem thus a code smell.

The fact that @ts-ignore even exists is a signal of TypeScript's poor design as it creates an escape-hatch for developers to use when they have broken their typing somewhere in the application logic. This defeats the purpose of type-checking and leads to a broken application with another layer of complexity that is sprinkled on top of it. TypeScript is nothing more than fanfare to me with a breakable type-checking system.

Determining the number of "if" statements in your codebase

Shailen Naidoo — Mon, 19 Feb 2024 10:51:43 +0000

Think of conditional statements as if they are bombs waiting to go off. It might be a great metric for the team to identify how many conditional statements are being introduced into the system or how many have been removed.

I wrote a simple bash command using the popular grep and wc tools found natively in most bash implementations to scan my source code and identify the number of conditional statements.

grep -rni --exclude-dir="node_modules" "if (" * | wc -l

Having a number for people to see gives them an idea of the general complexity or branches within an application. I believe that reducing this number should be a general goal of a software development team.

Treat the frontend as if it is dumb

Shailen Naidoo — Mon, 19 Feb 2024 06:34:51 +0000

The frontend is nothing more than an interface for a layperson to interact with so they can perform a task or a goal in mind. It is a given that the frontend will interact with a backend API at some point throughout the user journey.

To me, the more control flow statements (if/else) exist in a system the higher the chances are of something going wrong or at least the higher the number of edge cases that will be introduced.

I try my best to determine whether control flow statements should exist on the frontend or the backend as I try to treat the frontend as if it is dumb and defer all the responsibility or a large degree of responsibility onto the backend when it comes to control flow statements.

I feel as if developers do not think about control flow statements enough, it should be the goal of the developer to reduce control flow statements in the frontend and aim to push a majority of that logic to the backend whenever possible.

The best software engineers write instead of code

Shailen Naidoo — Sun, 18 Feb 2024 09:30:07 +0000

There is this misconception that software engineering comprises of several people getting together and writing code to meet an end goal but that is not what it is about. You will never see a car manufacturer building a car without some kind of plan, they have an entire dedicated team to the research and development of their next car.

Software engineering is the same process, whenever I try to develop something. I first close my IDE and do not even think of the code as the code is merely an implementation detail. In my document, I write what approaches I want to take when doing something or what it is that I am trying to achieve and from there, I start to flesh out the smaller implementation details of the project.

I would much rather write out the possible unit test cases as this is more important than the code itself. The code can be ugly, and it can be messy but as long as the unit tests pass and we have accounted for all the edge cases that we can identify upfront then I am happy with whatever is needed to achieve the desired goal.

You will often find that important decisions get lost if they are not tracked properly. This can lead to a lack of accountability in the team and unintentional forms of gaslighting where people cannot remember that they agreed to something and when you raise it as a concern then it becomes a problem or it does not get taken seriously.

I try my best now to ensure that any decision that is made by the team is tracked and acknowledged in writing before moving on to the next step, this will save you in the long run.

There is always an edge case (to life)

Shailen Naidoo — Sat, 17 Feb 2024 09:30:01 +0000

If something at face value appears to have only happy cases then the developer does not have the scope to understand what are the edge cases or they might simply be blinded by the implementation of whatever said thing is.

I believe that developers spend too much time or emphasis on the happy case of something, instead, they should work on flipping that mental model around and spend more time trying to identify what the edge cases are and account for those instead because in my experience, the more control flow statements introduced into a piece of software the higher the number of edge cases there will be.

This same model of approaching software design can be applied to just about anything in life, there is always an edge case to something and if you cannot see it now then it will eventually appear later down the line. One's capacity to identify edge cases comes with experience.

It is a bit negative to walk in the world and see the negatives of everything in this life but it is up to you to utilize it as a tool at the end of the day.

Treat onboarding on a project or team as if you are invited to a five-star hotel

Shailen Naidoo — Fri, 16 Feb 2024 16:47:07 +0000

I had an interesting conversation with the Practice Head of Frontend Services at DVT earlier today. I mentioned to him that when being onboarded at a company, the developer who is joining a project or team should never come in with the idea that they are in charge or they are going to start shifting things around for the better on the first day or in the first week.

It is important to note that the people you are going to join on a project have been working on said project for a long time that is if it is a mature project and so they have put their blood, sweat and tears into the project. They have an attachment to the project so if you come in and start trying to make things better on the get-go there might be some personal pushback from the team.

This is why I like to think of a project or team that you are joining as a hotel or someone's house that you have been invited to. You never go into a hotel and tell the hotel manager how to do their job or you never go to someone's house and tell them that they must get new carpets because it is so ugly and you do not like it. These things deviate from the normal social constructs that we all live by.

If I had to be invited to a friend's house, I would be a guest in the equation. I would treat the person's home well and be polite as they have taken the time to accommodate me in their home.

It is nice to think of joining a project or team in the same manner, it is best to sit back and let the team who have been working on the project for 1 - 10 years guide you through all the ins and outs of it and you should take as much notes as possible even if you know that you are a gifted software engineer.

It is called practising humility. Later on, as you feel more comfortable with the team, you can slowly start introducing ideas that you like or things that are more process and document-driven to the team such as clearer commit messages with deep references to decisions.

If you join a project or team and straight off the bat you come in and try to fix everything or tell everyone of all your amazing ideas then it will come across as you being smarter than everyone or they will take it personally. This is a solid sign of maturity in a software engineer, the moment a software engineer starts being concerned more about the team morale and sentiment than technical details that is when they become a senior software engineer in my view.

You can be the greatest technically gifted software engineer on the planet but if no one wants to work with you or if you cause stress every time you join a meeting then it is a sign that you lack the necessary soft skills to command a team or lead a team.

This is a profound way to think about working with people as being smart is one thing but being virtuous is of a higher importance.

Software Engineering is not about code

Shailen Naidoo — Thu, 15 Feb 2024 10:48:41 +0000

There is a strong possibility that I might get a lot of backlash from developers all across the Internet but I need to share my viewpoint on Software Engineering with whomever is interested in my viewpoints.

I believe that software engineering is not about code as most developers believe it is about. To me, code is nothing more than an implementation detail to execute a set of instructions which was architected by a software engineer. What is of higher importance is the design documentation or the technical documentation surrounding the software that is going to be built. The underlying tools and technologies that are being pulled in to achieve a desired outcome concerning the design documents are nothing more than tools and technologies.

An architect who does the blueprints for a skyscraper has to take into consideration numerous factors beyond just the tools and materials (technologies) that will be required to achieve the development of the building. There are factors such as:

Wind
Foundation
Sewerage
Stress points
Legal documentation
Clearance from the City.

There are numerous other factors that one needs to take into consideration beyond just the tools and materials (technologies) when it comes to developing a building. The same applies to software engineering, it amazes me how developers are more interested in the raw development of the application instead of taking the necessary time to sit back and just write up a design document for what the goals of the project are.

Code is not important, code is nothing more than a hammer or piece of wood but it does not form the entirety of software engineering. The day a developer decides to write less code and starts seeing control flow statements as a ticking time bomb is the day that they have reached a place of maturity in their field.

Do not show me the code, show me the design document for whatever it is that you are doing. Most developers want to create the path whilst validating their ideas but this is an immature way of approaching software, one should aim to clear the path during the design document phase and then pull together the tools and technologies needed to achieve said design.