CSS Refactoring With an AI Safety Net, by (not on Mastodon or Bluesky):

https://danielabaron.me/blog/css-refactoring-with-an-ai-safety-net/

#css #refactoring #testing #ai

SPFx State Management: Solving State Complexity in the SharePoint Framework

2,018 words, 11 minutes read time.

A Helping Hand Needed for a Fellow Programmer

I’m reaching out to see if you can lend a hand to a talented software developer who’s currently on the job hunt. With over 30 years of experience in C#, .NET (Core/6–8), REST APIs, SQL Server, Angular/Razor, Kubernetes, and cloud CI/CD, he’s a seasoned pro with a proven track record of leading modernization projects and delivering production systems.

Some of his notable accomplishments include DB2 to SQL migrations, building real-time SignalR apps, and developing full-stack API and frontend projects. Based in Southeast Michigan, he’s looking for senior engineering, architecture, or technical lead roles that will challenge him and utilize his skills.

If you’re in a position to help, you can check out his resume and portfolio at http://charles.friasteam.com.

Let’s all look out for each other – if you know of any opportunities that might be a good fit, could you please consider passing this along to your network?

—

The Evolution of State in the SharePoint Framework

The transition from the “Classic” SharePoint era to the modern SharePoint Framework (SPFx) represents more than just a change in tooling; it marks a fundamental shift in how developers must manage data persistence and component synchronization. In the early days of client-side customization, state was often handled implicitly through the DOM or global variables, a practice that led to fragile, difficult-to-maintain scripts. Today, as we build sophisticated, multi-layered applications using React and TypeScript, state management has become the primary determinant of application stability and performance. Within a shared environment like SharePoint Online, where a single page may host multiple independent web parts, the complexity of managing shared data—such as user profiles, list items, and configuration settings—requires a disciplined architectural approach. Failing to implement a robust state strategy often results in “jank,” data inconsistency, and a bloated memory footprint that negatively impacts the end-user experience.

When developers rely solely on localized state within individual components, they often inadvertently create “data silos.” This fragmentation becomes evident when a change in one part of the application—for example, a status update in a details pane—is not reflected in a summary dashboard elsewhere on the page. To solve this, developers must move beyond basic reactivity and toward a model of “deterministic data flow.” This means ensuring that every piece of data has a clear, single source of truth and that updates propagate through the application in a predictable manner. By treating state management as a core engineering pillar rather than a secondary concern, teams can build SPFx solutions that are resilient to the inherent volatility of the browser environment and the frequent updates of the Microsoft 365 platform.

Evaluating Local Component State vs. Centralized Architectures

The most common architectural question in SPFx development is determining when to move beyond React’s built-in useState and props in favor of a centralized store. For simple web parts with a shallow component tree, localized state is often the most performant and maintainable choice. It offers low overhead, high readability, and utilizes React’s core strengths without additional boilerplate. However, as an application grows in complexity, the limitations of this “bottom-up” approach become clear. “Prop-drilling”—the practice of passing data through multiple layers of intermediate components that do not require the data themselves—creates a rigid and fragile structure. This not only makes refactoring difficult but also complicates the debugging process, as tracing the origin of a state change requires navigating through an increasingly complex web of interfaces and callbacks.

// Example: The complexity of Prop-Drilling in a deep component tree
// This architecture becomes difficult to maintain as the application scales.
interface IAppProps {
  currentUser: ISiteUser;
  items: IListItem[];
  onItemUpdate: (id: number) => void;
}
const ParentComponent: React.FC<IAppProps> = (props) => {
  return <IntermediateLayer {...props} />;
};
const IntermediateLayer: React.FC<IAppProps> = (props) => {
  // This component doesn't use the props, but must pass them down.
  return <DeepChildComponent {...props} />;
};
const DeepChildComponent: React.FC<IAppProps> = ({ items, onItemUpdate }) => {
  return (
    <div>
      {items.map(item => (
        <button onClick={() => onItemUpdate(item.Id)}>{item.Title}</button>
      ))}
    </div>
  );
};

