Changelog

Do you have documentation? Do you have a documentation content strategy? No?!! If you want to create guides for your software, having a solid content strategy can help you write useful content. This article will walk you through how to develop that strategy, whether you’re an engineer or a technical writer, new to writing documentation or just looking to get more strategic about it.

The cause is a 2FA fail with either SIM security or a mobile number port-out scam as the point of failure. Brian Krebs writes for KrebsOnSecurity: Of particular note is that although the Reddit employee accounts tied to the breach were protected by SMS-based two-factor authentication, the intruder(s) managed to intercept that second factor. In one common scenario, known as a SIM-swap, the attacker masquerading as the target tricks the target’s mobile provider into tying the customer’s service to a new SIM card that the bad guys control. Another typical scheme involves mobile number port-out scams, wherein the attacker impersonates a customer and requests that the customer’s mobile number be transferred to another mobile network provider. Were you exposed? ...between June 14 and 18 an attacker compromised several employee accounts at its cloud and source code hosting providers. Reddit said the exposed data included internal source code as well as email addresses and obfuscated passwords for all Reddit users who registered accounts on the site prior to May 2007. The incident also exposed the email addresses of some users who had signed up to receive daily email digests of specific discussion threads.

The important thing to remember about leading is you have to have clear lines of communication with those you lead. I love the ideas Lara shared in this guide to writing a "week in review" team update. This doc helped me set records straight, disseminate info to lots of people at once, and open up conversation internally, while reflecting on the themes that had come up in weekly one-on-ones, backchannels, team meetings, etc. What I chose to write about each time widely varied. Though the teams who reported to me were the primary audience for this doc, I kept it internally-public, meaning that anyone at the company could read and comment in it. I found that some other managers just weren’t talking about hard things that were happening...

Ali Spittel lays out 7 excellent tips for writing cleaner code. Use descriptive naming Functions should do one thing well Comments should tell the "why" ... It's imperative to first learn rules like these, follow them for awhile, and then (and only then) you will be equipped to know when (and when not) to break the rules.

Tigran Hakobyan, remote software engineer at Buffer, writes on the freeCodeCamp blog: Working remotely is very different from working in the office. I don’t think you fully grasp the difference until you actually start being remote. For someone like me who never worked in a remote environment, the beginning wasn’t smooth and it came with challenges. I can clearly remember my very first day at Buffer... Tigran also shares a pretty comprehensive breakdown of a typical workday.

In the wake of Microsoft's acquisition of GitHub, the murmurs of replacing GitHub with something decentralized have been getting louder. In this article, Drew Devault points out that email-based git workflows are A Thing and one that works quite well. In particular, this blog post is a direct response to forge-net (formerly known as GitPub). They want to federate and decentralize git using ActivityPub, the same technology leveraged by Mastodon and PeerTube. But get this: git is already federated and decentralized! Drew has skin in the game via his sr.ht platform, and intends to make git send-email support a first-class citizen on it. Lots of interesting ideas at play here. After all these years is email still the web's killer app?

Dion Almaer (Google) writes on the Ben and Dion Medium publication: A few teams within Google have joined forces inside Chrome to focus on improving the Web ecosystem, focused on those who build experiences, and create on the Web. We want to make high quality experiences easy to build as that will enable more meaningful engagement on the Web for users and developers alike. This is an awesome breakdown of all the components required to deliver meaningful engagements and a roadmap to the future of the web platform.

I have to agree with this hard-line stance from Chris Coyier on the subject of view source: I literally don't care at all about View Source and wouldn't miss it if it was removed from browsers. I live in DevTools, and I'll bet you do too. I want my website to arrive at light speed on a tiny spec of magical network packet dust and blossom into a complete website. Or do whatever computer science deems is the absolute fastest way to send website data between computers. I'm much more worried about the state of web performance than I am about web education. But even if I was very worried about web education, I don't think it's the network's job to deliver teachability. What about you? Is view source more important than web performance? Is DevTools a worthy replacement for view source? Chris also cites comments on the subject from Tom Dale, Jonathan Snook, and Chris Heilmann.

