I had the pleasure of speaking at one of my favorite conferences, Stir Trek in Columbus Ohio. It's held in a movie theater complex and we always watch a Marvel movie after the conference - except the first conference, which was the first JJ Abrams Star Trek movie, hence the name. This blog isn't a comprehensive rehashing of the talk, but I did want to provide an overview of the subject matter.
CORRECTION
I've been informed that my take on auto boxing primitives in Java is outdated and incorrect. I apologize to all my Java colleagues. I do still assert that the POJO approach is a better solution for Java because it doesn't support other value types. I try my best to research everything I present in my talks and I am sorry I got this wrong.
Skip to the bottom if you're looking for the slides and (when it's posted) video.
Introduction
The bad coding practices I speak about in this talk fall under one of two categories, those that are language-driven and those that are created because of the high mental load of doing it correctly.
Language-Driven Bad Practices
While avoiding the holy wars of "well that's not a problem in my language of choice," most languages provide developers plenty of opportunities to write bad code in the three areas I cover: exceptions, object memory management and strings.
Exceptions
Exceptions are an important mechanism in most programming languages. It allows a block of code to signal to its caller that something has happened that was not part of the normal flow. Unfortunately, they often get abused or misused in ways that are detrimental to our code.
Object Memory Management
Most modern languages support runtime automatic memory management. While this lightens the load for developers and prevents countless bugs, it also makes it very easy to add bloat to our code. With some adjustments, improvements can allow our code to scale much more effectively.
Strings
In many languages, strings are a special type of object. They suffer from many of the same problems as objects because of that. An exploration of what makes strings tick
High Mental Load
Some bad things that we do, we do because it's just too much work to think about how to do it better. Of these, I talk about handling nulls, dealing with date and time, and logging.
Not Thinking Enough about Null
Called by Tony Hoare - who is responsible for creating null - the "billion-dollar mistake", nulls are almost impossible to avoid. This iniquitousness causes us to write some really bad code. When we look at null as intrinsically harmful, we start to realize how badly not thinking about null has hurt our code quality.
Time is deceptively complex
Because time is so intuitively transparent to us as humans who live in time, we don't spend nearly enough time analyzing the impact of time on our programs. Understanding how bad design where time is concerned can cause issues helps us build better systems.
Logging shouldn't be an afterthought
We all use logging, but for many it's an afterthought. We arbitrarily add log statements in our code, only add logging when debugging in the test environment, or build complex queries to create metrics after the system goes to production. Having a plan gives better observability and helps us understand our code better.
Conclusion
The session is pretty densely packed, but I put a lot of love in to trying to get the right level of detail for the format. Please let me know if you have any suggestions for future iterations of this talk.