LSD - The secret to coding

What would you say if I told you that the secret to coding was LSD? When you stopped having a conversation with the floor lamp and finished freaking out about the pink spiders in your hair, you would probably tell me that I was mistaken. However, I don’t mean d-lysergic acid diethylamide, aka “acid”. I mean a slightly different meaning for this initialism.

Instead, I mean LSD in the following context:

• Logic
• Syntax
• Data

Let’s explore each one of these in detail.

Logic

This is the hard part. This is what people fret about when it comes to programming. Are the instructions you are giving the computer going to achieve a successful result? Is that result repeatable, given the same data? Will different data achieve a successful result? Have you flowed from each step in a logical progression?

These are all challenging questions, and are what provide the daunting obstacle to most people embracing coding. Bugs happen, though. They are arguably unavoidable. That should be a reason for you not to enjoy the process of communicating a solution to a problem to a computer.

Logic is also where we do the vast majority of our debugging. Questioning assumptions is part of being a developer. However, the logic of how we process data doesn’t change from one programming language to another. The step-by-step process of getting the computer to work through your solution is relatively constant. Some languages may have a more streamlined process, some may require more declarative or more imperative programming steps, depending on the idiom. But the logic still doesn’t change. Ultimately, even if you are building OO applications or using functional programming, your solution contains the same steps. How you have constructed the program flow of those steps can vary.

Syntax

Have you used the right methods to enact your logic? Did you remember all of your commas, parentheses, curly braces, semicolons, or other syntactic characters that communicate meaning and functionality? When checking syntax, this is when it is always important to remember issues of capitalization, pluralization, hyphens versus underscores, and (if you’re in Python) whitespace.

Fortunately, syntax is usually the easiest problem to solve. Most parsers/compilers will throw an error when they encounter an invalid syntax. Typos are usually easy to spot thanks to syntax highlighting in editors and method lookups in IDEs.

Unfortunately, syntax can’t help faulty logic. Make sure you know what a method’s return values and expected parameters are. Understanding synchronous versus asynchronous methods means you are sure that your logic is running in the order in which you intended it.

Data

Last, but arguably most important, is data. Data is product. Do you have access to the data you need? And, is it in the format you need and/or expect? If the answer to either of these questions is no, then it doesn’t matter what your logic or syntax are doing.

Ultimately, products that you build are designed to either consume, manipulate, manage, or produce data. It is imperative that you are comfortable with the data set that your code is using, and make your logical decisions based on that knowledge.

Summary

The initialism LSD is great, because it evokes a chuckle. The truth is, it should probably be in the order DLS, because as a programmer you’re going to start with your data. The knowledge of the data you either have, or need, is going to inform your logical flow of steps to go from problem to solution. So, you will always progress from Data to Logic. Then, and only then, will you implement Syntax to apply the logic.

Additionally, data is usually provided, whether in the form of user input, access to a database, or from an external API. Logic is where the programmer will do most of their work, and the innovation happens. The logic, as discussed above, doesn’t change regardless of which programming language you are using. That means that everything else is syntax, which is easily research-able (Google-able, in most cases). This becomes a strategy for rapidly becoming productive in new languages and frameworks.

As a debugging method, as a workflow for approaching the development of a new feature, or even as a teaching tool, the LSD principle of programming is incredibly useful. Try it out the next time you have a problem and let me know how well it works for helping you to solve your bugs.

---

If you have any comments or questions about this post, please feel free to shoot me an e-mail at don (at) donburks (dot) com. I would love to hear from you and continue the conversation.