This is an interesting 30-hour method for learning a new skill from Azeria Labs (aka Azeria). If you're a fan of flow and you'd like to learn how to apply it to learning a new skill, check this out. We also know and have experienced the feeling of flow. The moment when you’re fully focused on a task. You lose all sense of time, and everything seems to flow effortlessly; you forget everything around you and have a feeling of control over the task. This rewarding feeling of flow is best described by Psychologist Mihaly Csikszentmihalyi: “The best moments usually occur when a person’s body or mind is stretched to its limits in a voluntary effort to accomplish something difficult and worthwhile.”

Ives van Hoorne writes on Medium: Personalizing color schemes is one of the most important things to have in an code editor. CodeSandbox didn’t have any way to personalize colors in the editor since release, but I’m happy to announce that we do now. The best part is that we were able to reuse a big chunk of logic from VSCode directly and also support any VSCode theme natively in CodeSandbox!

This is Segment's story from monorepo to microservies back to monorepo — "from 100s of problem children to 1 superstar child." Software Engineer Alexandra Noonan writes on the Segment Engineering blog: As time went on, we added over 50 new destinations, and that meant 50 new repos. To ease the burden of developing and maintaining these codebases, we created shared libraries to make common transforms and functionality ... Over time, the great benefit we once had of reduced customization between each destination codebase started to reverse. Eventually, all of them were using different versions of these shared libraries. The woes of operational overhead with each expansion into more microservices. The number of destinations continued to grow rapidly, with the team adding three destinations per month on average, which meant more repos, more queues, and more services. With our microservice architecture, our operational overhead increased linearly with each added destination. Therefore, we decided to take a step back and rethink the entire pipeline. One of the original motivations for separating each destination codebase into its own repo was to isolate test failures. However, it turned out this was a false advantage. With destinations separated into their own repos, there was little motivation to clean up failing tests. I'd love to dig into this story more on The Changelog with the team behind this transition back to a monolith and discuss the deeper details of their lessons learned.

This epic four part series from the Airbnb engineering blog showcases how React Native was used at Airbnb to enable their teams to move quickly and maintain a great developer experience. However, in the end, they decided to sunset React Native and focus on native — but their journey to that conclusion is well worth a read. Part 4: Sunsetting React Native — Although many teams relied on React Native and had planned on using it for the foreseeable future, we were ultimately unable to meet our original goals. In addition, there were a number of technical and organizational challenges that we were unable to overcome that would have made continuing to invest in React Native a challenge. As a result, moving forward, we are sunsetting React Native at Airbnb and reinvesting all of our efforts back into native. It's not all bad though. 63% of their engineers would have chosen React Native again given the chance and 74% would consider React Native for a new project. Gabriel went on to say: React Native is progressing faster than ever. There have been over 2,500 commits in the last year and Facebook just announced that they are addressing some of the technical challenges we faced head-on. Even if we will no longer be investing in React Native, we’re excited to continue following its developments. For a different perspective read Should we use React Native? — a follow-up post to this four part series.

Read this for the sidebar management tips alone! Wow, I had no idea how cluttered my sidebar was until I followed Peter's guidance from this post. Declutter your sidebar by hiding all channels that don’t contain unread messages and are not starred. You still won’t miss anything, as they pop up if there’s chatter, and you can always use ⌘-T to open the Jump menu. It’s amazing how much better it feels if there aren’t 50 channels you need to scroll through all the time. This post was extracted from Peter's talk Effective Remote Communication.

