Changelog

If software is eating the world, who is writing that software? You are. Hongli Lai, Co-founder & CTO of Phusion gave a talk at his local Amsterdam.rb meetup and shared his thoughts on the impending deadline of the EU General Data Protection Regulation (GDPR) and the impact of socially unaware software that's eating our world. ...I feel more and more convinced we (as Phusion and as ‘builders of the web’) have a responsibility to provide a framework for thinking about the ethical implication of our creations. Hongli continues: We've seen companies suffer recently for a lack of that social responsibility (data breaches at Equifax, Facebook, Uber, etc). Public outrage was strong but also burned out quickly as the news cycled. For a while, the same quick fizzle seemed to be happening with the Facebook and Cambridge Analytica scandal. It's up to us to fight back. That doesn't mean go on twitter and rant, but to actually go an do something. Give a talk in your local area to your developer communities to create with social responsibility in mind.

Laziness is one of the three great virtues of a programmer (laziness, impatience, and hubris) Larry Wall talked about in Programming Perl. The "deep thinking," as they call it, which is always required before even a small issue can be resolved, seriously turns me away from programming. Or did turn me away. Until I started to think differently and encourage myself to be lazy. Here is how. Iteration! It's so freeing to operate on the basis of iteration — knowing that today's version is shipping with flaws that can only be resolved through the feedback loop. In this case, incremental is an alias of iteration. Software development is perfect territory for cutting corners, being lazy and remaining calm, because our work is often discrete and can be very incremental.

I'm a huge fan of well designed feedback loops. In software creation, feedback loops prove to be one of the most important, often overlooked, artifacts of the development lifecycle. Evelyn Van Kelle writes on the O'Reilly Ideas blog: There is a false dichotomy between full automation and human intervention. Successful quality control combines tool-based measurement with manual review and discussion. At the end of the day, the most effective feedback loops are a mixture of daily best practices, automation, tools, and human intervention.

Reading Amjith's git hack reminded me that I wrote up a few techniques I use to retain my dev flow between coding sessions. I wrote this post back in 2011, but I'm happy to report I still use #2 and #3 all the time. ✊

Itamar hits the nail on the head: If you think of yourself as a Python programmer, if you identify yourself as an Emacs user, if you know you’re better than those vim-loving Ruby programmers: you’re doing yourself a disservice. You’re a worse programmer for it, and you’re harming your career. I've been preaching the gospel of generalization for many years. This industry moves fast. Today's new hotness is tomorrow's old and busted. Learn specific skills, yes. But always keep yourself above the fray. I am not a Rails Developer. I am not an Elixir Guy. Heck, I don't even consider myself a web developer. I solve problems; sometimes by writing software. Back to Itamar: The technologies you use, the tools you build with, are just that: tools. Learn to use them, and learn to use them well. But always remember that those tools are there to serve you, you are not there to serve your tools.

Do you wish you weren’t the only person slaving away on your open source project? Find out how to make your project pull request ready in this guide from our friends at Phusion. Floor Drees, writes on the Phusion blog: Newcomers to your project will turn to your issue tracker and look at (merged) pull requests, discussion forums, mailing lists or chat channels to form an idea of what your project is like and how and where they can best contribute. Optimizing these channels for on-boarding contributors will set you up for success.

Yegor Bugayenko: Thread-safety is an important quality of classes in languages/platforms like Java, where we frequently share objects between threads. The issues caused by lack of thread-safety are very difficult to debug, since they are sporadic and almost impossible to reproduce on purpose. How do you test your objects to make sure they are thread-safe? Here is how I'm doing it. Great details on a particularly difficult aspect of testing. ✨

Rachel Kroll with some sage advice on how to find interesting things to work on: In concrete terms, go around and find out what kind of little one-off tools people have designed. Talk to them and hear their stories. Look in their personal bin directories. Take notes and look for patterns. See if anything stands out, or if anything particularly compelling grabs you during the interviews.

Olivier Lacan on why we should all stop using cd and start using j (a.k.a. autojump). I've been wasting soooo many keystrokes over the years! 😱

Erica Lindberg, writes on the GitLab blog about preventing burnout: Set clear boundaries between work and home — I'm trying to limit how many days I allow myself to work over eight hours by either scheduling other activities in the evening with friends or my partner (it works better when you've committed to someone so they can help hold you accountable. These things can be anything from rock climbing to dinner or watching a movie) or simply blocking out my calendar and setting reminders for when it's time to shut off. And when it is time to shut off I'm come up with a "ritual" of shutting down my computer, turning off my keyboard, monitor, and light in my office – this makes it harder to come back to "just finish up one last thing" I really needed to be reminded of this. It's a shame when you know what to do, but you choose not to, and allow yourself to creep closer to burnout.

Carmen Andoh joined the show and talked with us about inclusivity, the 2017 Go Developer Survey, visualizing abstractions, and other interesting projects and news.

Yegor Bugayenko: Fluent interface, first coined as a term by Martin Fowler, is a very convenient way of communicating with objects in OOP. It makes their facades easier to use and understand. However, it ruins their internal design, making them more difficult to maintain. A few words were said about that by Marco Pivetta in his blog post Fluent Interfaces are Evil; now I will add my few cents. Yegor uses his own HTTP library as an example where the interface designed is fluent (which looks nice and readable to use) and shows how that design goal made the internal code a mess. My gut tells me it's worth the trade-off to provide a better user experience, but Yegor's real-life experience punches me right in the gut: Fluent interfaces are perfect for their users... However, the damage they cause to object design is the price, which is too high. He suggests decorators and smart objects as an alternative. Lots to ponder here, and the conversation going on in the comments is lively as well. 👌

