By now it is clear that the RIAA’s takedown notice backfired badly. With the ‘Streisand Effect’ in full swing, there are now probably more copies of YouTube-DL online than there ever were.
Gergely Orosz shared advice that he’d give to himself 10 years ago. It’s interesting how hindsight is always 20/20…it’s easier to connect the dots looking back vs looking forward.
As I look back to over a decade ago, there are a few things I wish I’d started doing sooner. Habits that could have helped made me grow faster and in a more focused way. This is the advice I’d give my younger self, who has just landed their first professional software engineering job.
1. Take the time to read two books per year on software engineering … Every time I took the time to slowly and thoroughly read a recommended book on software engineering, I leveled up. By properly reading, I mean taking notes, talking chapters through with others, doodle diagrams, trying out, going back, and re-reading…
Antirez on the strange relationship between money, open source, and the code we write on the job:
Open source is different, it’s an artifact, it’s a transposition in code of what you really want to do, of what you feel software should be, or just of all your fun and joy, or even anger you are feeling while coding… It’s not about money. You can ignore bugs if you want, and ignore their complains, you can do that since you don’t have a contract to do otherwise, but they are helping you, they care about the same thing you care: your software quality, grandiosity, perfection.
I enjoyed reading what Anna had to say about the advice she had been given and the process she created for doing introduction one-to-one meetings with her new team.
When I joined the Financial Times as Technical Director for FT.com, I inherited a team of around 50 engineers. One of the first things I did was meet each of them for a one-to-one. I was initially resistant, but it was extremely valuable, I’m glad I did it, and I would definitely do it again in a future role. I ran each meeting in the same way. Firstly I ran through everything I planned to cover, and then stepped through it…
It has become even more clear to me during the era of COVID-19 that poor communication is the reason systems and relationships fail. Every time I’ve failed to get what myself, my team, or a community wanted out of an engineering team was because I neglected to communicate why and how it would be impactful to them in a digestible way.
In this post, I share a few lessons learned as a non-technical launching hardware and software products over the last decade. We’ll explore tactics and skills teams can use to communicate more effectively.
Helping people online is difficult. We expect technical questions and discussions, but everyone involved are just people, so it doesn’t always go smoothly. There’s no way to guarantee a good outcome, but there are things we as helpers can do to improve the interactions.
Ned shares a dozen ways we can work to be more helpful online. Excellent stuff. 👌
Here’s a fun rabbit hole to go down if you have some free time to spend.
After a fellow named Zikubi beat the speedrun record for Super Mario Bros 3 by about 8 minutes with a time of just over three minutes, speedrun analyst Bismuth made the video above to explain how he did it…by changing the game with the gameplay itself.
The first couple minutes go exactly as you’d expect, but the speedrun takes a weird turn when, instead of using the second warp whistle to go to level 8, he uses it to go to level 7. And once in level 7, Mario races around randomly, letting opportunity slip away like a blindfolded birthday boy unwittingly steering himself away from the piñata. It’s only later, during the explanation of how he got from level 7 to the final screen so quickly, that you realize Mario’s panicky idiot behavior is actually the player actively reprogramming the game to open up a wormhole to the ending.
Daniel Moch shared his thoughts on semantic versioning and how he treats external libraries that violate its inherent contract with developers.
So as not to bury the lede, I’ll get to my point: Semantic Versioning is a meta-API, and maintainers who are cavalier about violating it can’t be trusted to created stable contracts. I’ve lost patience for breaking changes making their way to my code bases without the maintainers incrementing the major version of their projects, especially in language ecosystems where Semantic Versioning is expected, and in such cases I’m going to begin exploring alternative options so I can ban such libraries from my projects—personal and professional—altogether.
If you work in a language ecosystem where Semantic Versioning is the de facto norm, where violating it can wreak havoc downstream, then please play nice and follow its dictates. Instead of viewing it as a straight jacket, try to see it as an algorithm to determine what your next release number should be. We should all like algorithms!
Jared Mauch was tired of waiting for high speed internet access to his very rural house in the outskirts of Ann Arbor, MI so he started a telco to get fiber to his town.
Development was happening in and around Ann Arbor putting new subdivisions nearby. I expected broadband would reach my new home eventually (Cable, DSL, FTTx), but…nothing came. I know…start a telco! – source slides
Jared covers everything in this video – the research, planning, finances, pre-builds, getting customers, internet access, construction, contractors, and running all the fiber.
Depending on the project, the impact of biases can be completely different, from insignificant to dangerous for the survival of the project itself. … Come with me, I will show you what our enemy looks like, and how to bring it down with a sharp mind.
Thanks to Tom Larkworthy for putting together this “goldmine of tech resources.” The cool thing is you can play with the data yourself and make your own analysis.
The most favorited articles by the top 10k most active Hacker News members. The list skews toward innovative learning resources and tech career tips, but there is a little of everything.
Data was scraped 2020-09-1 from the public favourites lists. This is an observable notebook with the data attached as a file, so you can fork your own analysis if you don’t like how I did it (e.g. you could find the favorited Ask HN posts).
To calculate the top favourites, I give each member 30 votes to divided over their (max) 30 most recent favourited articles. I sum the votes over all articles. The results are a goldmine of tech resources.
Following Git 2.28’s highly sought after ability to configure
init.defaultBranch comes GitHub’s support at the platform level.
You can now set the default branch name for newly-created repositories under your username. This setting does not impact any of your existing repositories. Existing repositories will continue to have the same default branch they have now.
But even if you do nothing…
On October 1, 2020, if you haven’t changed the default branch for new repositories for your user, organization, or enterprise, it will automatically change from
I’m a bit late to the party on this one (was out on vacay last week), but my oh my did Randall Munroe hit the nail on the head. I have a feeling we’ll be referencing xkcd #2347 for years to come…
Oh, and in case you’re not yet aware, xkcd’s image
title attributes always carry an additional punch-line/comment (which is a brilliant way to make it worth visiting the site each go-around). I’ll save you a click, just this once:
Someday ImageMagick will finally break for good and we’ll have a long period of scrambling as we try to reassemble civilization from the rubble.
Slack and its counterparts ‘create problems, high-school-type problems,’ one CEO said.
What’s your internal Slack like? Does it fuel “drama” or enable greater collaboration? Both…?
Beyond internal politics, executives are also paying attention to how employees use tools like Slack to organize. Workers at companies like Away, Andela, and the New York Times have recently used Slack to put leadership on blast and leaked those conversations to advance their interests. As Slack spreads, this type of action will spread with it. And even the most open companies are unlikely to tolerate it for very long…
BTW, are you on our Slack? Join the community 🤓
Are you craving more of that wisdom you heard from Jessica Kerr on The Changelog #398: The ONE thing every dev should know? Yea me too…here we go…
Software feels more like assembly than craft. What if software used to be a craft? What if the standardization of common tasks in libraries and frameworks means craftsmanship isn’t such a big deal anymore? What matters now is knowledge of all those different materials. Understanding the libraries and frameworks and ecosystems and tools and infrastructure and automation. The implications, considerations, and conglomeration of their use.
What it sounds like Jessica is getting at, is that craftsmanship doesn’t seem to be required for entry anymore in order to thrive as a software developer. But I do believe there is still a place for craftsmanship in software, it’s just not as required as it used to be with the proliferation of standards. What do you think?
Code review is critical to being a software engineer yet there aren’t many resources on how to build up the skill. That’s why Shubheksha wrote what she learned when she first started making the mental shift from writing code to reviewing it.
Remember to be kind and empathetic — Code reviews are very ripe for misunderstanding and lack of empathy on either side. At the heart of code reviews is collaboration. It is as important to remind yourself as a reviewer that you’re reviewing someone’s code and not passing judgments on them as a person and it is equally important to remember that whatever your reviewer tells you is not meant as a personal attack.
ppk muses after digesting Mozilla’s big lay off:
To my mind, Mozilla’s core problem is the cult of the free. To my mind, we should eradicate the cult of the free from web development, and Mozilla should take a small step in that direction by requesting donations from inside Firefox — on an entirely voluntary basis.
This conversation hits close to home for a few reasons here at Changelog.
First, we have plenty of friends and acquaintances who were directly affected. Second, we share concern for the future of these bastions of the web (MDN) and open source (Servo). Finally, we’re a small internet-based business that gives away almost everything we create for free and shares a business model with Mozilla.
Changelog++ might be even more integral to our survival than we’ve been thinking it is….
In a post aptly titled “Tripping over the potholes in too many libraries,” Carl Johnson explains his philosophy on using dependencies.
In short, I think it’s become entirely too easy for people using certain programming languages to use libraries from the wide world of clowns that is the Internet. Their ecosystems make it very very easy to become reliant on this stuff. Trouble is, those libraries are frequently 💩. If something about it is broken, you might not be able to code around it, and may have to actually deal with them to get it fixed. Repeat 100 times, and now you have a real problem brewing.
I have a simple rule: never use a dependency that you could replace with an afternoon of programming.
Today Mitchell Baker, CEO of Mozilla Corporation, shared news of big changes taking place at Mozilla in the wake of COVID-19. In addition to the changes noted below, Mozilla is also laying off 250 employees while it makes these changes.
…going forward we will be smaller. We’ll also be organizing ourselves very differently, acting more quickly and nimbly. We’ll experiment more. We’ll adjust more quickly. We’ll join with allies outside of our organization more often and more effectively. We’ll meet people where they are. We’ll become great at expressing and building our core values into products and programs that speak to today’s issues. We’ll join and build with all those who seek openness, decency, empowerment and common good in online life.
This internal document includes the details about the restructuring and other specifics.
I’ve reached out to Mitchell via LinkedIn messages to invite her on The Changelog for deep dive into the future of the internet. If you or anyone you might know has a direct connection to Mitchell, please pass this invitation on to her — we’d love to have her on the show.
It’s easy to forget that there’s a human on the other side of that
<textarea>. So we tend not to give people the benefit of the doubt on the internet. This post is a gentle reminder of that fact and how active awareness of it would go a long way toward making it a more enjoyable place for all of us.
Leading off the updates for Git 2.28 is the highly sought after ability to configure
init.defaultBranch so folks can move from
main as their default branch name.
From Taylor Blau on the GitHub blog:
When you initialize a new Git repository from scratch with
git init, Git has always created an initial first branch with the name
master. In Git 2.28, a new configuration option,
init.defaultBranchis being introduced to replace the hard-coded term. (For more background on this change, this statement from the Software Freedom Conservancy is an excellent place to look).
Starting in Git 2.28,
git initwill instead look to the value of
init.defaultBranchwhen creating the first branch in a new repository. If that value is unset,
A new study from North Carolina State University and Microsoft finds that the technical interviews currently used in hiring for many software engineering positions test whether a job candidate has performance anxiety rather than whether the candidate is competent at coding. The interviews may also be used to exclude groups or favor specific job candidates.
What’s more, the specific nature of the technical interview process means that many job candidates try to spend weeks or months training specifically for the technical interview, rather than for the actual job they’d be doing.
Be careful out there.
I believe that there is a unique group dynamic that forms and causes the rot of software groups in a way that can’t be explained by bad external decisions causing the talented developers to evaporate … In this post, I’m going to set the stage by describing how individuals opt into permanent mediocrity and reap rewards for doing so.
A must-read piece for anyone in danger of getting stuck in the “Expert Beginner” loop.
… during these years, the software developers are job-hopping and earning promotions, especially these days. As they breeze through rapid acquisition, so too do they breeze through titles like Software Engineer I and II and then maybe “Associate” and “Senior,” and perhaps eventually on up to “Lead” and “Architect” and “Principal.” So while in the throes of Dunning-Kruger and Advanced Beginnerism, they’re being given expert-sounding titles and told that they’re “rock stars” and “ninjas” and whatever by recruiters–especially in today’s economy. The only thing stopping them from taking the natural step into the Expert Beginner stage is a combination of peer review and interaction with the development community at large.
Ah, the classic mis-alignment of value to LOCs. How have you responded to this type of question or scenario?
Why did a fix that seems so simple when looking at the changes made take two days to complete?
Because I took the time to investigate the real cause of the issue, not just looking at the symptoms. If some code is throwing an error, you could just wrap it in a
try..catchstatement and suppress the error. No error, no problem. Right? Sorry, for me, making the problem invisible isn’t the same as fixing it. “Swallowing” an error can easily lead to other unexpected side-effects. I don’t want to have to deal with them at a point in the future.