Ken Wheeler (Director of open source at Formidable) shared some pretty helpful words to get you excited about open source and also how to launch your first project. Nothing makes your repo look more legit than badges. Too many badges looks memey as fuck, but if you include useful ones, its a stamp of legitimacy. It shows you care. Things like npm version, test status, coverage numbers. It’s nice flair. Also, Markdown supports raw HTML, so you can make your repo header look nice. Center things, add a quote, jazz it up a bit. Ken even shared his thoughts on the best time to launch. My recommendation is very specific. Release at 12pm EST on a Monday. It’s the end of Europes day, New York’s lunch break and San Franciscos hour in the morning before anything gets done.

One of my favorite jobs in software was when I was a Product Manager for a non-profit startup. In that role I was able to impact and touch pretty much any part of the business I wanted to, it was almost like being an entrepreneur, but doing so from within an already formed company. I also led our agile software development as Scrum Master — it was awesome. I wish I had this list of advice back then. Mike Cohn writes on the Mountain Goat Software blog: Never commit the team to anything without consulting them first — As Scrum Master, you do not have the authority to accept change requests (no matter how small) on behalf of the team. Even if you are absolutely positive that the team can fulfill a request. Always say, “I need to run this by the team before we can say yes.” And certainly don’t commit the team to deadlines, deliverables, or anything else without first talking to team members. You may not need to talk to the whole team--plenty of teams will allow some or all members to say, “Yeah, we can do that” without a whole-team meeting. But it’s still their decision, not yours. This is number 1 on the list, because you should never get this one wrong.

In this post from Casper Beyer titled The Node.js Ecosystem Is Chaotic and Insecure, he cites examples like left-pad, is-odd, is-number — and goes on to say the way to be responsible with dependencies is... ...don’t trust package managers, every dependency is written by some random developer somewhere in the world and is a potential attack vector. ... Is this being too paranoid? Perhaps, or maybe it’s the healthy amount considering the massive reach these trivial packages can have. While this focuses on Node.js, the lessons learned apply anywhere you have dependencies in your code.

André Staltz: I’ve just given my third programming talk where I use only my IDE (integrated development environment) for live coding and no other presentation tool. I noticed the audiences were very pleased with these talks, and I think it’s correlated to using an IDE and not a slides program. If you've ever watched one of André's talks, you know he gives good talks regardless of whether or not he's using an IDE. But he makes a good case for their use in general and goes in to great detail* on how to do it well. *even explaining each individual editor setting and why they were selected

Daniel Stenberg joined the show to talk about 20 years of curl, what’s new with http2, and the backstory of QUIC - a new transport designed by Jim Roskind at Google which offers reduced latency compared to that of TCP+TLS+HTTP/2.

Programming around time is the bane of pretty much every programmer's existence. UTC works most of the time, but still has its flaws. Zach Holman writes on his blog: Programming time, dates, timezones, recurring events, leap seconds... everything is pretty terrible. The common refrain in the industry is Just use UTC! Just use UTC! And that's correct...sort of. But if you're stuck building software that deals with time, there's so much more to consider. It's time...to talk about time. Zach includes a lot of time-related puns and whole lot of wisdom about programming time.

Bummer. I've been there. It's so tough to make iterative change to software when those who are "in charge" of what you do everyday keeps interrupting or changing the rules to the game. Sjoerd Nijland writes on the Serious Scrum blog: As Scrum is a framework for developing, delivering, and sustaining complex products, and, if your management isn’t actively engaged in this exercise, it indeed may not make immediate sense for them to adopt the framework. Scrum could thus be perceived to be for developers only. Or perhaps Scrum was introduced by and is still contained to the development organization. In this case it may make sense to talk about the definition of ‘Product’. Would it make sense for the Management Team, to consider the organization itself as a product? If your team does Scrum, you should 100% read this.

I was perusing this popular VS Code feature request yesterday when I spotted a disturbing trend: more than a dozen comments containing nothing more than a +1

Adam is on location at ZEIT Day talking with Jessica Rose about burnout, Henry Zhu about his passions and pursuit of open source, and Simon Willison about data and his passion for interesting datasets in the world.

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.