"Coding is the easy part"
Yes...but, only for really good engineers.
Yes...but, only for really good engineers.
Figuring out how to design half of a system isn't anything. Anyone can do that. Non-programmers do that all the time. Engineering a solution means the whole thing, not just the easy parts of it, just like coding the solution means coding the whole things, not just the easy parts of it.
Focus on making your code clearer, not fancier or "faster". Don't prematurely optimize your code by eye. Generally just being conscious of the major performance no-nos to avoid and being able to use appropriate tools (like a profiler) when and if you actually need to tune performance is all you need. Instead concentrate on making your code highly readable, self-documenting plus fully documented (the best of both worlds!), as well as composable and maintainable and you'll be well set. Not just will you make other developers happy and improve the code base overall (fewer bugs, easier modifications for inevitable feature changes in the future) but you'll make your future self happier when you have to come back to that code.
By far the biggest mistake I see developers make is making their method/function bodies too long. Extract your methods people, it's not that hard and it's a great habit to get into. It takes skill to get good at it but a decently named small function makes code more readable and more reliable. And getting into the habit of making little functions that just take a few inputs, do stuff, and return a value makes your code way easier to unit test as well.
Exactly!
> By far the biggest mistake I see developers make is making their method/function bodies too long. Extract your methods people
As a general rule this is just one side of the coin imo. I often see this approach increasing the complexity of control flow in direct proportion to the simplification of individual code blocks. Net gain zero.
For me it actually makes code less readable. It makes the system more complex (because you've added extra function definitions and function calls) and just jumping back-and-forth between those small function calls makes code harder to read. I would much prefer to have a larger method that just does things in order, and, for readability, have its body divided into sections, each in isolated brackets (so that variables have local scope) and commented if necessary.
Edit: Hey, it is easy to implement code having bugs (shortly: implement bugs) and do many fixes further. It is hard to understand the problem and write code once, which won't need any bugfix. Think about the Apollo-11 code [0] - one tiny bug and astronauts might be dead.