Back in the early days, once we’d whittled our keyboards from a block of granite, we’d debate tabs vs spaces. Then we moved onto fixed display widths. Many a good friendship was lost to these worthy causes.
Then one day, something happened to restore peace. Swanky editors with soft-wrap, style guides, and EditorConfig united developers around one principle: consistency. Consistency was hard to argue against, and as tooling made it easier to promote/enforce we started to realise that the actual choice didn’t matter that much really.
So our armies retreated to our caves, ushering in an age of peace and productivity. But with that peace came complacency, and murmurings started again, this time around code collaboration. The Git Flow Wars of the 2010s saw the resurgence of trunk-based development and a return of the endless debate, this time around whether git rebase
was a silver bullet or a corrupting force of evil. …
Names are powerful. Good names are intuitive, and communicate intent and meaning to the reader. Good names help us have discussions without ambiguity, and gently nudge us towards a shared understanding of the thing.
Bad names, on the other hand, slyly make our lives harder. They hide ambiguity, and introduce tension into discussions. They make agreement harder, with different parties taking the name to mean different things. Sometimes none of these match the original intent, or even what the thing does.
The worst of it is that bad names are crafty. They sneak into conversations, documentation and code. …
A couple of weeks ago we held our first Remote Hack, a free, fully-remote hack day. Here’s what we did, how it went, and how you can run one.
Planning the day
To get things moving we set up a Slack organisation, a GitHub repository with a static site using GitHub Pages, and bought the remotehack.space domain name. We wanted to keep organisation and attendance lightweight, so after starting with a GitHub PR approach like SusHack we opted to open signups for the remote-hack Slack group and use chat/signups to gauge interest. …
Earlier this year I had the pleasure of working with the Department for Education, Nimble and Paper on the Alpha and Beta phases of a Find & Explore tool for the National Pupil Database. Having reflected on that experience, here’s a few lessons I hope I can apply to future projects, in no particular order.
Complex organisations have complex processes. Take the time early on to map out these processes through the lenses of the different departments. As an example, in addition to the GDS process (Discovery → Alpha → Beta → Live) we had Architecture Review Board and Technical Design Authority gates for technical architecture, as well as the Agile Security Framework, and Data Protection Impact Assessment. …
Hi Ryan, could you do me a favour and just confirm this user’s account please?
This request didn’t pop up in Slack in the first days of a new user confirmation feature. I was seeing this a couple of years later. The single line of Ruby was well known amongst the developers (it’s hardly rocket surgery) as we’d get a couple of requests a month, and within minutes we’d marked that account as confirmed and got back to more interesting challenges.
I see it over and over again. I fall for the same thing myself, even though I should know better: failing to automate menial tasks that encumber our non-developer colleagues because there’s “more important stuff to do”. …
We rely on Open Source for a huge portion of the Internet (and beyond), yet many projects still rely on goodwill and donated effort in order to survive. Sometimes that’s not enough, and organisations like Ruby Together have helped to make critical pieces of developer infrastructure more sustainable. Other projects have taken the approach of introducing premium tiers, adding enhanced functionality to libraries, tools and services in an effort to generate revenue and enable the (sometimes sole) developer to spend more time on the project.
Sustainability in Open Source software development is hugely important, but we need to walk the path carefully. …
About