Managers! Don't use developer metrics.
I love technology and everything related, from gadgets to new professional techniques. I like thinking, researching, optimizing, inventing and developing. I have a strong background in software research and development, operating systems, Voice-over-IP, network security, wired and wireless network engineering, complemented with electronic engineering background.
My career goal is to always keep learning, to be challenged, and to work remotely so I can be present for my family.
Bug hacker and master troubleshooter, my strength is understanding a problem and getting to the root of it. I'm mostly a self-taught individual and a constant learner. I push my technical boundaries daily and search for ways to improve my skills every day. With over 20 years of experience writing software in various languages, creating or optimizing algorithms, the digital development world is my turf.
Sample challenges which I particularly enjoyed:
- Created a GLSL based magnification tool for a client who was turned down by three other companies as "impossible to do on macOS".
- Optimized several SQL queries to reduce load time of a particular web page from several seconds to sub 50ms.
- Identified the root cause of stuttering animations in iOS mobile app and implemented mitigation strategy
Specialties: Swift, Objective-C and PHP Software Development; TCP/IP and Wireless Network Engineering
I read an article on LinkedIn titled "What code quality metrics should you track to improve your programming?"
When management attempts to qualify the quality of their product and development processes, they often look for existing metrics to inform their decisions.
Unfortunately...
Most automated code quality metrics should not be utilized by management. The number of "issues" discovered, or the complexity of a function, are metrics intended for developers themselves, to help steer their work.
In many instances, these metrics rely on false positives. Unless your team consistently reviews issues flagged by the automated tool, a significant portion of the identified issues will be false positives. Likewise, the tool will probably overlook more substantial concerns, such as excessively complex architecture.
The metrics that matters the most are:
How long it takes for a new programmer on the team to understand what the code does?
How happy are the developers working on the code base?
By focusing on reducing the amount of time it takes to onboard a new developer, you are indirectly making the code easier to understand. Code that is easier to understand inevitably leads to fewer defects.
Focusing on making your developers happy leads to greater productivity and less turnover.
Finally, if you really want to focus on producing quality, look at the customer/user reviews.
