Posted in 2018

Working remotely in a non-remote company

We鈥檙e a small team here at Guava, and we鈥檝e always considered ourselves remote friendly. Most of us work remotely every now and then pushed by varied force majeure situations鈥 be it the flu, the need to supervise renovation or construction work at home, flash floods near the office, receiving guests at home or any number of other situations. We鈥檝e also had a few of us working remotely for a few days or weeks while traveling to or back from a conference, or when visiting relatives that live out of town. In other words, remote working has always been a very temporary and circumstantial thing among us.

We have a nice office (with hammocks!), excellent work equipment, great desk space, comfortable chairs, plenty of snacks and comfort food and an infinite supply of coffee. We鈥檙e also easygoing and overall pleasant people (well, most of us are) to work with several hours a day, and some of us are even mildly funny.

Halving page sizes with srcset

Web bloat is discussed a lot nowadays. Web pages with fairly straightforward content鈥娾斺妔uch as a Google search results page鈥娾斺奱re substantially bigger today than they were a few decades ago, even though the content itself hasn鈥檛 changed that much. We, web developers, are at least partly to blame: laziness or just bad programming are definitively part of the problem (of course, laziness might stem from a tight or impossible deadline, and bad code might come from inexperienced programmers鈥娾斺妌o judgment going on here).

The 5 stages of dealing with legacy code

Yes, this article will use the 5 stages of grief as an analogy for something software development-related. There are at least a few thousand other articles with a similar motif (424,000 results for 鈥済rief stages software鈥 according to Google). But bear with me for the next 5 minutes and I promise you鈥檒l get something out of this鈥娾斺奿f nothing else, at least the smirk of those who read their past follies put on text by someone else.

I have been working on a rather big Rails project for the past year and half. The project is nearly 7 years old, and has an all-too-common successful-startup-bought-by-industry-giant background story. In a project with this kind of background, some things are bound to happen: many developers of many skill ranges have come and gone, many software fads (cough, Meteor, cough), and above all else a lot of legacy code that is, well, let鈥檚 put it nicely, not so great. None of this should be taken personally in any way鈥娾斺奿t is just natural for such things to occur in such projects.

10 ways not to do a big deploy

Ideally, deploys should be small, concise, easily revertible, fast and with a small or nil footprint on the database. However, no matter how awesome you are, sometimes that is just unattainable and you end up needing to deploy something that is just the opposite: big, messy, hard to revert, painfully slow and rubbing the DB the wrong way. If the deploy messes with a mission-critical part of your software, all the worse for you.

But there are actually many ways you can make those situations even worse. Here are a few bullet points you can follow to guarantee a nightmarish deploy complete with nasty side-effects that will haunt you and your coworkers for days to come.