writing less code and going with the grain

Periodically we need to remind ourselves of good common sense coding practices. Two simple but very powerful are:

1. write less code

Sometimes the best solution is just to write less code. We need to think before implementing: how can I write less code? I may come up with an acceptable solution, but there may be a better solution with less code. Its possible my first solution is not the best.

A good time to do this thinking is before you get too far into an implementation. At a certain point you're too deep, too far along to easily change or reverse course. But even if you are, don't be afraid to change course, even if you may lose some time. Its still typically more efficient to change when building a feature than after its been released to production.


2. "go with the grain"

Systems are often built in a certain way and when we change those systems we should try to follow that way. Build on the existing architecture, on the current algorithm on existing conventions on how things are done.

"The phrase originally comes from woodworking, where "going with the grain" means working in the same direction as the wood's natural fibers for a smoother, more efficient result."

Now, obviously, sometimes we need to go against the grain and refactor because of various reasons (e.g. new requirements, wrong approach) and then we go against the grain. Part of our role is known when to "go with the grain" and when to "go against the grain". And also when it should happen versus all your other priorities.

 

Comments

Post a Comment

Popular posts from this blog

angularjs ui-router query string parameter support

angularjs ui-router is pretty cool, we use it in our app now but have not yet used query string parameters (e.g. ?p1=age&p2=height). But now we need to. we're now adding a feature which is basically a report generator and its a good use case for query string parameters once on the page then you're basically in that ui-router "state" users can select filters etc. from dropdowns which will reload the data but should not destroy/recreate any controllers or ui widgets (we stay on the page and do not state transition) yet we do want to update the url for deep links and back button support we don't know the complete list of possible filter choices, but know it should be data driven and will change by report  urls to support this report feature are will be something like thus /reports  /reports/sales  /reports/sales?region=west&time=weeks so we need to use query string parameters Below are some of the things I discovered with ui-router query strin...
Read more

react-select stacking order bug, z-index, layers and stacking

Image
Had to fix a tricky bug related to react-select recently (our Dropdown component wraps react-select). Here's the how the bug manifested. Dropdown does not overlay dynamically added content below it Variations of this have been reported since 2017. But I tried all the suggestions in the comments and none worked for me. I also tried wrapping the Dropdown in a div and changing z-index to be higher as well as making absolute position but no success. Changing the elements order in the html source and then reordering using flexbox order does work but it breaks the tabbing flow and is not recommended from an accessibility standpoint. One issue is the Dropdown is in a container and is constrained by the containers z-index. No matter how I change the Dropdowns z-index, its container is stacked below the next in stacking order. Google Chrome debugger layers tool provides a cool way to visualize layers. Could be better but helps, check it out below. You have to look closely but you can see h...
Read more

typescript notes (typeof, keyof, ReturnType, Parameters, Extract)

  typeof extract a type from runtime code, typeof "make a type of it" (i.e. from it) e.g.   typeof "Hello world"  => string only legal on variable names can be used with functions or any other expressions aside: typeof vs keyof: keyof takes a type and creates a string/number union of it's keys. So keyof creates a new type from a type ....whereas typeof creates a type from an expression. good post Given a function: const myFunc = (name: string) => {   return `hello ${name}`;    }; type the function into MyFunc type MyFunc =   typeof myFunc; type a function return type (using built in ReturnType ) type MyFuncReturn = ReturnType<typeof myFunc>;  // string When the function changes, the types change! You can also type the parameters using utility type  Parameters      type MyFuncParams = Parameters<typeof myFunc>;  // string but Parameters will return a tuple (array), so you could index result like...
Read more