Manju

Greetings! "I have done my work. I'm taking another ticket." "Can we close this ticket end of the sprint." "Why is this ticket still open." "We need to work extra and close these tickets." Those are only a few phrases. If you have not heard those words, congratulations!! you are working in a super nice environment. Unfortunately for most, these are daily sentences they encounter. The definition I'm using this term for anyone, be it an intern, architect, manager or anyone whose main target is to close the ticket by themselves or by forcing others. They do not focus on, do not allow code improvements. Why do they do it As I can't read minds, I don't know. However they may be targeting big paychecks, promotions, praises, etc by showing they are very efficient, committed, etc. However they are just moving from one ticket to another. How do they look like Lazy to learn Do not understand the value of good code No proper use of design pr...

Greetings! While I was reviewing a code, I noted that there is a Sonar violation saying not to use HashTable. Which is correct. Also it suggested to use something like HashMap instead of HashTable. I reached out the developer and asked to remove the HashTable but she said that use of HashMap did not work. Also when I asked why did you use HashTable at first place, the answer was legacy code expects it, hence for new code we need to add HashTable. Let's see how we can solve such cases.  Problem First of all we need to understand why these kind of rules exists. Our codebase is very old hence we have lots of deprecated class usages. Former developers have used whatever the API available those days. As a junior developer you need to understand, learn that classes like HashTable, Vector should not use in modern codes because those are synchronized. You need to replace those with modern APIs. Hashtable<Integer, String> ht1 = new Hashtable<>(); Problem... Again One of thos...

Greetings! I have been using SonarQube as a quality tool for quite some time now. It is used for continuous inspection of code quality to perform automatic reviews with static analysis of code to detect bugs, code smells, and security vulnerabilities. Eventhough the intention is to detect issues, top level managers, architects, etc use it to measure team's working quality progress in their visual boards. As they are usually busy people they will not have time to look into real code and to see the real issues there. What happen then? developers will start to write "sonar satisfy" codes. I have seen very unreadable bad codes with zero sonar quality issues. And also there are good quality codes with some unnecessary sonar issues. Reason for that is it can detect prefined rules but not all design flows. If you want to be a good developer, don't try to write "sonar quality" code, instead use "clean codes" and get the Sonar support when necessary. Let...