Eric Tse

What Learn how to shut down Go HTTP servers so as to release resources properly. Why We started writing Go in 2014 for web services to support our mobile app. By “writing”, I mean slapping together code based on online blog posts and overly simplistic or out-of-date tutorials. What joy it was to crank out relatively straightforward, working code that replaced our frustrating Node/Express servers on production within a few days!...

I’m not opposed to the philosophy of improving code incrementally, but doing this can result in reduced productivity and more bugs, which I want to avoid. Non-functional improvements to code in the same pull request may introduce bugs make it harder to revert cleanly when a code change is discovered to be buggy obligate us to perform more testing, decreasing velocity add noise to the Git log, making it harder to find things require more time from the code reviewer to understand the change increase overall time in code review, as more lines changed also increase opportunities for more feedback and waiting My understanding of “cleaning up code along the way” means to change code around the area that I’m currently working in, however, requiring our team members to follow a non-linear path while reviewing a PR can be discouraging and waste time and energy....

Let’s do this.