OK, not really random thoughts as I've been thinking about this for quite some time. Sometimes it take a lot of reflection to understand what reality is (at least as I've perceived it).
There are a number of sayings that are too simplistic on review. Hey, there are a lot of sayings that sound good in the moment but other than a quick emotional appeal, do not help with the needs at hand. They are the quick 2 min fix that does not fix anything and still leave you as directionless as before.
So there is my software saying : "Don't pre-optimize your code".
At first glance this sounds correct and certainly applies for architectural issues and design, that may change to reflect implementation issues.
But at a personal level, does this really apply?
I mostly view the world through my own eyes and from my perspective, my toolkit, knowledge and experience is rather deep so that any code that I write is already efficient to a large extent. So much so that I rarely need to go back and re-write my code for optimization. For any given feature, I've already analyzed the implementation options in my mind and already pruned out the inefficient paths and settles on a clean design and patterns well before I start coding.
Looking back in time, I remember when junior coders have tried and failed to implement efficient implements that required re-work and sometimes a complete re-implementation. It's not that their code did not work, it did, but there where bugs that could not be rectified with the current implementation. Digging deeper I wanted to understand why this was the case.
Most features and coding is rather simplistic (web pages and forms come to mind) so that almost anybody that has a good understanding of the language (aka, JavaScript), will result in an acceptable implementation. The problem arise when the solution set lays outside of the coders experience set.
In these cases the coder should not pre-optimize because they don't have that knowledge yet. Veteran coders will write optimized code as they code, but the more junior coder will not know how for a more complex solution.
A solution set that represent this are "state" systems and "mutli-threading" (aka, WebSockets for web pages), where there are added dimensions to account for. Coders that have NOT been exposed to the designs and patterns for handling these cases will try to overcome them by adding flags, extra timeouts and other simple tricks to get the operational behavior that is required. All the while they are just hiding the issues without ever solving it. The resulting implementation could be so flawed that a re-write is required.
At this point, the coder would need to take a large leap on the learning curve to reach this higher level of knowledge. The real issue is they may not know this unless someone is around to guild them through this and there maybe additional pressure from management to "get it working".
There is kind of an unwritten myth that one you learn how to code, you can code anything. It's true if you know where your knowledge ends and when you need to stop and gain deeper understanding.
This is the opposite of the Imposter Syndrome where you feel not up to a task. This problem is where you are too optimistic about your skills and end up digging a deep hole that you can't escape from.
This leads in the Full-Stack vs Specialist programmer issue. But this is for a later article. For now just keep learning.
There are a number of sayings that are too simplistic on review. Hey, there are a lot of sayings that sound good in the moment but other than a quick emotional appeal, do not help with the needs at hand. They are the quick 2 min fix that does not fix anything and still leave you as directionless as before.So there is my software saying : "Don't pre-optimize your code".
At first glance this sounds correct and certainly applies for architectural issues and design, that may change to reflect implementation issues.
But at a personal level, does this really apply?
I mostly view the world through my own eyes and from my perspective, my toolkit, knowledge and experience is rather deep so that any code that I write is already efficient to a large extent. So much so that I rarely need to go back and re-write my code for optimization. For any given feature, I've already analyzed the implementation options in my mind and already pruned out the inefficient paths and settles on a clean design and patterns well before I start coding.
Looking back in time, I remember when junior coders have tried and failed to implement efficient implements that required re-work and sometimes a complete re-implementation. It's not that their code did not work, it did, but there where bugs that could not be rectified with the current implementation. Digging deeper I wanted to understand why this was the case.
Most features and coding is rather simplistic (web pages and forms come to mind) so that almost anybody that has a good understanding of the language (aka, JavaScript), will result in an acceptable implementation. The problem arise when the solution set lays outside of the coders experience set.
In these cases the coder should not pre-optimize because they don't have that knowledge yet. Veteran coders will write optimized code as they code, but the more junior coder will not know how for a more complex solution.
A solution set that represent this are "state" systems and "mutli-threading" (aka, WebSockets for web pages), where there are added dimensions to account for. Coders that have NOT been exposed to the designs and patterns for handling these cases will try to overcome them by adding flags, extra timeouts and other simple tricks to get the operational behavior that is required. All the while they are just hiding the issues without ever solving it. The resulting implementation could be so flawed that a re-write is required.
At this point, the coder would need to take a large leap on the learning curve to reach this higher level of knowledge. The real issue is they may not know this unless someone is around to guild them through this and there maybe additional pressure from management to "get it working".
There is kind of an unwritten myth that one you learn how to code, you can code anything. It's true if you know where your knowledge ends and when you need to stop and gain deeper understanding.
This is the opposite of the Imposter Syndrome where you feel not up to a task. This problem is where you are too optimistic about your skills and end up digging a deep hole that you can't escape from.
This leads in the Full-Stack vs Specialist programmer issue. But this is for a later article. For now just keep learning.
Comments
Post a Comment