What is Trenchcoding?
The name of this blog borrows from the idiom “the trenches”, which Merriam-Webster defines as, “a place or situation in which people do very difficult work”. Alternately, the definition is slightly different in the Longman Dictionary of Contemporary English: “the place or situation where most of the work or action in an activity takes place”. So one definition specifies the difficulty of work, the other focuses on quantity of work. Taken together, “the trenches” is where most of the work is done, and the work is difficult. I apply this to coding, or creating software in general, in a way that is separate from greenfield, vanilla tutorials and conceptual, academic coursework. For me, there’s some analogy to be drawn between modern software creation and the military practice of trench warfare, where the politicians, academics, and generals are far removed from those soldiers “in the trenches”, who are fighting battles on the front line, doing their best to carry out the orders given to them. As am I, trying my best to fulfill the requirement provided to me and deliver a successful product according to an often naive ideal concept. At the same time, I’m also trying to not shooot myself in the foot and save my future self from refactoring where possible. Phrases that keep me up at night include, “it wasn’t designed to handle that case”, “it was working until I made a change”, and so on.
I am not designing the car, I am the mechanic fixing or modifying the real thing. I’m not an electrical engineer, I am wiring in a new light fixture. That’s not to say it’s not useful to understand the theory behind how these things work or why they are the way they are; after all, more knowledge can only help you. I guess what I’m trying to say is that, it’s all well and good to major in Computer Science, maybe create your own programming language. But it’s entirely different working on an application with 900 moving parts, and something goes screwy, or perhaps all is well now but a change request just came in and you need to implement it without something else going screwy. Sure, someday I would love to write my own compiler, and I’m sure I’ll learn a ton along the way. But right now I need to know why my CI pipeline is failing builds, or why some script works on my computer but not in PRODUCTION. That’s trenchcoding, and there’s a lot of work, and it is often difficult.
Hopefully anyone reading this will be able to relate in some way, and gain some useful knowledge when I have time to jot it all down and post it here. In 2017 I was studying for MCSD certification and found this blog by Troy Whorten. Not only did he meticulously document his entire learning process toward acheiving the certification, but posted his experience going through several online CS courses as well. I admired his dedication to self-directed learning and documenting his progress. He’s since gone on to work for Google, so kudos to him. That work inspired me to do something similar, to carry the torch, or something like that. Anyway, that’s what this is all about, for you, me, us, down here in the trenches.