Known and Unknown
Programming as in life consists of known and unknown. For any given problem statement, there are components which need identification.
Programming is very similar to how we tackle challenges in real life. One of the skills that also helps programmers is effective delegation.
When faced with a problem (programming or otherwise), my proposition is to start with a broad idea before embarking on the solution, and to use delegation to proceed. Without having a broad (now this can be subjective) idea, to start coding is a sin. Take a look at the goal which needs to be achieved, without the goal, the code would be gibberish, and will require multiple iterations.
Once the goal has been defined, identify the known and the unknown. Maybe, the business logic or the algorithm falls under the known areas, or maybe its the inputs that are known. There may be ambiguity on the integration or on how the change would impact other services.
Have a clear strategy of executing the known. This is where your design skills and OOPS should help, for this code too shall change.
No code written is forever, someone down the lane will need to make changes, make his/her life easier today by writing understandable code (understandable for humans). If the code cannot be understood by machine, I doubt it will see the light of the day.
When coding, follow the art of delegation. For unknowns, create functions or methods that take care of the delegated part. For example, let’s say we currently do not know where a particular field would be from the database, create a function that is to provide this field, and move ahead with the solution. We will have to come back to solve for this, but by then the problem statement would be individualised. Get this function to throw exception if you think you are creating too many functions and won’t remember to fill them back up.
I propose to break problem statements into manageable chunks, of known and further chunks of unknown. In large problem statements, it is cognitively difficult to understand and predict all the pathways.
For example, let’s say you are working on a problem statement. This statement has a business logic, needs to read data from some system, and is to write output to some system.
Assuming the business logic can be written correctly, we can make assumptions about the input. Using an adapter we can convert the input to the format in which the business logic understands. This decouples the logic from the strictness of the data type of input, as well as makes the functions readable. By creating functions that do concrete unit of work, the code becomes modular and manageable .Once its done, the inputs can be tied one at a time.
As in life, there is nothing without costs and the above delegation also has its cost. It may add some cost of refactoring, when there could be functions doing work which could easily be abstracted out, or similar other such costs.
How do you program, when faced with a problem statement? And yes, the problem should have areas which are unknown.