A centralized state architecture solves this by providing a dedicated layer for data management that exists outside the UI hierarchy. This decoupling allows components to remain “dumb” and focused purely on rendering, while a service layer or store handles the business logic, API calls via PnPjs, and data caching. From a performance perspective, centralized stores that utilize selectors can significantly reduce unnecessary re-renders. Unlike the React Context API, which may trigger a full-tree re-render upon any change to the provider’s value, advanced state managers allow components to subscribe to specific “slices” of data. This granular control is essential for maintaining a high frame rate and responsive UI in complex SharePoint environments where main-thread resources are at a premium.

Implementing the Singleton Service Pattern for Data Consistency

To move beyond the limitations of component-bound logic, lead developers often implement a Singleton Service pattern. This approach centralizes all interactions with the SharePoint REST API or Microsoft Graph into a single, predictable instance that manages its own internal state. By utilizing this pattern, you effectively decouple the Microsoft 365 environment from your React view layer, ensuring that your data fetching logic is not subject to the mounting or unmounting cycles of individual components. In a high-traffic SharePoint tenant, this architecture allows for aggressive caching strategies; the service can determine whether to return an existing array of list items from memory or to initiate a new asynchronous request via PnPjs. This significantly reduces the network overhead and prevents the “double-fetching” phenomenon often seen when multiple web parts or components request the same user profile or configuration data simultaneously.

// Implementing a Singleton Data Service with PnPjs
import { spfi, SPFI, SPFx } from "@pnp/sp";
import "@pnp/sp/webs";
import "@pnp/sp/lists";
import "@pnp/sp/items";
export class SharePointDataService {
  private static _instance: SharePointDataService;
  private _sp: SPFI;
  private _cache: Map<string, any> = new Map();
  private constructor(context: any) {
    this._sp = spfi().using(SPFx(context));
  }
  public static getInstance(context?: any): SharePointDataService {
    if (!this._instance && context) {
      this._instance = new SharePointDataService(context);
    }
    return this._instance;
  }
  public async getListItems(listName: string): Promise<any[]> {
    if (this._cache.has(listName)) {
      return this._cache.get(listName);
    }
    const items = await this._sp.web.lists.getByTitle(listName).items();
    this._cache.set(listName, items);
    return items;
  }
}

The strength of this pattern lies in its ability to maintain data integrity across the entire SPFx web part lifecycle. When a user performs a write operation—such as updating a list item—the service handles the PnPjs call and then immediately updates its internal cache. Any component subscribed to this service or re-invoking its methods will receive the updated data without needing a full page refresh. This creates a highly responsive, “app-like” feel within the SharePoint interface. Furthermore, because the state is held in a standard TypeScript class rather than a React hook, the logic remains testable in isolation. You can write unit tests for your data mutations without the overhead of rendering a DOM or simulating a React environment, which is a critical requirement for enterprise-grade software delivery.

Advanced Patterns: Integrating Redux Toolkit for Multi-Web Part Coordination

For the most complex SharePoint applications—those involving multi-step forms, real-time dashboards, or coordination across several web parts—Redux Toolkit (RTK) provides the industrial-grade infrastructure necessary to manage state at scale. RTK standardizes the “reducer” pattern, ensuring that every state mutation is performed through a dispatched action. This unidirectional flow is vital in the SharePoint Framework because it eliminates the unpredictable side effects associated with shared mutable state. By defining “slices” for different domains, such as a ProjectSlice or a UserSlice, you create a modular architecture where each part of the state is governed by specific logic. This modularity is particularly useful when managing complex asynchronous lifecycles; RTK’s createAsyncThunk allows you to track the exact status of a SharePoint API call—pending, fulfilled, or rejected—and update the UI accordingly.

