loading...

Stop writing silver bullets

adam_cyclones profile image Adam Crockett ・1 min read

When I create a library / abstraction, it's usually quite small maybe around 300 lines, it's purpose should be singular, and everything around naming, methods and public is considered, I do no more than I need too, I will attempt to be quite generic, and so you would think this must be reusable?

I find more and more that my code is reusable, I know because I do reuse it, but actually it's only chunks that I need from a previous solution, rarely will I need everything and often 50% gets cut. This got me thinking, if code should be reusable, why do I have to cut code?

I think I may have a form of overengineering addiction where my solutions are not actually focused enough. Why write a SVGCurve maker and it only does that, when you know what your making further down the line is more specific. The generic SvgCurve maker does need to make calculations that the consumer library could skip because part of the calculation is already known. The generic solution then needs to allow for overides to bypass the calculation... But by now, I'm thinking what's the point?

There is no silver bullet, perhaps keep your functions pure, calculate before you pass values in, just return values out, be focused and maybe this means less cut code.

End of streaming consiusness. 😴

Posted on by:

adam_cyclones profile

Adam Crockett

@adam_cyclones

I work at ForgeRock as Staff UI Engineer, I play with all sorts really. Lately WASM is my toy of interest.

Discussion

markdown guide
 

I think the UNIX philosophy is a great guide here, especially if you follow a functional programming style. Can you throw your library method into the middle of a pipeline (under reasonable circumstances) and have some degree of confidence that it is going to work? If not, you are doing too much or have too many side effects in your code.

I am going through some of the same thought process as I write Vue components for my blog. I keep getting tempted to expand certain components to handle special cases, and then I have to remind myself these are for my blog, there are no special cases, I'm just procrastinating and finding excuses to delay going live.

I personally have discovered overengineering is my favorite form of procrastination. It looks like I am doing something noble and thoughtful, but really I am just scared shitless of showing my code to the world and seeing if it works or not.

 

That's a very honest administration at the end and I feel the same way. As for Vue again I feel the same, is it because Vue under the hood can handle a hell of a lot. I want my stuff to be the 'best' even if 30% of that 'best' is actually used.

Use restraint and lots of it. What's interesting is that overengineering and future proofing which is the same word is proactive, which sounds good in a developer world when being proactive is better than reactive. But counterintuitive as it sounds, it's not good at all in code, very strange.

If I put an analogy on this situation, there is a bunch of roadworks outside my house, I can't park and it's really making life truly, today they put a sign up giving details of the reasons for the work. The work lasts until October 2020 and the reason is future proofing, it this point I swore at the sign and walked off. Nothing has happened, something might happen and they are investigating time to disrupt everyone for no reason.