After being a developer for 13 years been through 30+ projects . they are the mindsets mistakes which i think important to every dev.
#1 I need focus , I do not want to talk
Everyone like to be in focus and stay in flow mode to do coding . but if we all keep doing these for days without any effective communication, will be more likely end up with some exceptional situation :missed a feature, misunderstood some requirement; or wasting each other’s time : backend waiting UI to be ready and same to UI, or QA waiting some feature to roll out from dev actually it’s done, they waiting each other like a “deadlock” .
Communication is very important part of work , as developer , we need flowstate , we also need to talk effectively to be more productive .
#2 After changed few companies, why bad code is everywhere
I have been there . when i just graduated within first my 5 years I changed 4 jobs. After each change every time i could find a clean ground , but after some months, code started getting messy .
so the reason is not about project or others, is ourselves lack of certain skill to get into some existing project and make it better . if you find some project code is s**t . challenge yourself , can you make it work ?before you refactor ,do you really understand how many cases the piece of code is handling ?remain humble , there are always some piece of code you can learn from.
If you find some code is very bad, before you go, remember this : it is easy for everyone to start from clean , but it is much harder to make dirty to work , and make the code clean piece by piece, this is the skillset about refactoring .and if you never get this skillset , you will more likely get dirty again and again from another clean ground !
#3 As a developer, most my time is about coding
No. Think in this way, we build things and own it. make it less problematic (testing) make it clear (documentation) and improve the process (devops) , do it constently .
Don’t get me wrong ,I am not ask you to switch context too often ,we all know that flow state is important ,but we can jump into flow state doing different things, do not restrict your mindset :only coding is the imporant to you.
So when we start the next flow state, instead of just thinking “what else code i can write”, or “which exception i should catch” or “extract what functions into a class” , or “this code is not single responsible”.
It should be testing driven , the lines of code should be driven by test cases in mind. we should think about “what else need to be tested” and ”how to pass this test” ,”what test case is helpful to be included in CICD pipeline” and “what information should be documented” for others to know (instead of just comments for dev).
#4 Not reading others code much
When 10 years ago the mistake i made was not read others code , or not familiar enough . We too much focus on our own task .the result is bad .
First thing is we will create some inconsistency (naming, or similar thing someone cached and we didn’t ) , or wasted time(someone else working on same thing, or wrote same function) . the benifits of review each other code is a lot . if we often read each other code, entire codebase will look consistent , less rework and saved each other time, also we can help others to find bugs by reading it. do not forget to talk to others and read their code ,we need add this into routine .
#5 Not carrying minimalism mindset
Every developer like coding. but more code we write could increase higher chance of bugs ,also there is test and mainteinance cost .
The key idea is we want to write or keep the change as less as possible to archive the same.
For next task, challenge yourself : can it be done with less changes? has this already by any library ? or are you writing some helper function which could already been returned by someone in your team or other team? can this be done by only tweak some configuration or database value without change any line of code ?
Always keep in mind trying reuse what already there, instead of creating one and another class or functions.
#6 Only debug, never test
have you ever thought of : “I only do the coding work and leave the most testing work to QA “. this is very bad idea .
Again, we own what we write .
We wrote every line of code, so we need to do enough unit, manual, integration test . as a developer , it’s normal more than half of the time (not including debuging) spend on testing to cover different cases and benchmark the performance , also test on different environments.
So that there will be less times “it’s working on my machine but not server” .
#7 Time to refactor ,again
I think most of us experienced this. after we refactored , and after some time, we are in another mess , and every refactor there are new bugs come out.
But we already followed and applied what we learned from “clean code” and “SOLID” also “OO design patterns”. what went wrong ?
The key idea of refactoring is : 1. understand the use case (i will explain below). 2. less , change bit at a time because the testing cost is very high (and it become more serious if lead to online issue) . 3. make sure the changes reviewed by others . you may missed something so that others can point out , or your best version is not everyone’s best. we have to prove to everyone, it is worth to refactor for certain piece of code.
#8 “SOLID” everything or patterns everywhere
If you learned some pattern or principle you find it nice and want to use it in projects, please make sure you fully understand the use cases .
I ever saw there is some log object or database connection being created as singleton which caused performance issues ; or abstract factory being used to create every single class object complexed the logic ;or visitor pattern is being used everywhere code became not easy understand even by devs; too much “Single Principle”, many unnessacery classes created ;or too much “object oriented” , very complicated to understand the relationships between classes ,the hierachy is to complicated.
I saw some good ones, like some decorators in python, request filters (chain of responsibility), template method (life cycle) ,”view template rendering” in flask and asp.net and most web frameworks . they are good use cases .
Think of “patterns” and “SOLID” as idea or useful tool, if you like some pattern, instead of change everything , think more on the use case, and it has to be a good match .
#9 I finished my coding and waiting to be assigned another one
Be proactive, always . you can never grow while waiting . when you finished your tickets check the backlogs, or help others review code or add test to CICD. there are always things to be done and make the application better, never wait .
That’s all.
Thanks for reading , happy coding !