// Redux Toolkit Slice for managing SharePoint List State
import { createSlice, createAsyncThunk } from '@reduxjs/toolkit';
import { SharePointDataService } from './SharePointDataService';
export const fetchItems = createAsyncThunk(
  'list/fetchItems',
  async (listName: string) => {
    const service = SharePointDataService.getInstance();
    return await service.getListItems(listName);
  }
);
const listSlice = createSlice({
  name: 'sharepointList',
  initialState: { items: [], status: 'idle', error: null },
  reducers: {},
  extraReducers: (builder) => {
    builder
      .addCase(fetchItems.pending, (state) => {
        state.status = 'loading';
      })
      .addCase(fetchItems.fulfilled, (state, action) => {
        state.status = 'succeeded';
        state.items = action.payload;
      })
      .addCase(fetchItems.rejected, (state, action) => {
        state.status = 'failed';
        state.error = action.error.message;
      });
  },
});

One of the primary advantages of utilizing Redux in an SPFx context is the ability to leverage the Redux DevTools browser extension. In a complex tenant where multiple scripts and web parts are competing for resources, being able to “time-travel” through your state changes allows you to see exactly when and why a piece of data changed. This transparency is invaluable for debugging race conditions that occur when multiple asynchronous SharePoint requests return out of order. Furthermore, RTK allows for the implementation of persistent state. By utilizing middleware, you can sync your Redux store to the browser’s localStorage or sessionStorage, ensuring that if a user accidentally refreshes the SharePoint page, their progress in a complex task is hydrated back into the application immediately. This level of sophistication transforms a standard SharePoint web part into a robust enterprise application.

Performance Benchmarking: Minimizing Re-renders in Large-Scale Apps

Maintaining a high-performance SPFx web part requires more than just functional state; it requires an understanding of the browser’s main thread and the cost of the React reconciliation process. In a SharePoint page, your web part is often competing with dozens of other Microsoft-native scripts and third-party extensions. If your state management strategy triggers global re-renders for minor data updates, you are effectively starving the browser of the resources needed to remain responsive. Performance benchmarking reveals that the React Context API, while convenient, is frequently the culprit behind significant “jank” in large-scale apps. Because a Context Provider notifies all consumers of a change, even a simple toggle of a UI theme can force a massive, expensive re-evaluation of a complex data grid.

To solve this, professional SPFx development necessitates the use of tactical optimizations such as memoization and selective rendering. By utilizing React.memo for functional components and useMemo or useCallback for expensive computations and event handlers, you ensure that components only re-render when their specific slice of data has changed. Furthermore, when using a centralized store like Redux or a custom Observable service, you should implement granular selectors. These selectors act as guards, preventing the UI from reacting to state changes that do not directly affect the visible output. Benchmarking these optimizations in a production tenant often shows a reduction in scripting time by 30% to 50%, which is the difference between a web part that feels native to SharePoint and one that feels like an external burden on the page.

// Optimization: Using Selectors and Memoization to prevent over-rendering
import React, { useMemo } from 'react';
import { useSelector } from 'react-redux';
export const ExpensiveDataGrid: React.FC = () => {
  // Use a selector to grab only the necessary slice of state
  const items = useSelector((state: any) => state.list.items);
  const status = useSelector((state: any) => state.list.status);
  // Memoize expensive calculations to prevent re-computation on every render
  const processedData = useMemo(() => {
    return items.filter(item => item.IsActive).sort((a, b) => b.Id - a.Id);
  }, [items]);
  if (status === 'loading') return <div className="shimmer" />;
  return (
    <table>
      {processedData.map(item => (
        <tr key={item.Id}><td>{item.Title}</td></tr>
      ))}
    </table>
  );
};
// Wrap in React.memo to prevent re-renders if parent state changes but props don't
export default React.memo(ExpensiveDataGrid);

Conclusion: Establishing an Organizational Standard for State

