Painful Lessons: 2006

My first year working full-time was as stressful as it was transformational.

I began my job search in 2005 in the shadow of the dot-com crash. Only one employer responded to my job applications, presumably because of the challenging business environment. My low GPA and lack of real-world programming experiences probably didn't help. I was carrying so much negativity about myself that I actually applied to this employer as a software tester, thinking that I wasn’t qualified to write software. As part of the interview process, they asked me to complete both a software tester exam as well as a software developer exam. I was very surprised and grateful when they offered me an entry-level programming job!

I started at $11/hour which even for that time was quite low pay. However, I was grateful to have a job and was elated to be able to start finally being able to save to buy a proper bass guitar amplifier after playing for years through a flaky Peavey keyboard amp from the late 80s or early 90s. Unfortunately, after working there only a few days, what I encountered filled me with shock and disappointment. I immediately knew that I didn’t want to work there long-term and actually started applying to other jobs the second week I was there.

Here are the reasons that working there was so challenging for me:

• My new employer was a publishing company first and a technology company second. They worked in the test prep space and therefore their projects were very deadline-driven and time-sensitive.
• Priorities shifted constantly and without regard to the cost of context shifting that software developers experienced.
• Offices were tiny and windowless. Lighting was either harsh overhead fluorescent lights or dim table lamps. I developed eye strain issues as a result.
• We weren’t allowed to shut our office doors. Or listen to music with or without headphones. The work environment was filled with distractions and not being able to manage these distractions was very stressful for me.
• My boss was very kind and meant well but he had a loud voice and communicated every changing requirement and rescheduled project verbally and with a great sense of intensity and urgency. His style was to barge into my office without warning and without caring if I was in the middle of a difficult task. I carried this stress and urgency home with me. I remember waking up my partner in the middle of the night talking in my sleep about the “instructor version” of our test prep software.
• Detailed oversight of technical projects was delegated to non-managerial software developers who didn’t have any meaningful authority over their peers.
• Office furniture was not adjustable and ergonomics were poor. My first chair was a non-adjustable chair that was actually tilted to one side! I developed repetitive strain injury my first week at this job and I have continued to experience profound issues with pain ever since – this is one reason that I don’t work more than 30 hours a week now. I spoke up about this situation with HR – I was grateful that they hired ergonomics consultants but for me it was too late.
• Our internet usage was closely monitored and audited. If we visited a single non-work-related site the manager of IT support would personally reach out to us and inform us of the violation! I didn’t appreciate this feeling of not being trusted.
• Pay was pretty low. My sense is that the business was structured to have fairly quick employee turnover and the code quality reflected this.
• The company was run by the founder and his sons and they treated staff like personal servants. For example, the warehouse and physical plant workers were asked to mow the lawns of the managing family. My friend who worked in support was asked to set up the Wii console game in one of the managing son’s homes! I felt like this blurring of boundaries was highly inappropriate.
• PHP was selected as the main language for implementing their products because of its low barrier to entry. Nothing wrong with a language being accessible to beginning software engineers, but if you don't properly mentor software engineers and let them loose with any language you will end up with poor quality software. Which I was not surprised to encounter in great supply.
• At the time, PHP did not have a reasonable package manager so dependency management was highly inadequate.
• In the early 2000s there was an understanding of the value of unit testing in the industry. PHPUnit did exist and was reasonably mature. However, no one at the company wrote any tests. All testing was manual. Sales and support teams were frustrated because of the resulting quality issues.
• We did have a bug tracker / issue tracker but the majority of change requests were communicated via real-time verbal communications.
• Even though there was plenty of work, writing CRUD web apps in PHP didn’t feel intellectually rewarding. I craved the feeling of wanting to continue to learn technical topics. As a result, I applied to an unpaid role at UF supporting a high-performance computing instrumentation project. Sadly, working 40 hours a week and learning how to parse and instrument message-passing C code using OCaml was not sustainable. I tearfully had to quit this role.

Even though I wanted to get away from this place as soon as I arrived, I did learn a tremendous amount here and I had a number of validating experiences.

• They take chances on folks in the very earliest stages of their career. Folks like me who had low GPAs. Students that had not completed a major yet. These kinds of roles are essential in helping build the next generation of skilled software workers.
• They had an extensive and well-maintained internal wiki with lots of testing documents and learning materials. I enjoyed helping to extend and maintain this knowledge base.
• They fully embraced open-source software. This introduced me to the creatively fertile world of the open-source software community.
• My attention to detail, skill at communication, and desire to do only quality work were noticed and rewarded early on. As a result, I was promoted twice in six months to a Developer III role which was the highest tier available to programmers. This placed me above others who had been there for quite a bit longer. The increased pay meant that I could finally afford quality music equipment instead of relying on underpowered entry-level gear.
• I was granted the role of head of QA and entrusted with administering manual testing and code reviews. I also started to learn how to interview and hire programmers.
• I was exposed to the challenges and complexities of evaluating peers and was involved in letting go of folks who were not able to be productive enough.
• I met passionate folks who were excited about their work and contributed to coding projects on their own time. For example, our head of networking and systems administration contributed to Gentoo and later went on to work for Google.
• I learned how rewarding it is to mentor someone one-on-one. So satisfying to see a new hire succeed and become able to to drive projects and take on more responsibilities.
• I helped hire a programmer that I knew from high school – he would walk around carrying a huge C++ reference book and I was drawn to the coolness and mystique of this. Another high school techie friend would also speak of him with awe and showed me his website where he shared a chess knight’s tour program, among other things. He went on to become an open-source Python project maintainer and eventually went to work for Anaconda. This programmer would later on become part of my network and my direct supervisor at a role I held for many years.
• I helped hire another programmer that I would later interview to be my replacement at my next job.

The biggest influences on my work and career development were what I saw as organizational and management failures. To try to make sense of this, I started learning about the craft of software engineering. I delved into the world of early software bloggers such as Joel on Software, Paul Graham, and Jeff Atwood, and would spend hours on the Programming Reddit and Hacker News. I started reading foundational books recommended by many bloggers including Peopleware and The Mythical Man Month. Among many other books, I read all of Code Complete and Martin Fowler’s Refactoring, and started to learn Lisp programming on my own via The Little Schemer and Practical Common Lisp.

I was also hugely relieved to notice that much of the math and theory that I struggled with in my computer science major was not always demanded in many software roles. I encountered very skilled and intelligent programmers that struggled to complete their projects and collaborate with others. These are folks who could maybe grasp certain kinds of problems more quickly than I could, but lacked the perspective and communication skills needed to be successful. I learned that without an understanding of people and processes you can't have a successful software project.

Part 3 of My Software Journey

Part 2: Unsteady Steps: 2002 - 2005