5 principles for creating stupidly brilliant JavaScript applications

Have you ever tried to add a minor feature to your application only to discover that you’ll have to re-write large blocks of code first? Or maybe you’ve spent hours deciphering hundreds, or perhaps thousands, of lines of existing code just to find out a task only required two lines of additional code. If you’re like most developers, you’ve wasted countless, frustrating hours wading through immensely complicated code trying to force it to do things it wasn’t built for.

In his presentation, Mike Manwill, Frontend Team Lead here at Smarty, discussed 5 principles to help you create stupidly-simple applications that are maintainable, extendable, and bug-resistant. He calls it “writing stupid code”.

“If you can’t explain it simply, you don’t understand it well enough.” - Albert Einstein.

Mike explained that “smart” code is “dumb” for several reasons. It is difficult to read and understand, making it difficult to hand off to predecessors or other coders on the team. It is bug-prone, and debugging can be very very difficult. Extending it becomes time-consuming and difficult, especially if you’re not the one who authored it. Estimating work needed becomes virtually impossible if your code is too smart. And finally, it tends to have a short lifespan and needs to be overhauled frequently because it can be so frustrating to work with.

Aside from spotting those challenges, there are five other symptoms of “smart code”.

1. Your functions take lots of parameters
2. There is a lot of conditional logic
3. You need to explain your code via commented code
4. Brittle code (it breaks every time you change it)
5. The code is difficult to follow

So, we’ve identified the problem. You’re tired of being frustrated with this “smart code”. How can you make it better? For the main part of his presentation Mike went over the five principles you can follow to create brilliant “dumb code” that lasts.

1. Take time to really understand the problem
2. Decouple different ideas
3. Pass the thing instead of the parts to build the thing
4. Refactor (just because it’s working doesn’t mean you’re done)
5. TDD (Red, Green, Refactor)

You can watch the video recording of his session (super short, only 28 minutes!) and see his examples and explanations first hand by clicking the button below.

Try our stupidly brilliant address validation and address autocomplete tools. You can sign up for a free account by clicking the link below.