Solving state complexity in the SharePoint Framework is not about finding a “one-size-fits-all” library, but about establishing an engineering standard that prioritizes predictability and performance. Whether your team settles on the explicit simplicity of props, the robustness of a Singleton Service, or the industrial scale of Redux Toolkit, the choice must be documented and enforced across the codebase. A standardized state architecture reduces the cognitive load on developers, accelerates the onboarding process for new team members, and ensures that the custom solutions you deliver to your organization are maintainable long after the initial deployment.

As the Microsoft 365 ecosystem continues to evolve, the web parts that survive are those built on sound architectural principles rather than short-term convenience. By decoupling your business logic from the UI and managing your data lifecycle with precision, you create applications that are not only faster and more reliable but also significantly easier to extend. In the high-stakes environment of enterprise SharePoint development, architectural discipline is the ultimate competitive advantage. It allows you to transform a collection of disparate components into a cohesive, high-performance system that meets the rigorous demands of the modern digital workplace.

Call to Action

If this post sparked your creativity, don’t just scroll past. Join the community of makers and tinkerers—people turning ideas into reality with 3D printing. Subscribe for more 3D printing guides and projects, drop a comment sharing what you’re printing, or reach out and tell me about your latest project. Let’s build together.

D. Bryan King

Sources

• Microsoft Learn: SPFx Performance Optimization
• PnPjs Official Documentation
• React Documentation: Scaling State Management
• Redux Toolkit: Official Best Practices
• Fluent UI: Performance Guidance for Large Lists
• Google Developers: Core Web Vitals and Main Thread Activity
• Microsoft: Choosing the Right Framework for SPFx
• CISA: Software Memory Safety and Architecture
• SharePoint PnP Community Web Part Samples
• TypeScript: Structural Type Systems in Large Apps
• React: Optimizing Re-renders with useMemo
• Microsoft: Enterprise Guidance for SPFx Development

Disclaimer:

The views and opinions expressed in this post are solely those of the author. The information provided is based on personal research, experience, and understanding of the subject matter at the time of writing. Readers should consult relevant experts or authorities for specific guidance related to their unique situations.

Related Posts

Rate this:

#AsynchronousState #BrowserMainThread #cachingStrategies #ClientSideDevelopment #CodeMaintainability #ComponentSynchronization #createAsyncThunk #DataConsistency #DataSilos #debuggingSPFx #DeterministicDataFlow #DOMThrashing #EnterpriseApps #EnterpriseArchitecture #EventEmitter #frontEndArchitecture #Hydration #LeadDeveloperGuide #MainThreadOptimization #memoization #MemoryFootprint #Microsoft365Development #MicrosoftGraph #Middleware #MultiWebPartCommunication #NetworkOverhead #OrganizationalStandards #PerformanceBenchmarking #PnPjs #PropDrilling #ReactContextAPI #ReactHooks #ReactReRenders #ReactState #ReduxDevTools #ReduxToolkitSPFx #refactoring #SelectiveRendering #SeniorDeveloperPatterns #SharePointDevelopment #SharePointFramework #SharePointRESTAPI #SingletonServicePattern #softwareEngineering #SPFxStateManagement #StateHydration #StatePersistence #StateScalability #StoreSelectors #technicalDebt #ThreadSafeServices #TypeScript #UIResponsiveness #UnidirectionalDataFlow #UnitTestingSPFx #useCallback #useMemo #webPartLifecycle #webPartPerformance

🚀 just uploaded (link in reply): Imperative Bowling Kata - 20 Years On - Delegating Menial Tasks to Github Copilot Chat - using Scala in IntelliJ IDEA #scala #TDD #refactoring #github_copilot #code_kata
@scala_lang

Notes for March 23–29

Work ate the week again. I’m exhausted, running on fumes, and daylight saving time stole an hour of sleep I could not afford–the biannual clock shuffle is one of those vestigial ab(...)

#agents #ai #arm64 #autoresearch #basiliskii #dev #jit #macemu #notes #refactoring #sheepshaver #weekly

