Writing simple functions which take an A and return B in any context. Then, composing those simple functions together to build up more complex functionality.
Although sometimes the domain is not clear enough before you start, that's shitty.
51–60 of 215 posts
Writing simple functions which take an A and return B in any context. Then, composing those simple functions together to build up more complex functionality.
Although sometimes the domain is not clear enough before you start, that's shitty.
For example once we had a project that wanted to add Role Based Access Control and some juniorish engnineer suggested adding boolean columns to the table for each of the user's roles.. Nope. Instead we created a document store w/ roles and defining new roles was as simple as adding a const to a set in the service's code. Good thing too because the number of roles grew from the initially requested ~3 to almost 100. That would have been too wide of a table.
Try again.
Something not mentioned yet. I find programming is the task of last resort and I spend a good deal of my time talking with the product person to help them refine their product idea into something that is mechanically sympathetic with how computers work and the general problem domain. It often adds 10% time for the initial work and -90% of the time for iterations. For example once we had a project that wanted to add R…
Avoiding cleverness at all costs. Simple code that is easy to both read and write without strong efforts to follow senseless DYI or take on abstraction for the sake of abstraction.
Their second decade they learn that simplicity and readability is always better, even if it does require more code.
It's better to have 300 lines of simple, straight-forward, easy-to-read code than to have a 30 line version of the same code that's difficult to understand, and difficult to debug.
Always code for your future-self and future-others who really don't want to spend an hour figuring out what the hell you did in that awesome looking 30 lines of entropy.
If you have to run your code to understand it. Try again.
In reality the code might be right for 90% of use cases, but once you multiply this over a whole project, you end up with total dogsh*t, and mainly because of laziness too. This is the biggest reason the inexperienced developers create such horrendously buggy code.