Today's Ramblings (A programming adventure)
It's no secret, I'm not the best programmer in the world, if that's why you're following me, then I'm sorry to disappoint. I'd like to think that I'm a decent programmer, that I think through problems in code to reach reasonable conclusions that are efficient and at times elegant, and I'd also like to think that I'm relatively creative in my solutions and designs for my own from-scratch code. The fact of the matter is, nobody is perfect, we all make mistakes, and if you want to see this first-hand in the realm of programming, just look at your own code (some of you pros will have to go back pretty far, but you'll see something that could be better).
I think I've done a pretty good job so far, even to the point of writing some damn pretty and functional code (I know, it's PHP, there's only so much you can do, but dammit I'm proud of what I do!). The company that I work for is a meritocracy, if you do well, you are rewarded and even praised publicly, if you don't do so well, you are privately educated and guided to resources/people that can help you to do well (every experience is a learning experience!). Worst case scenario: you're attitude and work are so horrible that you are more of a burden than a help and are let go. Why am I glad that this is the case? Because it's a damn good concept and business practice.
On the business side of the house, the company can't afford to keep bad programmers (employees, but we're being specific here). "Bad" is largely subjective, but suffice it to say that if you have a terrible attitude and are putting out equally terrible code that is bug ridden and you're too hard-headed to recognize it, then you're probably bad and need some help. On the more personal side of things, it does no good for you to be a douche when you make a mistake. When someone makes a mistake and can't just own up to it, get the help/education that they need in order to fix the mistake (and hopefully not repeat it later), and move on, it wastes productivity time. Other developers have to sit there and listen to you complain and go on about how great you are and how your code works and how they are stupid and if they try to prove you wrong it can turn ugly, for hours. It's not good for you (you get pissed) it's not good for them (they get pissed) and when developers are pissed off they produce garbage code which gets us back to the business side of things not getting much of a return on their investment. It's bad all around.
I said all of that so that you'd have an idea of where I'm coming from when I tell you a short story about what happened at work today; I made a mistake.
Yep, remember that part about "Nobody is perfect..."? Yeah, that includes me. One of the components of our app is a document converter. I've spent the better part of a week (maybe two, my brain is a bit fuzzy right now) doing the best that I could to fix someone else's code who is no longer with the company (for good reasons, they got a better offer elsewhere and I wish them well). Lots of things were broken and with the help of my two partners-in-crime (and a lot of research), I've been hacking away at the bugs and broken cruft in order to produce something that I'm (still) pretty proud of. We've all taken a few chunks out of the bigger pie in order to more easily manage implementing these fixes and today we were damn near finished, then 16:00 rolled around....
Bombs away! Someone else on the dev team had to go through some code that I had written a few days ago because of the particular task that they were working on. First problem, (a personal peeve that I blame myself for) they had to ask me what was going on in my code. That set off a red flag in the back of my head because I try to write as readable code as possible, so I failed at something. The second flag that went off was, if they couldn't see how my code was working, I didn't write it simply enough, which means that I didn't understand the problem well enough to come up with a simple explanation (programmatic solution). Two flags raised in the time it took for my cohort to utter one sentence, "Hey Brian, this code that you wrote, I'm having a hard time understanding what's going on with it and could use your eyes." Taking every opportunity to learn something as well as to possibly help my colleague, I jumped right up from what I was working on and walked on over. Come to find out, I was doing things the hard way. Part of this is because of my lack of experience with PHP (I was writing loops where in_array() would have sufficed), the other part is that my mode of thought immediately went to loops because when I hear "arrays" that's what I think, "loops".
Next up, we step through the code in the debugger and I explain what I intended for the code to do. Now, keep in mind, I did test my code, but not well enough in this case. I hadn't accounted for two possible user actions and so my code produced some odd results. No problem, my colleague figured out really quickly what was wrong and we both went to work bouncing ideas for solutions back and forth once we were both sure that I understood where my mistakes were (this is a very important part of the process!). By the time we had everything mapped out for what we needed to tackle and started writing the code to fix the problems (we found issues, unrelated to the code that I had written, that are definite "no nos") it was just after 17:00 and thus, time to leave for the day.
I have something to admit, I'm glad that my colleague found something wrong in my code even though I don't like being wrong. Why? Because if that code would have been left there and the mistakes not caught, things would have been hairy and life would have gotten a bit more hectic. I didn't catch it when I wrote it, our QA didn't catch it when they were testing, and my colleagues didn't catch it when they reviewed my code prior to the commit (whenever we are ready to push a commit, we always grab at least one other dev to take a look at the code and get their input, a second set of eyes helps!), and had my cohort not been digging around because of a problem that he was tracking down, our customers would have noticed it and badgered our tech support department. That gets back to the "bad for the company" part I talked about earlier.
Here's the other reason why I'm glad that my mistakes were caught, I can learn from them. Like I said, I'm not the best programmer in the world, I'm bound to make a mistake (or five) at some point(s) in time. If my mistakes are brought to my attention, I can look at them, point out the problem(s), find a better way, and add to my notes so that I will (hopefully) not make those mistakes again.
Note: I actually have a file for each language that I know (or am learning)with code examples and descriptions of what the mistakes are and how not to fall into those traps again. I read them every morning, all of them, in their entirety, in hopes that I'll remember what not to do as well as the examples of what to do. I highly recommend this practice!
Now, what does this have to do with my introduction to this monologue? If I were hard-headed and/or "bad" I wouldn't have learned anything today (regarding my mistakes). I would have just plugged along making the same mistakes again, and again, and again, and I would not be progressing in my craft (programming is art!). I would, most likely, not have ended up with a favorable review, and ultimately, I would have cost the company money rather than being a good investment, and eventually would have been fired. A good attitude can take you pretty damn far in life, and the willingness to own up to your mistakes can be the difference between a valuable lesson that you keep, and a kick out the door. Jobless.
Posted by Brian Tomlinson at Wednesday, June 20, 2012