KBall and Jerod digest and disect recent JS community news (React 18, Redwood 1.0, MDN Plus) then sit down for yet another game of HeadLIES! Can KBall fare better than Nick Nisi did last April Fools?!
Well, that is the single largest expense we have. If we want to optimize anything in our discipline we should look at this part first. We talk often about how we build systems, but how often do you talk about how you spend the “figuring out” time? If we do not talk about it, it’s not explicit. If it’s not explicit, it does not get optimized.
In addition to the author’s suggested solution to this problem allow me to add: developer retention! Nobody has more to figure out in a system than the people who just joined the team. Cut down on that (via better compensation, workplace satisfaction, etc.) and you cut way down on that oh so expensive “figuring out” time.
The incomparable Jessica Kerr is back with another grab-bag of amazing topics. We talk about her journey to Honeycomb, devs getting satisfaction from the code they write, why step one for her is “get that new project into production” and step two is observe it, her angst for the context switching around pull requests, some awesome book recommendations, how game theory and design can translate to how we skill up and level up our teams, and so much more.
Daniel and Chris talk with Lukas Egger, Head of Innovation Office and Strategic Projects at SAP Business Process Intelligence. Lukas describes what it takes to bring a culture of innovation into an organization, and how to infuse product development with that innovation culture. He also offers suggestions for how to mitigate challenges and blockers.
Last year, TikTokker Avery Steeves posted a video asking why no one talks about how there’s an entire generation of teenage girls who taught themselves to code HTML on Tumblr. “People are like, ‘Oh, there’s no girls in STEM,’” she says, imitating the faceless internet mob. “No, there were! They were just making pale blogs.”
OK so we don’t usually link to Mashable (first time ever?), but this was cool news to me, so I thought it was worth passing along. Long live HTML!
Rands asking himself some tough questions about our “new normal” remote work environments:
Relative to the Pandemic, the single biggest work question I’ve been asking myself for two years is: what did we lose? What is the measurable and objective loss for teams not working in close proximity? I’ve been looking for cracks. I’ve been looking for leading indicators of future doom. The Great Resignation seems like a proper crack, right? But are people quitting their jobs because they can’t work together or because their current job sucks and all this terror in the air has given them a new appreciation of what really matters?
A sobering perspective.
Old as in old school cool not old as in passe:
Despite the new gatekeepers’ best efforts, the old Internet never completely disappeared. Personal websites created by individuals that have always been the meat of the old Internet are still around. They are still about exploration, innovation, fun, and all the rest. Try as the new gatekeepers have, they simply have not had the power to eradicate the old Internet completely. All they can do is pretend it does not exist. And, that is exactly what they do.
… the old Internet seems to be slowly and quietly coming back, and it is coming back even better than before. Now it has better technology and an additional well-defined purpose that it never had before.
Some people have begun to refer to personal websites as the “indie web”, the “small Internet”, or the “smol Internet”. Some seem to reserve the last two terms exclusively for the Gemini Network, which nearly quadrupled in size last year. But, I think all three terms should also apply to some of the other networks that use alternative networking protocols–the Gopher Network, the Tor network, and the ZeroNet network, to name a few.
We laugh so that we do not have time to cry. (via Zachary Taylor in our community Slack)
Today we’re bringing our appearance on DevDiscuss right here to The Changelog. Jerod and I guested their launch episode for Season 7 to talk about deeply human stories we’ve covered over the years on this podcast. For long-time listners this will be a trip down memory lane and for recent subscibers this will be a guided tour on some of our most impactful episodes. Special thanks to Ben Halpern and Christina Gorton for hosting us. Check out their show at dev.to/devdiscuss
Milosz Danczak shares a principle that was surely born from years of painful experiences:
When committing to a piece of software, favor those created by people who value backward compatibility.
But how can you tell if a piece of software is likely to remain stable? Milosz also provides some heuristics you can apply when evaluating a project.
This week we are joined by Sophie Alpert, Head of Engineering at Humu, and former lead of the React Core team, to discuss her experience on being a very early adopter, contributor, and eventually maintainer of React. In her 4+ years on the Core team, she went from supporting a new niche OSS UI library to supporting a project used by millions of developers around the world. Join us to hear about this epic journey, as well as Sophie’s thought’s on some common critiques and misconceptions of React.
Overdoing things can have a deep mental impact, one should not feel guilty about giving up on something. It’s the same with pursuing side-projects don’t hesitate to abandon them if the need arises
We’re “doing it live” with Jerome Hardaway, a Senior Software Engineer at Microsoft and the Executive Director of Vets Who Code — a veteran-led and operated 501(c)(3) non-profit organization that focuses on training veterans, active duty military, and military spouses in software development and open source with the goal of starting careers in the technology industry.
This is a lengthly conversation in and around Jerome’s story, the Vets Who Code mission and impact, the experience of being in the United States Military, and the opportunity and potential of 1.5x’ing one of the most elite group of people on the planet.
Today we’re joined by Shawn “swyx” Wang, also known as just “swyx” — and we’re talking about his interesting path to becoming a software developer, what it means to “learn in public” and how he’s been able to leverage that process to not only level up his skills and knowlege, but to also rapidly advance his career. We cover Swyx’s recent writing on the light and dark side of the API economy — something he calls “living above or below the API,” his thoughts on Cloudflare eating the cloud by playing Go instead of Chess, and we also talk about the work he’s doing at Temporal and how’s taking his frontend skills to the backend.
This is a short post by long-time open source maintainer Chris Manson about commitment to tasks in the open source world and how life always takes priority over dev.
We always need to keep in mind that most open source contributions are given from people that are opting to give up their spare time (usually for free) and the level of expectation can never come anywhere close to the sort of relationship that an employer might have with an employee or contractor.
Pairs well with Every commit is a gift. 🍷
GitHub’s ReadME project did a nice job re-telling the story of why the lucky stiff and his enduring impact on open source developers around the world.
This week we’re joined by Gergely Orosz and we’re talking about the insane tech hiring market we’re in right now. Gergely was on the show a year ago talking about growing as a software engineer and his book The Tech Resume Inside Out. Now he’s laser focused on Substack with actionable advice for engineering managers and engineers, with a focus on big tech and high-growth startups. On today’s show we dig into his recent coverage of “the perfect storm” that’s causing this insane tech hiring market.
On April 30th, 2021, I rickrolled my high school district. Not just my school but the entirety of Township High School District 214. It’s the second-largest high school district in Illinois, consisting of 6 different schools with over 11,000 enrolled students.
Who doesn’t like a good rickroll story? This one’s replete with screencaps and video footage
Bryan Braughn has been making good use of his Checkboxland library (which makes it easy to display text and animations on a grid of checkboxes). He’s made games, image transfers, and even videos like the one below. But then, some introspection:
This whole process has been fun but I really ought to stop.
I got nerd sniped, hard. Sure it’s harmless fun, but I’m starting to feel guilty spending months tinkering on these things when I’ve got the tools and skills to put actually useful stuff into the world. I feel like Superman, using his powers to fry an egg.
I understand where he’s coming from, but I also believe experiments like Bryan’s are what make the web great and when they inspire someone else to build something, they are absolutely “actually useful stuff”. Don’t you?
This post is a confession of an “egocentric maniac” (his words) and how damaging code review can be:
This review I kicked off the article with? I didn’t send it. Instead I gave the guy a couple of comments and politely asked to fix a couple of things. No big deal if the code’s not good, I can fix it myself it I need to. But I can’t fix the psyche of a guy broken by dozens of harsh reviews.
My personality today isn’t my disease. It’s a disease of the whole industry, at least in Russia. Our mentality is predicated on the cult of power and superiority. And that’s what we need to fix: just stop being that. It’s quite easy, actually.
The author of this site handed a neural network brief text descriptions of a bunch of movies and let it generate image that represent each. Read how he did it or just have fun trying to guess the movie titles from the images. Harder than I thought it’d be!
A (short) must-read piece from rachelbythebay:
“Everyone knows” that code is something you type into a computer, that gets interpreted by a computer, and is run by a computer. But that’s not really the end of it. Before that, it’s being “run” on whoever’s working on it. After that, it’s “running” on whoever’s digging into it to fix a bug or add some feature.
You can throw all kinds of wicked, nasty, complicated, Klein-bottle-wannabe tricks into code and the computer will shrug and slog on through it.
Try feeding that same mess to a human and you will have a variety of problems. We see them every day, and, unfortunately, we /create/ them every day.
I’ve often wondered this as well. My conclusion, after not thinking too deeply about the issue, was that it’s a combination of the difficulty in match making and poor tooling. (There are many startups trying to solve those problems, but it doesn’t seem like anybody has cracked the nut yet).
There’s lots of wisdom in this post by Curt Corginia:
A wise, mature person would treat the software engineer interview process as a pure learning experience. He, or she, would enjoy learning about companies out there for the sake of research, interacting with key players, and mastering the art of whiteboarding. It would just be like a fun game.
I don’t think of it like that, but a mature person would. Do what I say, not what I do.
Yes, to all of this! Dave Bailey, author of The Founder Coach, shared ten useful patterns to help nurture more generous interpretations of others’ behaviors.
Reading this makes me really miss producing Brain Science.
When we encounter emotions and behaviours that don’t make sense to us, it’s often because we don’t have all the information. And in the absence of information, we tend to assume the worst.
‘Emotional generosity’ is the ability to see past behaviours that we don’t understand and proactively look for compassionate ways to explain them. It’s easy to do this for young children. If they start crying or throwing a tantrum, we wonder whether they are hungry, or tired, or hurt. Sadly, it’s harder to do this for adults — and especially our co-workers. And yet a more generous interpretation of their difficult behaviour often ends up being right.