https://taoofmac.com/space/notes/2026/03/29/1300?utm_content=atom&utm_source=mastodon&utm_medium=social

Alt...

Notes for March 23–29

Technische Schulden sind eines dieser Begriffe, die du früh hörst und erst später wirklich spürst. Gemeint ist kein “Fehler”, sondern eine bewusste oder unbewusste Abkürzung im Code oder in der Architektur, die dir heute Zeit spart und dich morgen Zeit kostet. Wie bei einem Kredit: Du bekom

https://magicmarcy.de/technische-schulden-im-alltag-erkennen-vermeiden-abbauen

#Schulden #Technische_Schulden #Refactoring #Programming #Java #KISS #Architektur #Wartbarkeit

We organise in the open, and you're very welcome to chat with the organisers to help, ask questions, give feedback, or simply to watch. You can reach us on the #ev_socratesuk slack channel (https://slack.softwarecrafters.org/), or on mastodon, LinkedIn, BlueSky, or by emailing organisers at socratesuk dot org.

#SoftwareCraft
#Unconference
#OpenSpace
#TDD
#Refactoring

We organise in the open, and you're very welcome to chat with the organisers to help, ask questions, give feedback, or simply to watch. You can reach us on the #ev_socratesuk slack channel (https://slack.softwarecrafters.org/), or on mastodon, LinkedIn, BlueSky, or by emailing organisers at socratesuk dot org.

#SoftwareCraft
#Unconference
#OpenSpace
#TDD
#Refactoring

Join me and the Seattle Software Crafters group for my talk on "Refactoring Tests"!

The talk starts at 10am PDT (5pm UTC), but you can join 30 minutes earlier to chat.

https://www.meetup.com/seattle-software-craftsmanship/events/310497363/

#Refactoring #AssertJ #JUnit #Testing

Refactoring Eleventy with Swisscom MyAI

Table of Contents

1. A testament to MyAI’s Improvement
2. Early Adopter with Pro
3. Asking for Clarity
4. AI As Micromanager
1. MyAI personal Summary
2. Self-Perception
1. Performance Refactoring
2. Data Quality Refactoring
5. And Finally

Yesterday afternoon I decided to experiment with MyAI and Eleventy because I was getting an error message. The issue is that when I refactored my Eleventy files with Gemini it removed code that broke the build process. I asked MyAI for help and it went beyond what I asked of it. Specifically, not only did it help me to fix the bug but it also helped me go from a build time of 35+ seconds, down to 25 seconds, and eventually down to 15 seconds. When you’re running build for each blog post that soon saves a lot of time.

A testament to MyAI’s Improvement

When I started playing with MyAI several months ago it felt quite limited, but yesterday the opposite is true. Today it feels as though MyAI could be serious competition for the US based AI options.

Early Adopter with Pro

It’s worth noting that because I signed up for MyAI Pro as an early adopter I was included within the MyAI Pro free of charge until 31.12.2026. When I was about to unsubscribe from pro I noticed the “free” opportunity and grabbed it.

It’s worth noting that I was using the fast bunny mode, not the “thoughtful pro” mode.

Asking for Clarity

I like that the model didn’t seem to hallucinate. I especially like that it asked for file A, and when it saw references to file B and C it asked for those, to understand the context of the code I was working with. As a result it kept things tidy and within scope.
It noticed loops that were called thousands of times, wastefully, and it refactored and optimised them with a minimum of effort.

When Gemini saw the legacy code in Latin-8 it wanted to create to go through all of the blog posts on each build. As a human I thought “let’s do this just once”, but not Gemini. MyAI created a file, and within a few iterations it had fixed all of the errors. In one case we used a SED command for a single exception.

The result was clean markdown, and a far more efficient build process.

When it noticed that reading time was called several thousand times it refactored the code so that it was mapped, and thus called half as often.

AI As Micromanager

