Have you ever accidentally told the truth to yourself? I do it all the time. Maybe it's just a writer's thing, but, for me, talking (internal monologue or otherwise) oftentimes precedes thinking. Like, I'll unintentionally say a sentence over and over and over in my head over the course of months (ex: "Aw, here it goes," Richard said with defeat.). Then, at some point - sometimes after the 100th iteration, sometimes years after the seemingly self-caused words first appear in my head - the falsifying flaw or the verifying breakthrough in the sentence becomes apparent. It's almost like the truth as I've known it has a rhythm in my head, and I know it when I hear it, but not perfectly... and saying some sentence multiple times to see if it fits that rhythm of truth is the only reliable way to know if the sentence is true. Incidentally, sometimes I'll hear a line of dialogue and that will inspire a piece or character here.
And sometimes - by seemingly random chance combined with random circumstances - I'll talk myself into a thought that I never would have thought to think. And, suddenly I've accidentally revealed something about myself or my situation that I hadn't ever realized or articulated before. It's remarkable. It's like having an outside observer inside your head - like having a historian with their grand sweeps to draw upon in the less-than-grand narrative of your life. That's why I said it might just be a writer's thing, but of course I'd have no way to confirm this, heh.
I had this experience yesterday. We'll get to that, but first, a bit of background: I lost my programming job a couple months ago, and it wasn't any sort of incident or angry exchange that caused the problem. No, it was as simple as business arithmetic: My productivity never got off the ground. While (of course) there were complicated, manifold reasons for this, the bottom line - the ultimate reason - is that I didn't learn much about programming and they didn't get much from me, and so it just wasn't working. It happens, and I haven't had much of an emotional response to it. Sunrise, sunset, and all that.
So, anyway, two months later, yesterday (note the switch to present tense) I'm awake at 0300 in a video game and I strike up a conversation with a friend who's a programmer himself, and we get to talking about jobs and prospects and all that. And at some point, I get to speculating about the job's ending, you know, talking about what really didn't work from a nuts-and-bolts programming perspective. And so we're talking about things like work as you think you should do it vs as your manager thinks you should do it, and all that stuff, all of it coming from our own experiences.
And so it's a comfortable environment, a good discussion, and I - the Honestly-Pretty-Introverted-And-Reserved - get to talking about the jobs I want to get, and I mention off-hand that I don't think I'm very good at programming. I think the word I use is "mediocre". Oh, sure, I might want to work as a programmer in an academic setting, because I historically flip through every type of book and article I come across (to a fault, actually), and I have mathematical ideas in my head constantly. But, as good as I might be in the specialized sense, I say I'm mediocre as a general programmer. I think I actually use the word "mediocre" and mean it, adding in a "maybe even below average".
This is the first I've heard this coming from my own mouth, and it strikes me to realize that I'd actually believed it. I'd never articulated that belief well enough to confirm or deny whether I should actually hold it. And so, in a new train of thought, after saying this out loud for the first time, I immediately begin correcting that belief, "No, that's not even right. I guess what really happened is that losing my job totally psyched me out." After all, as I work through this belief, I realize it's utterly absurd to generalize my value and intelligence based on a four-month stint that doubled as my first office job. I think of all the times I'd watched people in every profession struggle and then thrive. Especially with a complex cognitive task like programming. Hell, learning an NBA defense usually takes players a couple years. Does it make me dumb that I didn't get the intricacies of what was expected four months in, without having a solid baseline? Of course not (necessarily, at least).
Despite all this, it's not absurd to believe I'm mediocre. After all, a lot of people are. On the other hand, what was absurd was the secondary, self-defeating thought (which I'd also honestly believed) that the amount I can give an organization as a programmer was therefore middling. Which is not just absurd but so on so many levels - I'm clearly above-average at a lot of tasks, and clearly below-average at a lot of others. Mediocrity, then, must always be partly a failure (or, I suppose, a blessing, heh) of opportunity or of pursuit. An opportunity is good if it maximizes my strengths and ameliorates my weaknesses. And this opportunity, from the get-go, did not. Why I would take that one failure as a generalized failure to produce something for corporations no matter my role or situation? I sincerely had no idea.
Whatever the case, the job turned out not to be especially well-suited to the things that I do well with - creativity, open deadlines, teamwork, quantitative reasoning, and higher-level work. It emphasized rote tasks with a lot of rote asking around about complicated enterprise code. It emphasized asking a hundred questions of peers and supervisors over learning a hundred sub-systems. And along the way, in between questions, most of the work revolved around going from question #50 (just-answered) to question #51 (soon-to-ask). Part of this was my over-eager questioning; most was inherent to the problems themselves (as I found when I stopped being over-eager for stretches). If I'd lasted a year I probably would have gotten to a much more autonomous place and figured out more and more ways and resources to avoid asking questions.
What's more, the alternative to asking questions constantly was conducting research on the relevant sections of enterprise code to figure out i.e. where something is stored in a database. And while there's nothing wrong with this research (it's certainly potent and sustainable in terms of long-term problem solving to understand the code-base), it's also time-consuming. Which wouldn't have been so much a problem except that management never really dictated the proper speed for allotted tasks other than vague estimates. And so I never really knew if I was doing well enough or fast enough, even if I wanted to be purely rational in the sense of keeping my job at all costs. Here's something that took me awhile to fully understand about programming - there are a hundred decisions in the course of a sufficiently complex programming problem, and each of those decisions has at least a couple dimensions: These decisions involve trade-offs, navigating imperfect information, and, quite importantly, the expected speed and quality set down by supervisors and deadlines and business requirements. And looking at the code-base is a good way to build quality, but, of course, at the expense of speed. I tended on the side of quality almost always. In retrospect I did this to a fault, not in some abstract sense but simply in terms of what speed was expected.
It's not so much that I didn't understand this all immediately, it's that you don't really see how fundamental all of the decisions and trade-off are until you start making them for 8 hours a day, 5 days a week. Somewhere on the continuum between "Quick-and-dirty" and "Worthy of SICP" lie several points of interest:
- "How well/fast you think it should be done"
- "How well/fast your supervisor/clients think it should be done"
- "How well/fast your peers can do it"
- "How well/fast you can actually do it."
- "How well/fast the business actually needs it to be."
Ideally, you're not even thinking about any of this, because the solution is instantaneous. But then, complexity inevitably comes in and you are left with choices, and how those choices will affect your final quality/speed is not known, but hopefully you've learned and intuited the effects of various choices somewhat with experience, history, and intelligence.
The bottom line is that given all of this, and given the added dimension of communication of all of this between employee and organization? There's a lot of wiggle room to simultaneously a) get fired and b) be a pretty good, intelligent programmer. And if you start conflating one of the conditions with the negation of the other, you'll run into a lot of disappointment or, potentially even worse, you'll psyche yourself out of opportunities from the get-go.
There were plenty of things I learned from four months as a programmer, and there were plenty of great people and memories, many of which I'll draw from for years. I made mistakes on the job and I will surely make mistakes again, but there are other mistakes I'm fixing to avoid in the future (I wasn't nearly assertive enough at the beginning, for example). But in the course of learning what I did, I'd also "learned" something extra that was altogether sinister and deleterious and probably false. It's only fortune that I talked myself out of it.
No comments:
Post a Comment