What goes through my mind while writing a function 😵
Tags: javascript, coding, personal, webdev
Published: 2019-01-23 17:35:42

---
title: What goes through my mind while writing a function 😵
published: true
description: Writing functionality is tough. But the good kind of tough!
tags: javascript, coding, personal, webdev
---
I don't think a week goes by without me writing a function. Often simple handlers to modify a piece of state or format a bit of data. Sometimes something more involved, and occasionally up to the point I feel like my head is about to explode. 

I've written one-liners, hundred-liners and probably way-too-many-liners. But no matter how many times I do it... each time I write a function, I keep stumbling upon so many questions.

**For starters:** _do I need to write this function at all, or might I have a helper laying around that pretty much already does what I need?_

As apps grow, there's a big chance the functionality you seek is already (partly) there. Either through your own great work or through a library that hides somewhere in your `package.json`.

But maybe it's not there, or you feel you can do a better job. And you promise yourself you'll create the one function to rule them all... Often for me it goes a little like this...

_Do I begin with a test?_ The internet tells me to work test-driven. And to be fair, they make great points. Still, I might lose the energy and momentum I have. Because if I have to write a test, I would need a few moments to think and recalibrate my mind to think in tests.

## We only want the pure stuff
Okay, let's forget the test for a moment... I can do that later. _Do I make my function pure?_ That would be for the best right. It will help when I am going to write the tests, and maybe I could even reuse the function somewhere else.

But now I am writing the function I notice myself referring to `this.state` and `this.props`. It just quickens everything, and you know what, I can always fix that later.

I even find myself using `new Date()`. Okay, let's take a little break.
Maybe I can cut up the function in smaller pieces. Some of the stuff I'm writing can be pure and modular, while the rest of the function can be a bit like an impure container giving out the orders. That seems good.

Now I'm starting to get really smart. I have smaller functions calling each other returning beautiful predictable results. I write a few unit tests for them... I am on a roll. Let's try and get even smarter. I remember I have a few other functions in the app that will definitely benefit from some of the stuff I have just written.

## Enter the genius
Let's hook those up to my small functions and start abstracting!

...abstracting
...abstracting
...abstracting

I am done and feel exhausted. Great work right! Right...? _Or was I being too smart?_

Suddenly I remember that some of the extra functionality I just hooked up might be revised in the near future. I definitely heard the others talk about that. Does that mean I have to edit my abstractions? Exceptions in abstractions. I know I don't like those.

Already I'm getting nightmares of code that's so sophisticated I don't understand it anymore. How will I delete that one piece of functionality that no one ended up using, but is now tied up into all my genius?

I revert like a madman and am back to my one single function. Duplicated logic means less dependency and easier deletion. Travel light, right? That's what were going for!

## Doubt creeps up
But then again... what if this very simple piece of logic that's spread across the app in three different shapes needs an update because we decide to do things a little different with the app. Am I not going to miss one place where I should update it?

Again, the questions and scenarios keep coming up.

Unlucky for me, the future doesn't reveal itself. What I prepare for might not happen, and what I think will get back to later, could become the problem of another person.

So I remain with a lot of questions. I decide to write the function step-by-step, documenting my choices. I try to be aware of the context, but don't let it cripple me. It won't be perfect, but that's fine. Non-perfect code is easier to replace or delete. Let's just aim for what works and what is understandable. We make progress, and we try to have fun with it.