Working with AI is quite ironic. Last night, when I was pair coding with MyAI there was a moment when I thought, “It’s behaving like a boss with it’s ‘now change this, and that, and then these two things’.” We could almost say that MyAI was micromanaging me. In the end, when we had fixed the reading time problem I told MyAI “It’s 18:57, I’m calling it a day” and MyAI said “See you tomorrow — the ‘image’ shortcode is next.”

MyAI personal Summary

Great progress today:

? Fixed encoding in 443+ source files
? Cleaned up filters.js with proper memoization
? Moved excerpt to computed data
? Eliminated the O(n2)O(n^2)O(n2) related posts loop
? Removed redundant readingTime from base.njk

Self-Perception

When asked whether we had refactored its response was:

Performance Refactoring

Moving expensive operations out of render loops
Precomputing data at build time instead of runtime
Memoizing repeated filter calls

Data Quality Refactoring

Fixing encoding at the source rather than patching it at render time

The classic definition applies perfectly here:

“Improving the internal structure of code without changing its external behaviour”

And Finally

This was a positive experience for me. The character of the AI agent didn’t get on my nerves like Gemini often does, and I didn’t hit the token wall like I do with Euria, Claude and other solutions and that does make a difference, when you can make real progress. It’s also worth noting that I was using the fast, which I assume is the free option, rather than the “thoughtful pro” model.

What I saw yesterday afternoon, into the evening, leads me to believe that MyAI will be a useful companion for AI related tasks.

We organise in the open, and you're very welcome to chat with the organisers to help, ask questions, give feedback, or simply to watch. You can reach us on the #ev_socratesuk slack channel (https://slack.softwarecrafters.org/), or on mastodon, LinkedIn, BlueSky, or by emailing organisers at socratesuk dot org.

#SoftwareCraft
#Unconference
#OpenSpace
#TDD
#Refactoring

How do you manage large-scale code migrations across a massive codebase?

At #Spotify, the answer is Honk - an internal AI-powered coding agent - currently merging 1,000 pull requests every 10 days!

Read more on #InfoQ ⇨ https://bit.ly/4rZExaF

#SoftwareDevelopment #AIassistedCoding #Refactoring

Welcome to the Leanpub Launch video for Craft Your Code: Mastering the Foundations of Code Quality in the Era of AI Assistants, Second Edition by Srihari Sridharan!

Watch & read on the Leanpub blog here:

https://leanpub.com/blog/leanpub-book-launch-craft-your-code-mastering-the-foundations-of-code-quality-in-the-era-of-ai-assistants-second-edition-by-srihari-sridharan

#books #leanpublishing #selfpublishing #booklaunch #coding #programming #softwareengineering #career #refactoring #nodejs

Leanpub Book LAUNCH 🚀 Craft Your Code: Mastering the Foundations of Code Quality in the Era of AI Assistants, Second Edition by Srihari Sridharan

Watch here:

https://youtu.be/WjWRbaaXtF0

#books #leanpublishing #selfpublishing #booklaunch #coding #programming #softwareengineering #career #refactoring #nodejs

Refactoring and (A)I

Table of Contents

1. Scope Windows and AI
2. Gemini and Git
1. Why Entrust Git rather than AI?
2. The AI Negative Feedback Loop
3. Git and a Fresh Chat
4. AI driven Refactoring Lessons Learned
1. If Logic Works, Embed It
5. And Finally

For two days I have been migrating my blog from Hugo to Eleventy via the markdown pages, and the photos via Ghost Export for WordPress. In the process I achieved a goal, and then AI broke things, so I achieved them again, and then AI broke them again.

The favourite thing for Ai, and Gemini, in particular to break was the logic that took the markdown titles, matched them to a json file, and then helped 11ty marry the photo with the correct post. When it worked it was brilliant, but when it broke I would spend half a day trying to fix it. By the third time this happened I decided to ask Gemini to help me write a script to hard code the image path straight into markdown pages.

That step was a resounding success. The logic is simple. AI is great for a simple question, but as soon as you start a russian doll/inception of steps the context window, or scope window, to use a programming term gets confused.