Dimitri Fontaine shares 3 classic data-modeling anti-patterns. The UUID section lacks strong argumentation, but the real gem in this article is his advice at the end. A snippet: My advice is to always normalize your database model first, and then only fix the problems you have with that when you actually have them. Well except in those 3% of cases where really, really, it should be done in the design phase of the project. It’s quite hard to recognize those 3% though, and that ability is hard gained with experience. Experience is the ultimate teacher.

Suz Hinton joined the show to talk about live coding open source on Twitch. We talk about how she got interested in Twitch, her goals and aspirations for live streaming, the work she's doing in open source, Twitch for open source, how you and others can get started — and maybe some other fun stuff we have in the works at Changelog.

The subtitle here should have been “We’re all very !#$@%#$ afraid”. The reason I often hold back from doing something or when I self-sabotage a goal — the real reason is because I’m afraid of what will happen if this thing is actually successful??! Then, I’ll have to actually do it. 😱 John Gorman, writes for Personal Growth on Medium: Fear doesn’t manifest itself like you think, because often times we don’t give it the chance to. Fear isn’t always the sweaty palms that stop us cold in a job interview — fear is generally what prevents us from applying in the first place. Spend 8 minutes and read this.

Hazel Yang, on the GitLab blog shares insights about her last two years working at GitLab: Show gratitude Learn from failure Trust your team and grow with them Befriend managers and colleagues Embrace diversity I'm a HUGE fan of the concept of a "retrospective" which is most known by developers as a practice of agile software development. It is important to look back and review what's going well, what's not going well, and what needs to change or be stopped all together. This post is a product of that type of discipline.

Nikita Sobolev outlines why they're a self-described "mediocre developer" and how they survive in such a state. What follows is a bunch of excellent advice on practical steps toward success as a developer. Ironically, Nikita's self-professed mediocrity and clear path toward defeating it makes them an outstanding developer in my eyes. 🤩 Go and do likewise.

Stephanie Morillo drops some wisdom she gained running the Digital Ocean blog for the past year: Teams need buy in from the engineering org, a primary owner for all things blog related, a regular publishing cadence, ongoing conversations, flexibility, cross-functional communication, and open dialogue with readers to get the most out of their blog efforts. Getting buy-in can be the hardest part. I have a hard time convincing myself to blog, let alone other people.

Steve Jobs, in his last interview with Walt Mossberg and Kara Swisher at the All Things Digital's D8 Conference in 2010. Steve died a year later. We're organized like a start up. We're the biggest startup on the planet. There's tremendous teamwork at the top of the company, which filters down to tremendous teamwork throughout the company. Teamwork is dependent on trusting the other folks to come through with their part without watching them all the time, but trusting they're going to come through with their parts. That's what we do really well. If you wanna hire great people and have them stay working for you, you have to let them make a lot of decisions and you have to be run by ideas not hierarchy. The best ideas have to win, otherwise good people don't stay. This interview has many great highlights, but this part is some of my favorite advice Steve has ever given about how to run a company. We strive to achieve this at Changelog. Here's a link to the full video, and the same but deep linked to the part quoted in this post.

Alex Sexton, on his personal blog: This list is the product of many years of experience in the front-end web development field. I maintain this list as a reminder to myself to always follow best practices, and to not compromise on performance, even if I’m in a time crunch. I read it before I start any project, and share it with my team at work (sometimes we joke and call them “codemandments”) so we can all be on the same page and do our part to keep the web fast. He goes on to say "feel free to fork this for your own use," so use this liberally. Some of my favorites: I will use SVGs instead of JPGs, wherever possible. I will resist the urge to use window.alert to inform visitors that there’s a Facebook group for cool friends and if they wanna join it, that’s fine, it only takes a few clicks. 😂

I was clueless about this until I saw the Smashing Mag headline in my feedbin: Europe’s imminent privacy overhaul means that we all have to become more diligent about what data we collect, how we collect it, and what we do with it. Read through and be aware of the implications. These changes become enforceable in May of 2018.

The TLDR: Contributor license agreements (a “nice to have” for many corporate-backed open source projects) create a contribution-hostile developer experience, require significant administrative overhead, shift legal blame to the party least equipped to defend against it, and are unnecessary given modern development tools. Click through to read each of these points explained in great detail.

Mike Hoye dives deep to answer this question: By now your peripheral vision should have convinced you that this is a long article... He's right. This piece looked so long that I kept it open in a tab (the original Instapaper) for a couple of weeks before reading it. But it's not so bad! And the topic is fascinating: starting at 1 is not an unreasonable position at all; to a typical human thinking about the zeroth element of an array doesn’t make any more sense than trying to catch the zeroth bus that comes by, but we’ve clearly ended up here somehow. So what’s the story there? My head canon on the topic treats zero-indexing in terms of offsets. How much of an offset do you need to reach the first entry in the array? Zero. How much for the second? One. Turns out, nope that's not why!

Lorna Jane Mitchell, on the role of a developer advocate: The less-visible part of the role is probably the most technical part. People rarely think of the gregarious advocates they see on stage or tweeting as being technical but we are, probably more than you expected. I write sample code and internal tools, but better than that: it's my business to wade in and improve anything that would make life easier for developers. An advocate is just that, someone who acts on another's behalf — a role that requires a variety of skills: The job requires a really weird mix of skills, and like most advocates I'm endlessly delighted to find that there's a job that combines such a great combination of stuff I like to do! The role varies a lot between jobs, and also between weeks — it's a little bit of everything.

From David Mack, CTO and co-founder of SketchDeck: You can accumulate responsibility faster than you can learn how to harness it. I now appreciate that the infrastructure, frameworks, and languages you choose will stick with you for a really long time. Only hire when you feel you’re completely desperate for the role. Hire to keep up with growth, not to generate it. I really appreciated David's thoughts on hiring.