If you’re anything like me (and chances are, if you’ve found your way to this site, you are. Gawd help you.), you love making apps with Ruby on Rails apis and Angular front-ends, running as two separate applications, as the man upstairs intended. With your ideal setup, everything to do with the view layer of your application would be handled by Angular, leaving the model and controller to Rails. All minification, fingerprinting, etc… would be handled by webpack and seamlessly integrated into your application. In the real world, however, we don’t always get what we want, and sometimes, your beautiful Angular application gets sandwiched into a legacy rails application, and said rails application still relies on sprockets for cache-busting (That is, unless you have Rails 5.1 or above, built with support for webpack). While this is all well and good for your legacy code (I guess), if your Angular app is built using the angular cli tool, you have the option of using webpack, which bundles support for those super-cool cache-busting hash-fingerprints that sprockets provides when compiling its assets. While the CLI’s documentation says this feature is turned on by default, I found the opposite to be true, and my app would generate nothing but the plain-vanilla bundles (booo!).
Everyone hates to be criticized; this is human nature, and it goes double for developers. It takes a long time to gather the skill-sets required to be successful as a developer, and on the whole, knowing this tends to be quite an ego boost. It’s when those egos get threatened and tempers flare out that code review practices can fall by the wayside, often to the detriment of the project. It’s easy to want to go easy on the people you get along with the most, those who are like-minded individuals who agree with you on the ‘right way of doing things’, and be merciless with those you don’t. This is an entirely wrong-headed way of going about it. We’ve all got this ego-monster living in our heads that screams out “WHAT THE F&#% DO YOU KNOW?” on every line of a peer review. Software development, unlike a lot of creative disciplines, is by nature a team effort - you have many devs with different skill-sets working towards the same goal: delivering working software that meets business expectations. If your project is big enough (and most are), chances are no matter how skilled a developer you are, you need everyone on your team to be able to complete your mission. Learning how to keep the ego-monster in check while your code is under review is probably one of the best skills a dev can acquire. Learning how to write a peer-review that’s merciless while at the same time respecting your colleague as someone who is most likely your equal and quite possibly even your better at some aspects of programming, is another.
I’ve been reading up on best practices lately, not just in software, but in general, and came across Lindsey Dunn’s article entitled Best practices don’t matter, here’s what does…. The article raises some great points about the blind implementation of best practices and argues for an adaptive culture, citing Toyota’s great success, and how they teach the adaptive methods. Now, this may leave some scratching their heads a bit… you may ask what an article in an online hospital review magazine and an automobile manufacturer’s decisions about best practices have to do with software development. There are some that will be reading the linked article and in their head, they’re bare-chested, swinging their shirts around their heads, and screaming “WOO-HOO!!! THERE’S NO RULES!!!”. You guys, put your shirt back on, and all of you bear with me for a moment, there is a point to this.
subscribe via RSS