Sign That You’re A Good Programmer

Programmer Job InterviewWhat makes a programmer good at their craft? For years, organizations which hire programmers have reasoned with this question. Yet, the criteria for selection of a “good” programmer differs by the lot. As candidates, most programmers are put through tough technical interviews, grinding analytical tests, and twisted coding sessions. Employers also review attributes like past work experience, skill-set, education qualifications, references etc. With all sorts of characteristics to gauge, it becomes very difficult to recognize a good programmer, let alone to hire one.

After reading an article titled ‘Signs that you’re a bad programmer‘, I thought hard at what makes a good programmer. No wait, let me rephrase that, for the reason that everyone (including yours truly) is marginally horrible at programming. It’s a craft that takes decades to excel, if not to perfection. So the real question then is, what makes a programmer less horrible?

I have been interviewed for job roles, and I have interviewed other people on occasions. I’ve also been gracefully delegated the awkward task of firing a programmer. To my comprehension, following all these years as a programmer, the most reasonable sign that you are a less horrible programmer is your ability to build stuff during your spare time that serves a utility or solves a problem (maybe your own). When programming becomes a hobby, and as side-projects start taking shape, you’ll start getting marginally less horrible. Even better if those side-projects are collaborative.

This inherent trait shows that such programmers are passionate about the craft as they indulge in “extra-curricular” problem solving. An ad-hoc practice with a variety of small projects also improves the quality of work and estimation accuracy. This skill of utilizing time for 20% of the causes is what makes a (talented) programmer less horrible. Moreover, when you are both the teacher and the student, you’ll find it easier to surpass any illusory superiority. Programmers who strive for a process of continuous learning through self-teaching can be distinguished much easily than with conventional steps of recruitment.

The Cross-Platform Enterprise Lore

It’s a known assertion that software applications (desktop or distributed) are not truly platform agnostic. Even if a software application is developed as a cross-platform solution, it is very difficult to make it look and work identically across all platforms (operating systems). Hence, lately I’ve been thinking about the quest of cross-platform software applications in the enterprise landscape.

Brian Clapper recently wrote why C# is now a better programming language than Java, and yet, why he still prefers the JVM to CLR:

Sun and the Java community have allowed Java, the language, to stagnate to the point where, compared to C# and Scala, it is almost painful to use.

Brian’s viewpoint is a sign of the times. A lot of Java programmers consider(ed) C# to be an inferior replica of Java, and hiked Java to be enterprise-centric and cross-platform as opposed to C#. In fact, C# (like Java, and other object-oriented languages) is based on C++. For the past 8 years, I’ve been programming exclusively in C#. I’ve consulted in Java solutions before, but sooner than later I realized that C# is abundant and flexible enough. Back then, many Java developers sighted it as sheer marketing by Microsoft to lure developers. I agreed, it was, more so because Microsoft did a better job at designing a modern OO language and a decent IDE to go with it.

Behind the C# versus Java debate, also lies a ludicrous assumption for a programming language to serve enterprise application software in a cross-platform environment. It has to be the most common notion I’ve heard time and again from Java developers and evangelists. However, the lore in reality is quite different.

Enterprise Software

Let me ask you, have you ever developed a business application with the purpose of it being deployed in a multi-platform environment? How often do you think an enterprise application software is required to be implemented across platforms? Rarely, maybe less than 1% of the times, unless it’s a niche system for disparate platforms or legacy components. In context of an average enterprise application software, the fact is that cross-platform support is not a requisite. In a very large organization, the stakeholders don’t really care about the cross-platform aspect of an average software solution. With a few hundred or thousand seats in their dispersed infrastructure, enterprises formulate strict guidelines for their base software installations across the globe. Workstations and servers in these giant corporations run a rigid set of base software (including OS, database, Web etc.), so they already know their target platform. And, if you have a single base platform to support, whether it’s Windows or Linux, enterprise application software gets a bit easier. It’s a perplexed undertaking to build a cross-platform enterprise application, due to the complex nature of technical disparity across systems, and issues associated with cost, maintainability, testing, training, and of-course time.

Google released its new Chrome Web browser, but only for the Windows platform. For the past few months, they have been working on an “identical” version for Mac and Linux, but it hasn’t been a straight-forward approach. It’s just a Web browser. Think about a much more intricate supply-chain management system that must deal with external hardware interfaces, system API’s etc. In 99% of the cases, it’s just not feasible to build a cross-platform software solution in the enterprise. So, when cross-platform support is not an issue for enterprise developers, the architecture choices are suddenly simplified. For everything else, Web applications and SaaS model have already opened doors for business solutions to be ‘hosted once and run everywhere’.

Java is a mature language. Enterprise solutions in the yesteryear’s relied largely on Java and J2EE. Enterprise solutions today are increasingly being built on C# and the .NET Framework (or Mono). The whole idea of interoperability in enterprise apps is irrelevant in my opinion. What really matters in a programming language or technology stack is not its feature set, but its ability to produce results with minimum efforts.

The Whitespace Pattern

The other day I wrote down this Haiku out of disappointment:

With a necktie in January:
Erratic spacing at the end of lines
Heedless programmer continues to code

Disappointment that came from recently inspecting gallons of ruthlessly written source code. The business logic, coding standards, and refactoring aside; I was baffled foremost by the actual code formatting.

If I’m managing code that someone else wrote, I would expect to reach the end of a line when I click the ‘End’ key on my keyboard. What I don’t want is to land at position 542 of that line, with just whitespaces in between.

Don’t get me wrong, you need indentation and line-breaks to keep your code readable and easily maintainable, but you definetly don’t need excessive horizontal whitespace within or at the end of each line.

Excessive whitespaces at the end of several lines of code, just goes to show how unimportant that code is to the original writer, unless that code was written in an esoteric programming language like Whitespace!

In some ways, code is poetry. Ignorant programmers don’t understand that others may review and even maintain their “poetry”. If you don’t format your code, I would highly recommend (and request you) to start doing so by keeping your code clean, concise, and commented. Consider this advice as a ‘design pattern’ for respecting your own code.