Latest posts by Sam Lightstone (see all)
- Nine ways hybrid cloud delivers real IT and business benefit - April 13, 2016
- IBM dashDB is here!Keeping data warehouse infrastructure out of your way - November 10, 2014
- Please join me at IBM Insight 2014 for more on #IBMBLU and #BLUEMIX - October 24, 2014
When I joined IBM as a student, I shared an office with another student I’ll call Bob. Bob was an immensely talented programmer who was finishing a degree in engineering mathematics. He was one of the top students in the school and, from what I could gather, also one of the top students in the country. We joined IBM the same week and were assigned to work together. Bob was an expert in C programming, and I was amazed at his ability to pick up any manual and absorb new information. Every day I’d come into work, and there was Bob, a student from my university who had started the same time I did, pounding away at the keys doing advanced programming while I spent my days struggling to figure out pointer indirection and make files. It was brutal, and for the first couple of months I came to work thinking “Today I will be fired.”
The real risk of getting fired was nil, but I didn’t know that. (students rarely if ever get fired for being useless, they just don’t get hired back). I just came to work and tried my darndest to build skills and get work done. Somewhere around four months on the job, I realized that I was starting to get comfortable with what I was doing at IBM. I’d become a pretty fair C programmer, the development process was no longer a complete mystery, and my role in the organization as a tester for the new image-processing API was becoming clear. Heck, not only could I now spell API, but I knew what it stood for. By the time I finished my 12-month internship at IBM, I knew that I was truly skilled at my craft. I was a powerful C programmer, with strong skills in image processing, parsing, graphical interfaces, and multithreaded scalable programming.
The lessons were simple enough: The first few months on a software job are usually pretty painful, especially if you’re joining an existing project that has a sizeable existing code base. Your time will be dominated by climbing the learning curve. While it might feel painful, it’s completely normal. That was 1989, and it would be very rare today to land a job at a major firm as a C programmer without knowing C, but the analogy translates forward in time. Today people get hired all the time for jobs that require skills they lack, forcing them to develop those skills quickly while also learning the existing code base, absorbing the business domain, building a social network, and learning the organizational culture. Software is massively complex, and even the smartest people need time to wrap their heads around the complexity. This process is true for new hires, journeymen, and senior architects alike.
I know that my early success as a student at IBM was due in large part to my sharing an office with Bob. Bob taught me a huge amount about the C programming language and about programming practice. I’ll never know how he picked it up before we joined IBM, but he seemed to walk in the first day knowing everything. In return, I shared my code with Bob, and he was able to improve the utilities he was building as a result. I also did a lot of the painful grunt work he really didn’t want to—such as authoring our 400 page test plan. It was a win-win relationship. The experience taught me the value of a good mentor: A good mentor can teach you a lot and cover your rear.
Times have changed, but the old mantra still seems to hold true for new grads and experienced professions alike: The learning curve dominates the first few months on a software project. If you know that coming in, you won’t be quite so anxious about getting a pink slip.