<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Software Engineering on A Blog for the Uninitialized</title><link>https://www.nilpointer.blog/tags/software-engineering/</link><description>Recent content in Software Engineering on A Blog for the Uninitialized</description><generator>Hugo</generator><language>en-us</language><copyright>&lt;a href="https://www.apache.org/licenses/LICENSE-2.0" target="_blank" rel="noopener"&gt;Licensed under Apache 2.0&lt;/a&gt;</copyright><lastBuildDate>Fri, 04 Sep 2026 14:46:37 -0700</lastBuildDate><atom:link href="https://www.nilpointer.blog/tags/software-engineering/index.xml" rel="self" type="application/rss+xml"/><item><title>Social Acceptance of Large Scale Changes</title><link>https://www.nilpointer.blog/posts/2026/09/social-acceptance-of-large-scale-changes/</link><pubDate>Fri, 04 Sep 2026 14:46:37 -0700</pubDate><guid>https://www.nilpointer.blog/posts/2026/09/social-acceptance-of-large-scale-changes/</guid><description>&lt;p&gt;I started reading through a book posted online called &lt;a href="https://abseil.io/resources/swe-book"
 
 
 target="_blank" 
 rel="noopener noreferrer"
 
&gt;Software Engineering at Google&lt;/a&gt;, written in March of 2020 (truly a fateful time in all of our lives).&lt;/p&gt;
&lt;p&gt;It&amp;rsquo;s an O&amp;rsquo;Reilly book, too, which you can purchase here if you&amp;rsquo;re interested (&lt;a href="https://www.amazon.com/gp/product/1492082791?tag=bicyclewate08-20"
 
 
 target="_blank" 
 rel="noopener noreferrer"
 
&gt;affiliate link&lt;/a&gt;).&lt;/p&gt;
&lt;p&gt;In particular, I&amp;rsquo;ve started with chapter 22, which discusses &amp;ldquo;Large Scale Changes&amp;rdquo; or LSC&amp;rsquo;s for short. The intention behind it is to discuss how Google&amp;rsquo;s monorepo works when it comes to making changes that span across multiple projects.&lt;/p&gt;</description></item><item><title>Should dependencies always be kept up to date?</title><link>https://www.nilpointer.blog/posts/2026/05/should-dependencies-always-be-kept-up-to-date/</link><pubDate>Tue, 19 May 2026 17:21:43 -0700</pubDate><guid>https://www.nilpointer.blog/posts/2026/05/should-dependencies-always-be-kept-up-to-date/</guid><description>&lt;p&gt;Something came up at work today related to the topic &lt;a href="https://www.nilpointer.blog/posts/2026/05/just-because-you-can-doesnt-mean-you-should/"
 
 
&gt;I discussed yesterday&lt;/a&gt;.&lt;/p&gt;
&lt;p&gt;&lt;strong&gt;Should dependencies always be kept up to date?&lt;/strong&gt;&lt;/p&gt;
&lt;p&gt;I work in the Developer Experience (DevX) realm right now, and the current perspective on handling the potential security concerns that &lt;a href="https://red.anthropic.com/2026/mythos-preview/"
 
 
 target="_blank" 
 rel="noopener noreferrer"
 
&gt;Mythos&lt;/a&gt; is highlighting is that we should immediately update all code (third party) dependencies to their respective, latest versions.&lt;/p&gt;
&lt;p&gt;While that perspective is valid for my company right now (there&amp;rsquo;s so much more to the story there), this isn&amp;rsquo;t always a valid perspective to take.&lt;/p&gt;</description></item></channel></rss>