Having pride in your job: the ethics of software engineering

One of the biggest issues currently facing the industry of software engineering is standardization and professionalism . Although there have been some valiant attempts to create means and levels to measure a software engineer by, with no lack of testing in the field, it's still very difficult to exactly measure the productivity and capacity of a software engineer. There is still too much art and not enough formal scientific laws that govern software engineering. Metrics such as lines of code , cyclomatic complexity and code coverage attempt to add "numbers" ways to determine the quality of code, which is the first data needed to measure the quality of the engineer. Unfortunately, they are a form of cargo cult .

Complexity, size of project or size of tests tell little about the quality of the code or the productivity of the engineer, they are measured primarily because they are easy to measure. The ambiguity of quality creates an ethics issue: it is too easy for an unqualified or incompetent practitioner to build a software system today. Worse, sometimes productivity in terms of features and lines of code comes at the cost of technical debt and overall fragility. It's ever easier to do today with productive frameworks in Javascript, Python or Ruby used by legions of "coders" who do not fully understand the issues of security (remember the Target scandal ?), scalability, durability and costs. Worse, these legions don't know what they don't know and often honestly believe that what they construct is the best product that can be and the only thing that matters is speed to the supposed code complete. They move on and the client begins to pay for an expensive firefighting and repair job.

The only heuristic that I've seen work (albeit, not measurably) in the past is pride in work. Someone who believes that delivering a quality system is a reward in itself, tends to produce a better system that someone who believes that the main thing that matters is to produce the system faster. Sometimes they voraciously learn about every software tool available, sometimes they instead focus like a laser on the tools that they have. The main thing is that they want to be better tomorrow at doing their work than today. Notice the difference between being better and faster. That means not just standing up a system to share on Facebook and brag about, but take care of the painstaking details to make sure that it doesn't crash under a load, supports all users correctly, handles failure gracefully and notifies the ops team, scales beautifully, is secure as Fort Knox and the speed of execution rivals a bullet. I call that having pride in your job, being proud of having built the best system possible.

It's the main thing that I look for when looking to hire someone.

This post discussed on reddit.