Two Software Opinions
Was asked to question as part of an application and I thought it would be good to publicly share and document them for future reference.
What is one strong opinion you have about software development that is also strongly held, and why do you hold this opinion?
NULL is bad, it's the billion dollar mistake as the creator Tony Hoare said and he was clearly underestimating it's impact.
The problem with NULL is that it allows you to hide the behavior by saying I don't know and sometimes that can be it's not known yet, it's not in the range of expected values, or it has failed and I give you nothing. Â How are you supposed to know without applying some thinking on to the situations and results that possibly could return from the method. Â What are you doing here? Â You have offloaded your complexity of situations, paths, and results to your caller/user. Â Don't do this, languages like Elm, Pony, Haskell etc say this is something to provide intent to signal to the consumer of the function and list the valid state and do not represent invalid states.
It's just a lazy catch all that anything can be of NULL state so that represents everything in your system if you think about it, constantly thinking that a type/method can give you an implicit NULL is bad and causes unneeded strain and state checking in your code.
If you can avoid it, be explicit on allowable types and that means removing the ambiguity of NULLs.
What aspect of distributed systems engineering do you enjoy the most, and why?
When you are distributing workloads amongst workers in a system the predictability of what happens when, where, and how many times is difficult to control and monitor. Â However if you build your system to work idempotently operating and debugging such a system becomes exponentially easier. Â Distributed systems are messy in practice because ordering, retries, and operations are not consistent between workers and accepting and working with these issues at the forefront means building idempotency on the distributed results is paramount to getting at least one form of guarantee on what you can control when writing the system.
The guarantee of idempotency means that the end results can be aggregated without worry and you can key off that guarantee to then find redundancies and issues all the while this is happening the system continues to operate and operational efficiency can be increased in an incremental, deliberate, and constructive manner.