Being An Elegant Business Programmer

11 September 2011 | talking about Programming

“I am a Java programmer.”

“I am an object oriented programmer.”

“I am an agnostic programmer, I can program anything.”

“I am a mobile programmer.”

When talking to software developers everyone is something. Today I am going to reveal what I am, creating a new category of programming, a completely new bucket of organization. Drum roll please.......”I am an elegant business programmer”.

computer geek image

Being Elegant

Ok maybe EBP is not the best name, I will work on a better one. For now, though, let’s define what it is. First let’s analyze the “elegant” part. Code can be a work of art or a tangled web of craziness. I consider code elegant if I can read it as I would a book. A well-written book reads smoothly, and uses words wisely to lead the reader along with the plot. Unnecessary wordiness may drive readers away. Similarly, with software development I should be able to start at the top of a file and read through the entire code at a consistent pace, not getting hung up on any section in particular, and not being flooded with unnecessary terms.

An example of “not so elegant” would be a 10 line sql statement just to return back a perfect sub-set of data, when a “Select *” would have done the trick. That 10 line statement often will cause someone reading the code to stop and spend a great deal of time dissecting. I am sure that block of sql took 100X longer to write then a simplified version that might have returned a little more data. Furthermore, that block of code is very hard to maintain and debug in the future.

I know what people may respond to the statement above with “performance is better with the ugly block of code”. You know what does not perform well? Software that never launches. Or software that launches with tons of bugs. Every performance decision should be made on “will my users notice the difference”. They will notice bugs. They will notice it takes forever for you to release new features.

Be a knowledgeable programmer: recognize when there could be better ways of doing something. However, when software is young, a focus on elegant, maintainable, bug free software is a far better approach.

Naming conventions: keep them readable. Anyone that has ever read my code will notice I use longer and more descriptive class, variable, and function names. Remember: your code should read like a novel. Don’t make your names so unreadable that no one can understand your code. Both Objective-C and Ruby have gone to great lengths to make naming conventions understandable. I try to follow suit.

Another less than elegant approach is being tough with your typing while you program, particularly in scripting languages. I really get annoyed when I see classes riddled with private and public restrictions. I really get annoyed when people go overboard with making sure every variable is typed just perfect. Yes, in some software this stuff really matters. In web scripting world this stuff does not really matter. It just makes you an OCD, control freak programmer.
 
Read the rest of this entry