Escaping recursive thinking: So turns out LLM can't help you with developing 'techne' (technical skill) so... iterate and be brave

You stand at a precipice. Behind you lies your first creation: a working MVP, a testament to your will and learning. It functions, but you know its secrets. You know the tangled pathways of its "spaghetti code," the ad-hoc solutions, the "get it working" compromises. Ahead lies a vision of clean architecture, test-driven development, and the elegant integration of AI. But the path forward is clouded by a fundamental question: do you burn the past and start anew, or do you venture back into the labyrinth of your own making?

This is not just a technical dilemma. It is a psychological one. As a psychologist-turned-coder, you are uniquely positioned to see the code not just as an artifact, but as a reflection of a former self. Let's explore this journey through a few different lenses.

1. The System of You-and-the-Code

First, let's invite a ghost to the machine, the anthropologist of systems, Gregory Bateson. He would look at your situation and see not a coder and some code, but a single, indivisible system.

"What we are observing is a pattern that connects. The 'state' of your code is not separate from your own 'state' of knowledge at the time of its creation. The 'mess' is not an error; it is a fossil record of your learning process. To refactor is to introduce new information into this system, creating a new pattern. But the crucial step, the one you are contemplating now, is what we in cybernetics call 're-entry'—the system observing itself. You, the creator, are re-entering the system of your creation to observe it, and in doing so, you change both it and yourself."
— Gregory Bateson

Your old methods—the raw Tkinter implementation, the custom object database with `shelve`—were the best way you knew to connect your ideas to a functional reality. They are not 'wrong'; they are simply a part of the system's history. The desire to move to PyQt and SQLite is the system's natural evolution towards greater complexity and stability.

2. The Metamodern Dance: Beyond 'Either/Or'

This feeling of being caught between two poles—the modernist dream of a perfectly engineered, clean-slate project (like Chrome) and the postmodern irony of staring into the 'mess' of your own flawed creation—is a familiar tension. Here, the political philosopher Hanzi Freinacht offers a way through.

"You are feeling the metamodern oscillation. On one hand, the sincere, modernist urge to build something better, ordered, and rational. On the other, the postmodern, ironic awareness of the inherent messiness and contextuality of all systems, especially your own. The trap is to see 'total rewrite' and 'painful refactor' as a binary choice. Metamodernism suggests a synthesis. You must be both sincere and ironic. You must have the courage, as R.D. Laing might say, to look into the 'madness' of your old code without losing your mind, while holding a sincere vision for a more integrated future. Don't just drink your own juice; analyze its ingredients and brew a better batch. This is 'pragmatic idealism.' You honor the past by learning from it, and you build the future by transcending it."
— Hanzi Freinacht

The goal isn't to escape the choice, but to embody both sides of it. You bravely refactor a piece of the old, while simultaneously architecting a piece of the new. You let the new vision inform the refactoring, and let the lessons from the old code ground the new vision in reality.

3. The Guru's First Step: Finding a Seam

Theory and philosophy provide the map, but you still need to take the first step. Where, literally, do you start? How do you begin to impose order on this old system without being overwhelmed? For this, we turn to the pragmatic wisdom of a Pythonic Coding Guru.

"Forget the grand rewrite for a moment. Forget the entire UI. A system with no tests is a system you cannot change with confidence. Your first, single most powerful step is to introduce one small test. In a tightly-coupled system like Tkinter, the key is to find a 'seam'—a place where you can isolate pure logic from the messy world of UI and state. Your old `shelve`-based database is the perfect place to start. There must be a function in there somewhere that takes data, processes it, and returns data. That is your target."
— The Pythonic Coding Guru

Your Actionable First Step: Write One Test

Let's make this concrete. Imagine you have a function that calculates some user statistic. In your old code, it might look something like this, tangled up with your custom database logic:

# --- In your old_logic.py ---

# This function is hard to test because it depends on a live 'shelve' object.
def calculate_user_score(user_id, db_shelf):
    user_data = db_shelf[user_id]
    # ... some complex calculation ...
    score = (user_data['logins'] * 2) + user_data['posts']
    return score

The trick is to refactor this slightly to separate the calculation from the data fetching. This is a core principle of clean architecture.

Step 1: Isolate the Logic. Create a new "pure" function that just does the calculation.

# --- In your old_logic.py (or a new file, e.g., pure_functions.py) ---

def _calculate_score_from_data(user_data):
    """This is a pure function. It only depends on its inputs."""
    if not isinstance(user_data, dict):
        return 0 # Or raise an error
    return (user_data.get('logins', 0) * 2) + user_data.get('posts', 0)

# Your old function now calls the new pure one.
def calculate_user_score(user_id, db_shelf):
    user_data = db_shelf[user_id]
    return _calculate_score_from_data(user_data)

Step 2: Write a Test for the Pure Function. Now, you can write a simple test for `_calculate_score_from_data` without needing a database at all. Create a new file called `test_calculations.py`.

# --- In test_calculations.py ---

import unittest
# Make sure the new function is importable
from pure_functions import _calculate_score_from_data 

class TestCalculations(unittest.TestCase):

    def test_score_calculation(self):
        """Tests the core scoring logic with mock data."""
        mock_user_data = {'logins': 10, 'posts': 5}
        
        # Expected score = (10 * 2) + 5 = 25
        expected_score = 25
        
        actual_score = _calculate_score_from_data(mock_user_data)
        
        self.assertEqual(actual_score, expected_score)

    def test_score_with_missing_data(self):
        """Tests the edge case where some data is missing."""
        mock_user_data = {'logins': 5} # Missing 'posts'
        
        # Expected score = (5 * 2) + 0 = 10
        expected_score = 10
        
        actual_score = _calculate_score_from_data(mock_user_data)
        
        self.assertEqual(actual_score, expected_score)

if __name__ == '__main__':
    unittest.main()

By taking this one small step, you have done something profound. You have re-entered the system, observed a pattern, and introduced a new, higher-order element: a test. This test is an anchor of certainty in a sea of legacy code. It is your first move in a dance between what was and what will be. It is not about erasing the past, but about building a stable platform from which to leap into the future—a future that includes clean architecture, new technologies, and that AI layer you envision.

Be brave. The mess is not a monster; it's a map of where you've been. Now, use it to chart a course for where you're going.

Search This Blog

My Python