Remembering how to KISS

Developers love to experiment. There’s always something we don’t know, and we have a constant desire to play with the latest tech; ensuring we’ve figured it out and are keeping those skills razor sharp. This post is a way of reminding myself of the quagmire that is learning new things.

The issue for today’s developer is that the day to day targets are moving so fast that it can often be a struggle to find time. And when the opportunity does arise, there are two very common scenarios:

1. File->New Block

You’re excited, now is the time, you’re going to add that package you’ve had on your research list for weeks and break the back of it. You crack open your IDE, open that first document and….what now? Where do I start? What am I going to write to really harness the power of this? Sure I could write Hello World or crack open another todo list app. But that’s not COOL!

New app then, what back-end is it going to have? Do I want to go NoSQL for this? Hmm…what about dependency injection? I could bundle it with that new container I was looking at. THAT is cool! Two birds, one stone, now I’m winning. What test framework should I have? Could I go for three birds and try out that new test runner? hmm…

This sounds like I need to tackle it when I have a little more time…what’s that? A steam game on sale? Fabulous!

2. Demo Code Overload

You found it, the grail, the sample that explains everything, shows details of each operation and the way it can be used in conjunction with other areas of the framework! Just look at this beautiful code, it’s so easy to…to read…and…ooh, what’s that for? I haven’t seen that before…oh I see that hooks into…WOW! That whole namespace makes it all so much easier, what an improvement, and that hooks into the UI somewhere. It has to. Where does it…Right, let’s close this down and open up that one and…there? Possibly. If I can just figure out how it hooks into the UI, then I can use that new namespace in my method and after all that I’ll…

…What was the one thing I opened this sample for again?

I’m sure we’ve all been there

And this is the problem, we’ve probably all been in one or both of those scenarios in our time – but there’s so much shiny we do it again and again. We always look at the opportunity with good intentions and become waylaid at some point. And the worry is that if we allow it to happen then that becomes an annoyance – and not at ourselves, but at the code, the sample, the lack of “good” samples, you name it, because it can’t possibly be that we looked at the pool of new learning and cannonballed into the deep end without checking.

So what do we do?

Keep It Simple, Stupid

It’s an easy thing to say, but I’ve just spent quite a long period of time and more words than I’m used to explaining how simple is exactly what it isn’t. So how do you take something that appears to be dangerously overburdened with information and KISS.

The only good sample is YOUR sample

Write the sample code. But careful – because I don’t mean the sample code for the new shiny. Yes, I know it’s sitting there beckoning – minimize that window!

The easiest way to KISS is to make yourself a sample that you know inside and out. Something you’ve written that, when you commit version 0.1, is going to be functional but basic. Something you’re going to enjoy. Pick something you can build on, a new personal website, a desktop application for handy dandy utilities, that little app you’ve always thought would be fun. It doesn’t matter what the subject is, but you have to OWN it.

Then you commit it. That’s your master branch. That’s the one you never taint with unknown entities.

New shiny comes along? Branch your sample and start adding the new shiny to it. Refactor that page, optimize that process, work the shiny into something you know and love little by little? You might not be able to understand the Demo Code Overload, but I bet you Stack Overflow can help you with those first three lines. Then you can figure it out for a while after that, keep going, you understand it by compiling and testing and compiling and testing with something that is 100% yours, you can tell instantly if it fits because you’re pushing it into a frame that you created, that is your way of thinking and you instinctively know when that doesn’t sit right.

But what happens when it works? When your sample is better than it was before? When you’ve (partially) rebuilt it, what happens when YOU have the technology?! I know it might seem the wrong thing – but for all you hold dear, resist the urge to merge your branch straight back into master. What you’ve done is put a new component into an old machine, and it’s new, so it’s better for now. But you don’t know if you’ll like it, you don’t know if it will work long term. Revisit the branch, tweak it, learn from it. But keep the master sample clean for the next thing, and the next, and for the shiny after that.

If a little way down the line you come across another shiny, and you crack open another branch, and as you open that project you shudder and go “Now why on earth am I not just doing [insert previous shiny tech here]? This is a lot of hard work for the same amount of effort!”. That’s when you take the time to merge the branch in. When the technology has had those rough edges sanded down and you feel comfortable, then you improve your baseline, because for every one you merge, there are going to be several that you don’t.