For some programmers, the deepest satisfaction in software comes not from building applications but from understanding how machines work at their most fundamental level. As described in a personal blog post, this manifests as a need to 'know what these lines meant' when seeing computing depicted in media like Tron: Legacy, leading to years spent learning programming not for practical utility but to 'understand how the machine works.' This inclination extends beyond technology: such programmers report needing to 'reinvent it myself from scratch until I get it' when learning new concepts, adjusting axioms for intuition in school until they fit before building theorems, and being unable to experiment with cooking without understanding underlying chemistry. For these individuals, focusing on details like writing machine code by hand, counting cycles, or creating toy operating systems wasn't just a preference but a core aspect of their engagement with the field, with one noting they 'take pride in inventing clever hacks' and 'treat the machine as a continuation of myself.'

Retro terminal showing htop and commands including whoami, login, make, and cat /proc/meminfo
A programmer's terminal illustrating low-level system interaction and deep technical engagementpurplesyringa.moe

This image exemplifies the hands-on, low-level exploration that programmers who value deep technical engagement describe as essential to understanding how machines work.

This deep technical engagement historically provided both psychological refuge and professional validation. The blog author explains that before industry trends shifted, 'Even those who didn't get would at least respect my work on low-level projects. There was an understanding that minor optimizations in compilers compound, that someone needs to write assembly for JSON parsers to go brrr, and that programs don't have to suck the way Electron slop does.' The software world served as a reprieve from broader struggles, stating 'This is genuinely debilitating in day-to-day activities, but for a while, the software world was the one reprieve I had from this struggle.' However, the rise of large language models has fundamentally altered this landscape. The industry now overwhelmingly agrees that 'LLMs will make such a draining and exhausting process as worrying about details obsolete, and let developers focus on abstractions and large projects.' As the blog author bluntly states, 'Great for them, but I'm not exaggerating when I say they took everything from me.',

In response, the author finds LLMs incompatible with their way of working. They describe getting 'almost physically ill when I work on a project with more source code files or at least general architecture than I can keep in my head, so I don't get anything out of expanded scope.' After trying an LLM on a pet project, they realized 'the LLM would come to know more about it than pretty much any person I could show it to,' leading them to swear off LLMs for anything they care about. Over the course of a year, they went from having a planned future to worrying about applying for disability, as the job market decided LLMs are the future and the one option in their life they thought constant disappeared. This leaves them questioning whether there is any economically viable path forward for their particular skills and mindset.