I'd have to more or less agree with a sibling comment, in the sense that writing the code isn't the hardest part (that's the agreement part) but it's not the ea

I'd have to more or less agree with a sibling comment, in the sense that writing the code isn't the hardest part (that's the agreement part) but it's not the easiest, either (that's the disagreement part). I write a lot of code for highly secured black boxes that break a lot of networking rules: undirectional gateways and guards where two things must be guaranteed: one, no matter what, data can flow in one direction and one direction only, and two, no matter what, with the proviso that we cannot control customer operators, the only data flows permitted are those that have been reviewed by two people with independent roles. The hardest part is understanding the space, how things need to be, what might work, what might go wrong, how a change here might break something there (and this in a system basically running in old-fashioned SELinux "strict" mode). (There is only so much experimentation and instrumentation possible, because I need to make things work in that closed, tightly controlled appliance.) The easiest thing is explaining this to others, at various levels: It’s about knowing what to include in the explanation, what to omit, and which analogies are useful, which are harmful. That all comes from repetition and retrospection. Writing code is somewhere in the middle: once I understand the problem, the code is usually pretty easy, except, of course, when it isn't because oh, yeah, that. Fortunately, I have a long legged hound. My entire team knows the value of our DWs, dog walks, or, as a colleague recently called it, Diagnostic Wandering. Two hours a day in the woods, along the rivers, and much becomes clear. Not all, just much. The really second hardest part is mentally working through the coding alternatives like an adversary, trying to figure which one is best, or, on the whole, given all the layers of defence, good enough.