What should a software developer not do?

Write an engineering article with a concrete timeline in Markdown format from the following transcript.

there are lots of advice out there on all the great things you should do as a software developer like learning and upskilling and this and that but what are some of the things that a software developer should definitely not do let's talk about it today then these are the things that I recommend you to totally avoid and the last one is what a lot of people hate me for but it is 100 True first thinking that a working code is Task done no a working code is the least your employer is expecting out of you you are expected to do lot more than just to ensure that your happy path runs or your code is working here are few of them first the bare minimum your code should work second your code should be extensible where it should be easy for anyone or for you to extend your code to meet future product requirements when I say accessible it implies because at end you are solving up business problem a product problem a product will evolve so which means that if tomorrow a new requirement crossover you cannot say hey you did not discuss this in requirement so I cannot I would have to rewrite the entire code No it should not be the case your code should be extensible enough so that you would be able to accommodate future product requirements third is your code should be well documented so that anyone who would be reading your code with that documentation be able to understand how to use it or what it does fourth your code meets all the best practices that your organization or employer suggest you to do around performance around writing code around practices all of them fifth is your code should follow the standard of a code base which is where I would like to elaborate a few things more around every code base is unique unique in with respect to the kind of practices it follows for example every code base has its own peculiar way of defining global variables defining class names defining local variables defining constants understand that understand how that code base is written and your code should be indistinguishable from any other line of code which is ever written in that code base and that is truly a good code base then your code should cover all edge cases you should not just say hey my code runs when this like you should not have a condition supply on your code your code should always run for all possible cases and that is really important for you as a software developer to ensure and to ensure that no one else like changes from no one else is breaking your logic you need to have sufficient test cases for your code that is expected out of your unit test case integration test case and what not and last but not the list your code should run should be running fast at scale because you should not write n Cube solution if when N squared is possible you should not write n square if log n is possible right you should know the kind of complexity that your code bears and try to get the max out of it and that's these are the things that are like bare minimum expected out of you as a software developer the second thing that a software developer should definitely avoid is Reinventing the wheel we as Engineers like to build things from scratch how many times has it happened to you when you were using something you said I can build this in two days why should I just use this and use this application for example when you are building your own portfolio websites you would always think yeah write my own static site generator why should I use next.js why should I use Jekyll or something like that right it that thought comes to your mind youth may think hey I I want to do this let me write this entire new library you would not do Google search to find an existing library that does that exact same thing but you would choose to re-implement that entire thing on your own but don't do that why because if you are Reinventing the wheel first of all for a hobby project okay but if you are working in an organ organization and trying to reinvent the wheel problem number one your project delivery timeline would shoot at that you are expected to deliver things on time and if you are just keeping on Reinventing the wind that's not good for your business that's not good for your product second is whatever you write will have bugs you cannot be overconfident say my code doesn't have bugs whatever you are writing the code would have bugs in in comparison to an existing popular open source tool which has been tested by so many teams right so you need to know when to reinvent the wheel let me give another example where you should reinvent the wheel for example when you are thinking of an existing web an existing solution does not fit your requirements where you are not able to find anything that exists that solves the problem that you are having that's mean that means that you are finding a solution or you are on to something where you are finding an you are finding a solution for your own Niche that's where it's okay for you to reinventable but not always and it has to be very thoroughly discussed on when you are trying to rebuild something from scratch right the third thing that a software developer should definitely avoid is to not over engineer an extension to the previous one when I say over engineering it's about handling scale you should not think of handling a billions of users on Day Zero or you should not be thinking of handling infinite scale on days you know because most products don't last more than two years so why would you want to waste time thinking of infinite scale where you know that in next two years these are the number of users which I would be able which are which my organization will be supporting you handle for that because it is far more important to deliver things on time versus taking time to build things that would work at infinite scale right because building things that work at infinite scale it takes really long so in some cases or in most cases businesses would want to hit the market first with that new feature versus thinking hey I'll build the best one out there right the world is highly competitive and you need to know that you are not just someone who is writing code for the organization but ensuring that your business and your product sees a positive impact by the work that you are doing if you address eating up time not good right okay the fourth one the fourth one that a software developer should avoid is having a strong bias you are not part of a cult understand this you should not say I'll use no matter what happens I'll only use python as my packet programming language why what if you want to write a high performance application you cannot write it in Python so then you should not just think this is the language that I'll use this is the database I'll use no matter what I'll only use mongodb why you need to understand every single tool or technology or framework or database whatever exists it exists because it solves one Niche really well whichever tool whichever technology whichever language solves that Niche for you you pick that and that's how you should be thinking for example ready skips things in memory and it's memory bound and not discount so use cannot just I'll use redis for everything if you'd want to store large number of date a used one to store large data you cannot store it on it is you have to go for a persistent data store that is disk bound like 10 more TV right so be open with your choices don't have don't form strong biases around anything that only this is good and that is bad only Java is good and Scala is bad and kotlin is good and python is bad no the soft the domain of software engineering is there is no one-size-fits all it's all that this is the case this is what you do there is no that does not exist a flowchart for you there does not exist a decision tree for you everything is a trade-off and you need to know that and the final thing the fifth thing that is software developer should avoid which a lot of people hit me for is thinking design patterns are everything no I talk about extensibility I spoke about extensibility thinking saying that your code should be extensible that tomorrow a new product requirement comes in you should be easily be able to extend it but you need to know how where to draw that line because over abstraction over extensibility kills productivity kills developer experience makes it harder for people to understand code basis imagine writing five layers of nested abstraction 10 different implementations of an interface and then a developer needs to figure out what exactly was the flow of my code extensibility is good but over extensibility is bad abstraction is good over abstraction is bad what I am saying is understand where you need to draw the line in some code basis 10 layer of abstraction is fine but if you are a startup if you are an early engineer if you are working on a smaller code base you don't need to make everything extensible thinking hey what if this happens in the future no in most cases that would never happen right so but whenever in case it even happens you would have time to refactor your code but doing that on day 0 might not be the best decision your first thing is to get things delivered drive to Dr try to derive outputs and outcomes and not just some fancy design patterns don't try to superimpose design patterns on everything I'm not saying design patterns are bad but you need to draw the line that when over when your abstraction is over abstraction where your extensibility is over extensibility because at the end your code needs to be easy to understand by other developers and it should be easy to extend this definition varies as per organization as per product as per maturity of your team so understand that well right and these are the five things that I believe every software developer should avoid let me just give you a quick gist on that first one was thinking that the working code is Task done second was Reinventing the wheel third one was to not over engineer fourth one was to having a strong bias fifth one was about thinking that design pattern is everything because there is no hard and bound rule to everything right so yeah this is all what I wanted to cover and this one I hope you found it interesting hope you found it amazing that's it for this one I'll see in the next one thanks [Music]

Here's the video ⤵