I was going to write something about the 1 or 2 tricks I’ve learned about trying to wrap your head around large codebases, but the last few months at work have pretty much made it clear to me I know nothing about knowing things, so that one’s pretty much in the scrap heap at this point. My very first post tried to capture that sense of being overwhelmed and in over your head when you start a new job, and it turns out it’s pretty easy to keep that sensation alive 6 months in. I wouldn’t be surprised to discover that I know less about what I’m doing now than I did when I started.
Has anyone else ever worked in a job where they never seemed to wrap their head around what it was they were supposed to be doing? I mean as in the sense that every time you think you have an understanding of how something is supposed to work, you learn that something you thought wouldn’t be affected, or that shouldn’t be affected in the slightest is now broken because of something you did? I used to think this was a learn by experience thing, but that seems to be taking too long and leaving too many bug reports in its wake.
In light of all of this, I’ve had to try to take a hard look at how I’m trying to learn at my job, as well as I how I do it in the first place. In light of it being January, and me needing to get my act together, it’s clearly time I make some changes.
Change #1 – No more worrying about hitting the “happy medium” in developer testing my code. I tried this over the last few months after some feedback over the progress of a script that had to process huge amounts of data, and thus took huge amounts of time to run. It seemed like a good idea at the time, but I don’t think it’s working for me. Testing is 1 of my biggest weaknesses as a software developer (along with system administration-y tasks I’m doing for the first time), and I can’t afford to chance scrimping on something I’m already not good enough at. From now on, I’m making sure I feel confident I’m doing enough testing, and if that makes things take longer, then so be it. I have some other thoughts about “happy mediums” in general that I’m just going to dump into their own blog post, but that’s another topic for later.
Change #2 – Get less stymied by system administration-style work. Yes, experience helps with this a lot, but from now on I’m going to dive into these sort of things, and be quicker to pull people over to help me figure out what system file needs what line in it to get things going again. Doing software development means running your own local or virtual server(s) now, as well as maintaining their configuration and communicating all of those changes to the people in charge of running production machines. It’s time I stopped just struggling and eventually getting by and started developing a sense of competence about these things.
Change #3 – Be more assertive about working on side projects. This is tricky, as stuff done on work machines or on work time lead to work claims on said projects, but I need to do better about making time to work on this stuff. I have 1 project that I’ve been putzing around with for a while that’s almost ready for open source release, and a couple of others that sound good and I’d kind of like to jump on and get started, but none of that can happen until I buckle down and make the time for them. So this year, I’m going to start looking for opportunities to work on these things instead of just getting around to them when it’s convenient.
Change # 4 – Try to avoid using keywords in comments. Specifically, I want to avoid the keywords in the lines I’m writing a comment about. This is more of a personal challenge to try to write better comments than anything. My thought here is that if I avoid using the same keywords as int he code I’m writing about, I’ll be forced to avoid repeating the obvious repetition of what the code does, and instead have to write about more useful comments that describe the state of of the program at that point, and what that means logically.
I have no idea how well any of these will work to improve my output, but I think these are worth giving a shot. They may lead me to other ways of improving my code that work better. If nothing else, I’ll have a handy list of how not to improve one’s code. Regardless, all of the points above are really just subsections to my real programming resolution, to suck less in 2013 than I did in 2012.