In the past few years I have tried to work and rework my resume. A resume should be able to reflect my past and my future potential. I always wanted to ask “What kind of person do you see in my resume?”
Below are 3 events in my life as a software developer. To me they are significant. To me they are not reflected in my resume. And yet they are a very important part of me, they give a picture into my developer DNA. Neither the interview process nor resume could glean this information about me.
See a problem, speak up, help solve it: A colleague of mine had collected a bunch of us together for a high level design discussion for a new feature (s)he wanted to architect. That was the general methodology we had, get the team together to discuss nebulous ideas. This was the best way to weed out unworkable ideas. Next day I went back to my colleague with the hack and examples of why the feature cannot be designed as discussed. Along with the analysis, I provided a few other possible options that might work. I saw a problem with the design because I had deep knowledge of the building blocks it was going to use. I saw a problem and I communicated at the earliest with the analysis and suggested list of alternatives. IMO it saved time in design instead of finding out later that it would not have been feasible. If I see a problem I have to bring it to attention. I try to have at least one suggested solution, and it may or may not work, but at least it can be addressed sooner rather than later.
What is the main problem?: A customer needed to move a system table off a particular low performing disk. The usual tool used for this purpose is failing with inexplicable error. There had been no changes to this tool for past several releases. One of the version in previous release even worked fine, as tested in-house. A senior colleague of mine was tasked with finding the fix, hypothesized that the C++ compiler created the object code differently. So compiler level debugging needed to be done. He spent about 2 weeks pursuing the problem, when he was called away on a more burning issue, and I was assigned to the problem. I had no where near skills or knowledge of compiler debugging like my colleague. So I was deep in thought about my predicament...how do I fix it? Some time during the next several hours I had an epiphany. “What was the real problem?” The customer cannot move the physical file for the table off a disk.
I created a different mechanism to move if off by stitching together pieces from other solutions. We tested it and gave the special code to the customer. They moved their file off to a different disk in a week. I did not solve the problem of why compiler created a different object for the tool. I just stitched together existing pieces of code to solve the customer problem.
The best part: my colleague said that it was a “brilliant yet simple solution”, and I cherish his comments.
3. When I knew the design was wrong: This was during implementation for upgrade project. It was a project on tight schedule to begin with and then the date was pulled in by a month. My first design for the feature was constrained by stringent implementation constraints by the person managing the project. When it went to QA the feature was failing randomly. I had a haunch that the continuous allocation of memory on heap was causing it to fail at random places in code. In a week I redesigned and reworked the code to work the right way. The feature ran with no problem and I was asked what did I do to make this huge difference. It’s just that I knew the surrounding code, the feature I designed intimately. While intuitively I knew my first implementation was wrong, I had mentally formed alternative paths for implementation.