On Empathy & Pull Requests

I’ve trained more people on the subject of pull requests than I care to remember.  But I’ve never came close to explaining the best practices as well as this Slack Engineering blog post does:

Basically, your reviewer is totally missing context, and it is your pull request’s job to give them that context. You have a few options:

  • Give it a good title, so people know what they’re getting it into before they start.
  • Use the description to tell your reviewer how you ended up with this solution. What did you try that didn’t work? Why is this the right solution?
  • Be sure to link to any secondary material that can add more context — a link to the bug tracker or a Slack archive link can really help when describing the issue.
  • Ask for specific feedback — if you are worried that the call to the `fooBarFrobber` could be avoided, let them know that so they can focus their effort.
  • Finally, you should explain what’s going on for your reviewer. What did you fix? Did you have any trouble fixing the bug? What are some other ways you could’ve fixed this, and why did you decide to fix it this way?

Not every pull request needs every single one of those things, but the more information you give your reviewer, the better they will be able to review your code for you. Plus, if someone ever finds a problem in the future and tracks it down to this pull request, they might understand what you were trying to do when they make a follow-up fix.

Give your reviewer all the context they need to get up to speed with your bug so they can be an informed, useful code reviewer. It’s all about getting your reviewer onto the same page as yourself.

Postcardware

I am not the biggest fan of shareware or other ways of limiting user rights when it comes to software, but if I had to pick one and call it my favorite, I’d go for the  postcardware.  Have a look at this good example:

Open source software is used in all projects we deliver. Laravel, Nginx, Ubuntu are just a few of the free pieces of software we use every single day. For this, we are very grateful.

When we feel we have solved a problem in a way that can help other developers, we release our code as open source software on GitHub.

A lot of our packages are postcardware —free to use if you send us a postcard.

 

Periodic Table of Software Engineering

I came across this Periodic Table of Software Engineering, and I think it’s an excellent visualization.  For those working their way to become software engineers, it provides a nice map of skills, topics, and knowledge areas to cover.  For the rest, it clearly explains why software is so much more complex than anybody thinks.

What is the hardest part about learning to program?

Quora runs an interesting question – “What is the hardest part about learning to program?“.  As always, there are plenty of insightful answers with suggestions, tips, shared stories, research and statistical data, and more.

For me personally, this answer in particular was useful, as I’m very well familiar with the phenomena, but never knew there was a name for it – Dunning–Kruger effect.

Single Sign On – You’re Probably Doing It Wrong

Arnes Blanert wrote an extensive article for the architect magazine on the subject of Single Sign On (SSO).  It covers both authentication and authorization via a variety of widely and not so widely used methods, including oAuth, SAML, JSON Web Token and more.

As someone who was involved in a variety of Single Sign On implementations (see some of the posts on the subject in my blog), I wish I had an article like this in my RSS feeds much much earlier.

The sudden death and eternal life of Solaris

Bryan Cantrill wrote this blog post on the death of Solaris.  Here’s a bit like the most about it, which talks about the proprietary software vs. Open Source:

Assuming that this is indeed the end of Solaris (and it certainly looks that way), it offers a time for reflection. Certainly, the demise of Solaris is at one level not surprising, but on the other hand, its very suddenness highlights the degree to which proprietary software can suffer by the vicissitudes of corporate capriciousness. Vulnerable to executive whims, shareholder demands, and a fickle public, organizations can simply change direction by fiat. And because — in the words of the late, great Roger Faulkner — “it is easier to destroy than to create,” these changes in direction can have lasting effect when they mean stopping (or even suspending!) work on a project. Indeed, any engineer in any domain with sufficient longevity will have one (or many!) stories of exciting projects being cancelled by foolhardy and myopic management. For software, though, these cancellations can be particularly gutting because (in the proprietary world, anyway) so many of the details of software are carefully hidden from the users of the product — and much of the innovation of a cancelled software project will likely die with the project, living only in the oral tradition of the engineers who knew it. Worse, in the long run — to paraphrase Keynes — proprietary software projects are all dead. However ubiquitous at their height, this lonely fate awaits all proprietary software.

There is, of course, another way — and befitting its idiosyncratic life and death, Solaris shows us this path too: software can be open source. In stark contrast to proprietary software, open source does not — cannot, even — die. Yes, it can be disused or rusty or fusty, but as long as anyone is interested in it at all, it lives and breathes. Even should the interest wane to nothing, open source software survives still: its life as machine may be suspended, but it becomes as literature, waiting to be discovered by a future generation. That is, while proprietary software can die in an instant, open source software perpetually endures by its nature — and thrives by the strength of its communities. Just as the existence of proprietary software can be surprisingly brittle, open source communities can be crazily robust: they can survive neglect, derision, dissent — even sabotage.

AWS Application Load Balancer

I found this visual primer to the Application Load Balancing on the Amazon AWS quite interesting.  Application Load Balancing is not something I am using just yet, but it’s getting there.  With more and more services and pricing schemas available from Amazon, explaining things simply is not as easy as it may seem.

oEmbed specification

oEmbed has been around for a while and there are some really nice implementations of it.  For example, in WordPress, where pasting a URL to YouTube video, Flickr photo, Twitter tweet, and a number of other services, will result in a nicely formatted embedded snippet from an external site.  WordPress does not only consume the oEmbed, but also provides embeddable content.

For a while now, I’ve been thinking about ways to utilize it.  There are quite a few applications of oEmbed that make sense for our projects at work.  For now, I’ll just leave you here with the link to the oEmbed specification.