Scope Windows and AI

I saw the term context window used, but I'd like to experiment with scope and AI. Specifically I'd like to document how it behaved when I saw that the eleventy.js file was getting too long, and I asked Gemini to refactor it. The first mistake was to accept that Gemini could do this in just two steps. Step 1, filters.js, and then step 2 for another set of logic.

Now, in an ideal world, AI would know what it did, see the code, determine what each part does, and tidy everything up into neat refactored niches. It didn't do that. Remember that mention of the image logic being lost three times? The third time was due to refactoring.

To be specific, Gemini took the complex logic for matching thumbnails to posts and replaced it with two lines of irrelevant code, that I noticed eventually, as I tried to debug why the refactoring had failed.

Gemini and Git

When I noticed that Gemini has issues with keeping within the scope of a question I decided to use git. Every time Gemini provided me with a solution that worked I'd commit it. The logic is that if it breaks something I can tell it "This is how things were, and this is how they are now. I'd like to fix things".

Why Entrust Git rather than AI?

In my experience AI is fantastic as spitting out code, and muddling contexts, but very bad at answering "Can you remind me which command we used to do that", whereas git is fantastic at that, if you're efficient about git commit comments that mean something to you.

The AI Negative Feedback Loop

If AI makes a mistake, either because your instructions were not clear or because it got confused, asking another question will muddle it even further. Imagine an AI chat as a sand pit by the sea. The more you chat, the deeper the hole you dig. Eventually you make a mistake, and the tidal waters begin to flow into your sandpit. Within seconds that chat is swamped and unusable. With AI it's good to have a bug out bag ready. "Now that this context is hallucinating let's move to a new one".

Git and a Fresh Chat

If you're working on an eleventy blog and you're adding functionality, one step at a time, it's good to add bookmarks in the form of git commits. You use Gemini, or your favourite LLM to write the function, and once it works you bookmark it. You then write the next, and bookmark that. Eventually, when the LLM, or you, makes a mistake, and the LLM hallucinates or starts muddling scopes, you just start with a clean slate, helped by git, and continue moving forward, with a minimum of hassle.

AI driven Refactoring Lessons Learned

Next time I refactor I won't ask "can you refactor this long eleventy.js file?" I will break into stages. I like that Gemini refactored the functions into two files based on function type. I made the mistake of not checking that it preserves the logic of the function while refactoring. Be explicit.

If Logic Works, Embed It

With the thumbnails and featured images logic I assumed that once the logic worked, it would be permanent. It isn't. It can easily change. When I told Gemini to use the logic, and move the image paths directly into the markdown files I simplified my life. Complex logic could be removed from eleventy, and posts could go with a standardised approach to displaying images. Simplification works.

And Finally

Use git to help you keep track of changes. AI is not a search engine, so don't rely on it to remember a solution it provided for you. It will come up with a new one. Be as concise as possible and keep the context window small. The larger it is, the more room there is for mistakes.

And finally, AI might be logical and rational but it doesn't have an understanding of what it is doing. To use the Short Circuit analogy "A machine doesn't have emotions, or feel, it only runs as programmed". AI is Not Number five. AI is a tool. That's why it's good to practice with using it properly.

I've been training many teams around coding, design, and refactoring this past year, and here are three things I repeat often:

Fix the small things, particularly during training. Learning to be super fast at fixing the small things prepare you for when the big things will come. In that, when big things arrive, the small things will never be an issue, you can deal with them on autopilot and save your energy for the big things.

1/3

#code #training #refactoring #software

Refactoring : If you run the tests often: everytime it breaks, it has to be what you just did. Diagnostic is super easy. If you run the tests at the end only: if it’s broken, you have no idea why and you have to look everywhere. Check early, check often.

2/3

#code #software #refactoring

My preference: start slow, finish fast with confidence. Rather than start fast, finish slow with a lot of things to fix.

Bonus:

