Search This Blog

What does your programming language of choice say about you?

Many people in todays development word say "the language doesn't matter, only the results". I find a lot of fault with this logic, as certain languages really teach you to think very differently. If you've ever seen a Java developer try to program Python, you know exactly what I'm talking about.

Developers are trained to think a certain way; some languages focus on Class-based workflow, some on function-based workflow. Some focus on asynchronous development, some are procedural, some are event-based, some are function-call based. The point is, the language you prefer says a lot about who you are as a developer simply because it defines how you program.

I've written down a few of my observations, but please feel free to contribute. If you come up with something very useful I'll add it to this post!

Again, this is not a "people who know X" generalization, it's a "people who prefer X".

Python

This is actually my language of choice, so I'm a bit biased. Python developers tend to "fly by the seat of their pants" so to speak. The python programming language is a scripting language, and usually draws in developers that aren't into big amounts of requirements gathering. You'll rarely find a lot of unit-tests in python projects. Python developers tend to move very quickly, making mistakes but often designing to recover from errors. You'll often find a lot of error-handling in Python code since errors are really expected to happen.

Ruby

Ruby developers tend to love documentation, and not be nearly as focused on speed. Documentation is so strongly encouraged in Ruby that often it takes much longer to install the documentation then the project itself. Most "Ruby" developers are actually "Ruby on Rails" developers, and more and more features that are really designed just for Rails are merged into the core Ruby system. Ruby is also a scripting language, so ruby devs tend to move fast and expect errors (just like Python developers). However, Ruby is entirely object-based, so Ruby developers often build very OO systems. This makes for a much more readable code-base, but doesn't necessarily make the fastest or best system. Ruby developers often rely on "monkey-patching", where simply importing (or requiring a module changes core functionality of the language.

Java

Java developers are completely the opposite of Python and Ruby developers. Their primary focus is on documentation before building, and most focus on Test Driven Development (TDD). You'll find many enterprises in this class since Java development often involves a lot of prep work and design before any coding is started. A typical Java project moves at glacer speeds, and you'll find it requires many more developers to build a java application. Java developers also tend to focus on Deployment schedules instead of relying on continuous integration. You'll generally get a very reliable system, but often by the time it's completed it's out of date. Java developers tend to freak out when requirements change.

C/C++

C and C++ developers are typically hard-core speed freaks. C is a much lower-level programming language, so it is incredibly fast, but also the most complicated to develop. It usually ends up in much harder to follow code, but the optimizations it provide can result in some very fast performance. C developers are usually even slower to complete a project then Java developers, since they have a lot more to manage (Memory management, low-level algorithms, variable types). C developers usually don't rely on pre-built frameworks, and often don't use a lot of external libraries. I've also never met a C developer that was sane.

Objective-C

In today's market, Objective-C developers are synonymous with iOS developers. Typically these are people that really keep up with current technologies as they are rapidly changing. Most Objective-C developers hate themselves, as they have to learn an almost entirely new language every year. These developers tend to move slightly faster then C/C++ developers, but not as fast as Scripting language developers. They tend to be similar to Java developers, but often focus a lot more on User Experience. Since Objective-C is based on C, you'll often find some bleed-over of C/C++ developers too.

HTML/JavaScript

Similarly to Ruby and Python developers. HTML/JavaScript developers tend to fly a little faster then other programmers. They almost never rely on documentation or tests, but instead rely on "feeling" and general non-measurable metrics to determine the success of a project. They do tend to rely more on requirements then Ruby and Python developers, but they often gather these requirements themselves, instead of having them dictated to them. These are much more visual people, and they tend to focus entirely on a snazzy UX. They are religious about browsers and technologies, and tend to hate other types of developers. JS developers even made their own way to run JS on a server, Node.js, so they don't have to ever touch other programming languages. JS is event-based, which means they are reactionary. They love making their customers happy, and generally do so with snazzy looking features.

Popular Posts

Ever wonder how sites like battle.net support things like this in Google Chrome?

Well I did, so I did a little bit of digging. It turns out Google Chrome supports an open standard called Open Search. This format is relatively simple, and very easy to add to your own site. I just added it to some of our systems in under 5 minutes.

Adding OpenSearch to your site is incredibly simple, you just have to add a simple tag to your index HTML page, and add a simple XML file that it points to. The link tag looks like this:
<link rel="search" type="application/opensearchdescription+xml" href="http://my-site.com/opensearch.xml" title="MySite Search" />

For a while, I have been creating command line tools provided right with boto which I used to manage AWS. Recently, others have become interested in these tools as well, and I've seen several other contributors adding to these tools to make them even more useful to others. One recent submission by Ales Zoulek added some nice features to my list_instances command, which I use on a regular basis to list out the instances that are currently active for my account in EC2.

Amazon now lets you add Tags to EC2 objects such as Instances and Snapshots. This allows you to actually "Name" your EC2 instance, as well as add some metadata that could be used for AMI initialization, etc. Ales added the ability to list these tags by name within the list_instances command line application:

Last week, Amazon announced the launch of a new product, DynamoDB. Within the same day, Mitch Garnaat quickly released support for DynamoDB in Boto. I quickly worked with Mitch to add on some additional features, and work out some of the more interesting quirks that DynamoDB has, such as the provisioned throughput, and what exactly it means to read and write to the database.

One very interesting and confusing part that I discovered was how Amazon actually measures this provisioned throughput. When creating a table (or at any time in the future), you set up a provisioned amount of "Read" and "Write" units individually. At a minimum, you must have at least 5 Read and 5 Write units partitioned. What isn't as clear, however, is that read and write units are measured in terms of 1KB operations. That is, if you're reading a single value that's 5KB, that counts as 5 Read units (same with Write). If you choose to operate in eventually consistent mode, you'r…