I found what Andrej Karpathy said on the importance of accessibility to what you create - a reason why I decided to express things in this post.
(Aside: I use dashes, organically. Not em-dashes. I hate that this has become a way to identify LLM generated text.)
Grounding
I’ve traditionally had a very isolated way to express myself. Growing up I’d happily spend countless hours in my childhood bedroom, building a small slice of my inner world - a little lego city perched beside my bed. From lego floor tiles, to random Storm Troopers just chilling, seemingly out of place. In other cases I carried around a hilariously sized A4 diary that I would scribble random drawings upon when my parents brought me out to pubs and restaurants as they met their friends in Ireland.
I was happy, and free in my little world. But looking back, it felt a bit empty that only I remembered what I had created, only I knew the enjoyment of those semi-unique moments after school.
Suffice to say, it felt like I was so happy about the mere idea that one day someone would be able to join in this little world I created (even as I write this, I can feel that childhood energy of sharing spike in the back of my mind) and I could share the beautiful things I thought I had created, and be happy to co-create with them too.
Without making this a slightly pixar-esque sop-story, I didn’t get the chance to have someone to share in this world I created. And that did hurt. But it’s okay, eventually I did find a vehicle by which a world I could create would be more accessible: it was through Software. So, I want to set the headspace of this particular writing, by capturing a cliche yet important anchor to my enjoyment of Software: It is a pure creative way that I can express things to people.
Function, Form, Make it Work, Make it Pretty?
Often in this particular headspace, and as I’m surrounded by peers with different approaches the question arises:
Is Software a vehicle for function (the answer appears yes, but I still ask the question.) Is form the way it is presented? Does making it pretty require making it work first, and inversely the same. Here, I guess I want to at least say what I see in each of these properties and actions.
Though I do admit (and warn you) that it feels like i’m appearing like i’m saying obvious things or things that appear to make it more inaccessible/surreal than what it really is, and yet I’d like to just push past this feeling of judgement I presume I would get some from some readers.
Feel free to skip to the next section if you’re not interested in hearing me be self-reflective of Form and Function in the way I understand it.
Function
Inherently Software exists to me as a way to functionalize the human qualia.
In the spirit of accessibility, it would be ironic I wouldn’t provide at least my understanding of the definition of qualia: broadly it’s a term used to represent “the experience of doing something, like the experience of feeling a breeze, or the experience and or feeling of calculating some large problem in one’s head.” Though I’m not one to push forward, that I have an insanely deep grasp of the broader subject.
That is to say, the things that we used to do, or experience whilst doing them - might be better to be exchanged for new experiences that we don’t know how to functionalize, yet. Through the element of discovery we would get whilst performing these new functions often lead to some deeper insights about the functions they were performing. Does creative expression exist here in complete isolation to other elements? Probably.
Form
Now this is the obvious point to just say “duhhh creativity is in form!” - but I guess I want to open up to this some more. Is form just presumed to be a separate element from the base function itself. Does one interoperate with the other to provide the complete package of work? I don’t know. I feel like in software that elegance comes from foresight, and that an evolving form is used to shield the consumption of the output from its own evolution - whilst it evolves.
Though in that sense, how can form support the needs of function as function evolves at the marching drum of external pressures, “customer A needs this”, “things only survive one magnitude of growth!” and so forth. For me, in this new added way of pressure, form becomes static in software. It’s what provides the contract for consumption. Without regard for introducing the concept of schema to this point, form is the literal foundation by which all others follow.
If we can stomach that point of view, I guess I want to express that form should inherently be fluid, fluid, fluid - ending its process at the first time it is consumed by the real world. It’s incredibly important to find creativity in form early on, to imagine what are the base ideas and concepts that someone could surprise you with their usage of the form.
I may have begun by saying the form shields the evolution of function. Yet, it would appear that function actually is the one that shields form from needing to evolve. To raise us back to normal engineering point of view, refactors are the admission that function can no longer shield form. Or is it (please don’t hate me) that refactors are the admission that form needs to be enveloped by an outer form to preserve its contract with others?
Make it Work
Okay, now that we’ve pretended to be deeply logical philosophers in discussing form and function. Let’s go a little less abstract here.
When one approaches the desire to create a body of work. The immediate gut reaction is to follow the path of least resistance. Like an electrical current fighting through a block of dry wood to find the other side of the jumper cable, it’s sometimes too easy to just brute force the solution that inevitably forces form to take shape.
In some cases, especially early on - there is a reward loop of progress obtained from the working of a function without regard for form. It’s not that people don’t care, but just that the thrill of the dopaminergic release of making a cool thing work often overrides attention to form.
When these moments happen early on in a codebase, or new greenfield development - depending on how critical it might be to the overall codebase, it can be the exact entropy needed to promote more attention to form going forward. Equally, it could be a contributor to lowering the pain threshold to appreciate the contract in future development, to a point where people are pushed away from the idea of protecting the need for form to be rock solid. Like, why should I design something beautiful that is surrounded by another body of code, where that very same code when it interacts with my contractual form - asks me to mutilate myself to adhere to its own weird contract. But it’s kinda silly to complain at that, that’s life - though I just still want to acknowledge it.
So now we’re at a new thought, making it just work can provide outcomes necessary to achieve business needs, but destroys an entire future of creativity that I strongly believe could be used to have actual outcomes that itself is aligned with business needs: flexibility of the form, while static, and had enough forethought for the future.
Make it Pretty
Making it pretty in my experience refers to something outside of the “oh the code is so aesthetic wow!” - but rather the prettiness results from the respect of contracts between forms. When my code is designed well, had enough creativity to access our future needs, it invites others to respect and think about the same. That’s it.
So in essence.
There is an equally similar dopaminergic pleasure to beautifully crafting form and function at the same time, without the immediate gut-reaction of screaming “overengineered!”, “bikeshedding!”
How can you best design form, that is aligned with the objective business reason for software, in a time-limited way, without becoming lazy?
Oh man, that is the essence of the beautiful creativity that made me fall in love with Software Engineering.
I really hate Cursor. I adore LLM aided coding.
An amazingly (gorgeous) destructive problem that is all bubbling under the surface is that we forget about form, when we use LLMs to code.
We copy entire files into < your favorite LLM’s context window >, without introspection to the unspoken contractual form(s) that are in play. It’s asserted that LLMs don’t have creativity. But I believe that “those” (I really-really do not want to anthropomorphize these things) things can at least appreciate the contractual nature of form. Which we hardly give, or appreciate the need to give.
In the use of tools where the ability to “feel” the shape of the form of many contracts at once, without a general specific exact sense of each field in said contracts - is missing, I worry deeply for the debt that we incur when it becomes too easy to ignore form for function.
I feel pain, outside of the typical engineering pain, when things don’t fit together because there wasn’t any imagination for critically building for the future. It creates a feeling of silent disappointment in the process for me. That those around me aren’t actually interacting in the creative process with me anymore. The same process that I had wished for people to enjoy with me, whilst I played with my lego those days after school growing up. It’s sorta slipping away again?
I think that’s the real root of my disappointment with AI tools and in general our prior faults of accessibility. Has the ramp (to borrow this choice of word from Karpathy) gotten so low with Cursor-like tools, that the natural problem mentioned in the header image of this post, given lead to this disengagement with the elements of what I find truly warm and cozy with Software? To put it another way: Is it easier to just engage with function, than it is with form these days?
I don’t believe that LLM’s kill creativity with respect to Software Engineering. I think it’s greatly given me new and really exciting new avenues to try. It’s also given me ironically, accessibility to topics that were lacking.
Accessibility to the work you’ve poured time into.
Over a few months I built our Queue system at the company Bland - that handles millions of calls a week. I really invested time into an elegant approach that appreciated the unique characteristics of Calls - so far that the duration of each call cannot be reasonably predicted ahead of time. So we couldn’t use token bucketing, no - we had to use a more probabilistic way.
Like, what is the probability given “x” calls at once that most will hang up or go to voicemail based on the current advancement in active concurrent calls per-customer - whilst imposing a soft and hard maximum to the amount of calls that could be handled by a finite number of containers? Calls were bursty, customers had dispatch per-second targets and timeframes, we couldn’t wait for perfect knowledge.
It was a creative, elegant solution that had the form to consider external metrics, overrides, nice-to-haves and virtually anything under the sun. And yet, few understood it. Even fewer were confident to touch it due to how it was in the critical path. I added heaps of documentation, really friendly details, guides and examples. But no one really had touched it.
One day, I decided to put time on the teams calendar where I’d physically walk them through it. I sat down with them, explained what I had just explained to you above - and explained why we needed to do it like this. And things … actually changed!
Now, and hilariously, during an incident - engineering didn’t have to wait for me to wake up at 7am to triage a customer blowing up our platform, they got hands on with the Queue system! The funny part was that they manually forced the probability for dispatching calls (of which there were 110k in backlog still for this customer) to 50%. It was an interesting few hours cleaning that up, but someone actually was (at the time, I guess) confident to do this without intense oversight. That made me feel something nice, irrespective of the lack of business alignment with that outcome (obviously!)
Closing
I think with that all said, I’ve had some reflection on why I feel disappointment for the growing use of Cursor for reasons other than perceived skill diff bro that might be echoed by others. No, for me it was that I felt that I was losing the anchoring to something that gave me genuine comfort and purpose when things were in flux in my own life.
I recognized that maybe to keep people involved in the creative process around form, that you have to start making it accessible to them. I don’t know the best solution here, so I won’t comment. But someone enthusiastic about resolving the perceived danger to approach something, by being proactive with as little as physically sitting with them and or recording you providing a human touch to that nature, can frankly be all that is needed to keep the respect for form alive in a LLM-enabled engineering world.
In truth, all I just want is to keep people wanting to be creative with me too :)