Thread by @BandaWorks

#BandaDaily #1:

When #coding something, always approach the problem iteratively.

That means that as #developer you go through roughly 5 stages:

1. Make a straightforward solution
2. Cover edge cases
3. Improve the performance
4. Improve the design
5. Reduce complexity

🧵👇

1. Make a straightforward solution

It's the basis of your work: it's rough, potentially inefficient, and may not work in the edge cases.

Copy/paste here instead of creating complex reusable components.

Here's the goal to create something that actually works, but not perfect.

As a junior engineer, you should be able to come up with at least one such solution, after thinking about the problem for a while, researching, and discussing with more experienced engineers.

If you still can't, the problem requires more expertise than you currently have.

In that case, I recommend sharing it with your team and ask for help from someone who has relevant experience.

Your colleague may show how this problem is solved on a whiteboard or through pair programming.

You'll learn this way and prove to your team that you are reliable 🦸

2. Cover edge cases

Sometimes, your initial solution is already solid enough. In that case, this stage can be considered as complete.

Usually, the more experience you have, the easier for you to foresee what data / input / events /etc may not be handled properly by your code.

But even the most experienced engineers know that there's always a possibility of a missed case, bug, or some other problems.

So even if you are sure, go through your code again and try to find potential inputs / usage scenarios /etc you might have missed.

This stage is a good place to prepare tests as they'll ensure the changes at the next stages do not break the solution.

In case, you follow the TDD approach, you most likely started writing tests at stage 0, before even making a rough solution.

3. Improve the performance

Performance is important. Especially these days, when modern software is really the way to slow considering the resources available.

In #webdev it's one of the ways to improve your #SEO and ranking in the search engines. It also improves the #UX.

There's a statement credited to Donald Knuth: "Premature optimization is the root of all evil".

It's a good point and the iterative problem-solving respects this thought.

At the same time, it does not leave performance as an optional feature you'll add up (maybe) another day.

Most likely, if you treat the performance this way, your code (and the product) will always have a relatively poor performance.

Instead, I recommend you optimizing your code as part of the iterative coding process and not as a "fair weather feature".

You can see, there's a thin edge between premature optimization - when you try to make your code fast as early as possible - and optimization ignorant code - when you move performance optimization to the moment that it's already many days as shipped to the production.

In this stage, you often don't need to apply advanced algorithms and complex data structure knowledge.

Often it's more simple concepts: For example, in #javascript, if you traverse an array many times retrieving something - it may be more optimal to use a Map or an object.

Or if you fetch() data from multiple endpoints consequently, you can remove blocking and speed up the perceived performance by using concurrency with Promise.all().

Many optimizations are relatively trivial, honestly, and are learned rather as good practices than algorithms.

4. Improve the design

The design part is 2 slightly different things:
- Refactoring: improving naming, restructuring / reorganizing code, reducing duplication (if that's appropriate) 😉
- Applying design patterns

Refactoring is necessary most of the time - or the code quality will drop.

While applying design patterns often make sense only in subsequent iterations - do not try to apply them until you see that problem repeats a few times.

Otherwise, you'll add unnecessary over-engineering

5. Reduce complexity

I put this as a separate stage as engineers often forget (we r included) while in the pursuit of writing the most sophisticated code possible that:

"Perfection is achieved not when there is nothing more to add, but when there is nothing left to take away"

Before finishing the solution, we need to make sure that we made it simple and pragmatic enough to be

1. Readable - we are reading the code magnitudes more than we write code
2. Maintainable - in my practice, we work over existent code more than we write new (bugfixes, updates)

So even if you skip the design improvements always take a look at your code from the perspective of future months.

Will you understand it? Is it clear enough? Is something implied I know now and may forget later?

That's it.

Apply this approach to your daily development work, whether it's #frontend, #backend, #mobile, or anything else, and your work will be appreciated by everyone: your users, your colleagues, and even your future self 😉

@threadreaderapp unroll, please 👍