Tuesday, June 25, 2013

The Art in Value

One of the challenges in a creative profession is managing the perception of your “value” including the work that you perform, the objects that you create, and the temperament that you nourish. These are truly three independent metrics.

Due to the demands of the profession and its continually advancing technologies developers tend to dwell more on what they already know (or what they need to learn) rather than focusing on how others perceive them. As software development is both an art and a vocation however, it is important to pay attention to both your internal qualifications as well as the perceived external value that you add to your job.

The value of your physical software development opus is fourfold: it may provide a revenue stream by itself, it may tender “goodwill” to customers and draw them in to purchase other products, it may offer cost savings as the business operates, and finally it may give a strategic advantage by opening new markets that create unique services.

The value of the product you help design is a separate matter however from the value of the actual work that you perform. Somewhat impishly, you can lead a project that creates the next YouTube and still only get paid like a system designer. Your employer compares your base salary to that of any other developer they could hire off the street. The cost of a foot of electrical wire inside a jet plane is the same even if you only use it to connect your power outlet to your reading lamp.

But now let’s consider your actual value as viewed by your employer. This is a more nebulous quantity that relates to a host of factors, many of which are strictly outside of your vocation. Are you a healthy employee? Then you add value by your contributions to the company’s medical plan. Are you cheerful and easy to work with? Then you add value by improving the morale of the workplace. Are you a good mentor? Then you add value indirectly through improving the productivity of others.

As a professional remember not only to stay sharp on your skills, but also to pay attention to the art in your value.

Wednesday, June 5, 2013

The Art of Debt

I am often surprised how frequently developers fail to make database modifications simply out of laziness. Say you have a customer identifier for favorite color, and the values tend to be either blue, yellow, or red. Now say you add a new attribute to a customer and this attribute only applies to one existing subset that already exists.

Say only customers who put red as their favorite color also like beets. Should you add a new field (named beets) or should you split the "red" values in the existing field to "red likes beets" and "red dislikes beets." All too often I see folks go down the path of trying to squeeze additional information into the existing fields, "red likes beets."

Sure this requires changing less programming logic immediately but it also builds up "technical debt" by increasing the analytical complexity in the future. In short it trades elegance for immediately impressing the boss.

And this really gets to the crux of the matter in the Art in software development: do you shoot for pleasing the boss, or do you aim for a pleasing future?