08 January 2017
I primarily focus on code as a communication tool between programmers, even when I’m just writing code that will only be read by my future self. It’s a set of machine instructions secondary to that.
So how does that translate specifically? Developer Ergonomics.
I like programming languages that are expressive where the designers have created sensible, elegant interfaces. I like a community that encourages documentation, including expressive testing. Lowering the barrier to creating documentation and tests, and making those habits, are key to lowering the barrier to entry in foreign projects and languages. For me, these are Ruby and Elixir and their communities.
I don’t care as much about raw speed from a language when it comes at the cost of clarity or simplicity and I am willing to make that sacrifice. Developer hours reading and writing that code are much more expensive than the hardware it runs on.
I also don’t care as much about finding the “one right way” to do something or arguing about which way is better. If a solution is objectively better, I’ll happily drop the old one in favor of the new one. However, this decision should be made more on a per-case basis depending on business requirements rather than on rigid rules. I like having more than one way to do things, and at least one “good way”.
I like using a programming style that fits the business need and mental model best. Sometimes, this is Object Oriented Programming and sometimes Functional Programming lends itself better to the task at hand. The more I learn about Functional Programming, though, the more I like using it to solve problems.
For me, it’s about developer ergonomics. I want it to be easy for developers to write tests, code, and documentation and my technical choices tend to follow this philosophy. However, these things only represent one layer. Developer ergonomics is not something I expect upper management to value because that’s not their world and not a framework they have to think in. So, I’m happy doing what I can, working to meet the needs of management and the business while leaving behind documentation, trains of thought, and tests along the way.