9 Important developer mindset can not be learned from books

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

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

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

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

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

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

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

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

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

That’s all.

Thanks for reading , happy coding !

--

--

A channel which focusing on developer growth and self improvement

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
LORY

A channel which focusing on developer growth and self improvement