Refactoring is also knowing when to stop.

3/3

#code #software #refactoring

You know you're old when... someone cites a concept and both cites and shows the book that is influential in this space... this is good... but the book they show is the second edition, when your point of reference for the same concept is the same book... but the first edition... that is (personally) not so good 🙄
#Refactoring

We organise in the open, and you're very welcome to chat with the organisers to help, ask questions, give feedback, or simply to watch. You can reach us on the #ev_socratesuk slack channel (https://slack.softwarecrafters.org/), or on mastodon, LinkedIn, BlueSky, or by emailing organisers at socratesuk dot org.

#SoftwareCraft
#Unconference
#OpenSpace
#TDD
#Refactoring

We organise in the open, and you're very welcome to chat with the organisers to help, ask questions, give feedback, or simply to watch. You can reach us on the #ev_socratesuk slack channel (https://slack.softwarecrafters.org/), or on mastodon, LinkedIn, BlueSky, or by emailing organisers at socratesuk dot org.

#SoftwareCraft
#Unconference
#OpenSpace
#TDD
#Refactoring

In GNOME 50, the Nautilus hovercraft will no longer be full of eel, thanks to @kabushawarib nuking the last specimens of that living fossil: https://gitlab.gnome.org/GNOME/nautilus/-/merge_requests/1975

Nautilus developers are here to kick ass and chew bubblegum, and they're all out of gum 😤

#GNOMEFiles #GNOME #MontyPython #Nautilus #refactoring

Thanks to all the #DevNexus folks who attended my #Java talk on #Refactoring in #IntelliJIDEA (mostly) without AI.

Slides are available here: https://ted.dev/talks/#past-talks

Want this talk (or other ones) at your group event or conference, let me know!

ReSharper for Visual Studio Code, Cursor, and Compatible Editors Is Out

https://blog.jetbrains.com/dotnet/2026/03/05/resharper-for-visual-studio-code-cursor-and-compatible-editors-is-out/

#dotnet #resharper #vscode #cursor #programming #refactoring #codingstandards

RE: https://discuss.systems/@SoCraTes_UK/116165956780268806

really excited to be going to this…

#tdd #Refactoring

We organise in the open, and you're very welcome to chat with the organisers to help, ask questions, give feedback, or simply to watch. You can reach us on the #ev_socratesuk slack channel (https://slack.softwarecrafters.org/), or on mastodon, LinkedIn, BlueSky, or by emailing organisers at socratesuk dot org.

#SoftwareCraft
#Unconference
#OpenSpace
#TDD
#Refactoring

We organise in the open, and you're very welcome to chat with the organisers to help, ask questions, give feedback, or simply to watch. You can reach us on the #ev_socratesuk slack channel (https://slack.softwarecrafters.org/), or on mastodon, LinkedIn, BlueSky, or by emailing organisers at socratesuk dot org.

#SoftwareCraft
#Unconference
#OpenSpace
#TDD
#Refactoring

"Always be refactoring. If you touch the code, and you can improve it, improve it, but never optimise early."

#refactoring #classic

https://levelup.gitconnected.com/martin-fowler-was-right-microservices-suck-573bbf09a0fd

We organise in the open, and you're very welcome to chat with the organisers to help, ask questions, give feedback, or simply to watch. You can reach us on the #ev_socratesuk slack channel (https://slack.softwarecrafters.org/), or on mastodon, LinkedIn, BlueSky, or by emailing organisers at socratesuk dot org.

#SoftwareCraft
#Unconference
#OpenSpace
#TDD
#Refactoring

We organise in the open, and you're very welcome to chat with the organisers to help, ask questions, give feedback, or simply to watch. You can reach us on the #ev_socratesuk slack channel (https://slack.softwarecrafters.org/), or on mastodon, LinkedIn, BlueSky, or by emailing organisers at socratesuk dot org.

#SoftwareCraft
#Unconference
#OpenSpace
#TDD
#Refactoring