My Journey as a Software Engineer
My earliest memory of a computer was watching a series of circles appear on an old computer screen, falling in line one by one to form a crooked smiley face. I was fascinated. By pushing some buttons, my brother, sisters, and I could bend the behavior of this device to the extent of our creativity. We could express pictures or ideas using the BASIC programming language and, with a little work, make it beep at just the right moment.
This was an unlikely scenario for the time and place. I was born in 1983 and grew up in the small town of Oakley, Idaho, surrounded by farms on all sides. From the air, the town looked like a green patchwork one might find in a well-worn quilt. The population was around 650 at the time and almost everyone worked in agriculture or mining. Personal computers were rare at the time generally, let alone in my small town. The only person I was aware of who knew anything about computers happened to be none other than my own father. My dad built and owned a computer and programming business called ComTech in the nearest town 20 miles away where he sold computers and wrote software for local businesses. Like the plants in the fields that surrounded our home, our lives are massively influenced by the environment in which we are cultivated. In retrospect, I recognize growing up in my particular family was an incredibly serendipitous advantage to my future hobby and career in software engineering.
The arrival of the internet
Sometime in my early teens, the internet arrived to our home, but in an unconventional manner. This is best described by my dad:
Back then, the only Internet available was from Project Mutual Telephone in Rupert. I did their programming and finally got them to open an Internet line to Oakley that allowed 2 users — first come, first served. The 2 were usually Aaron and the Schenks. Prior to that, we had to call a Rupert line but Oakley to Rupert incurred long distance charges. Oakley to Burley was free, as was Burley to Rupert. So, when I’d close up at night, I’d forward one of our Burley lines to the Rupert line. Then Aaron could call my Burley line from home and, wallah!, we had Internet at the screaming rate of somewhere between 300 and 9600 bps — absolutely free! A guy could download a 10MB file in a mere 2 hours if weather conditions were favorable.
It was amazing! The internet unlocked a huge door to the rest of the world — both in information and entertainment. I got involved in the usual things like downloading MP3s from Napster and messaging through ICQ, but the major event was when I sat down with my dad to attempt to create our first website.
My first website
Our internet service provider gave us a free FTP account for hosting a website. One night, my dad and I sat down at his desk at home, did some searches on Yahoo, and figured out how to create and upload a simple HTML page. I still remember seeing our text show up in the browser on the default gray background of that era. Our website, http://www.cyberhighway.net/~comtech, was live!
The fact I could create anything I wanted and immediately publish it to the whole world blew my mind. I started learning how to build more complex websites, complete with horribly aliased (jagged edges) animated flames, 3D construction signs, and links across pages. I learned tools like Microsoft FrontPage and even landed a site at my own vanity URL: http://welcome.to/thetwighlightzone. I was hooked!
I somehow made my way into an online community that was building a new “ezine” called The Internet Eye — an online magazine discussing the design of graphics and websites. I didn’t have any graphic design experience at the time and didn’t have enough money to buy a graphics editing program, but I managed to contribute enough to the ezine to earn a copy of PaintShop Pro. This is when I started to dabble in graphic design, mostly as a means to build ssssssick websites. I still didn’t really know what I was doing (to be honest, this hasn’t changed), but I was curious and loved learning and experimenting.
A while later, I got involved with a club at my high school called Business Professionals of America. They had a local competition and one of the categories involved developing websites. I teamed up with my cousin and a friend to build a website for our local chapter, which happened to win the local competition and then, later, the state competition. We were able to travel to Philadelphia for the national competition and, while our website didn’t win, I had the opportunity to talk face-to-face with both kids and adults interested in building websites. I also got a glimpse at the tech world (and the world in general) beyond my small town.
Around 1999, Macromedia Flash (which was later purchased by Adobe) started becoming popular and made websites much more interactive and interesting. My parents bought me a copy of Flash 4 and I was on my way.
Over the next few years, my websites incrementally improved.
Turning hobby into business
As most teens do, I needed to make some money in the summer. How does a teenager go about making money in Oakley, Idaho? By either lifeguarding at the local pool or working on the farms. My uncle owned and operated the farms surrounding our house, so he hired me to move handlines (sprinkler pipe) at 25 cents per pipe. On occasion, I also helped the local ranchers brand cattle.
It quickly became obvious I much preferred web development over farming. I needed to find a way to make some money doing what I enjoyed. Through an online community, I managed to talk a business in Seattle into paying me to use my newly acquired Flash skills to create a virtual tour of a house as well as a 360 degree interactive view of a watch. This was the first time I got paid for anything computer-related. I was elated, but inside I felt like I had just tricked someone into believing I was a professional. I guess I kind of did. I also designed a small graphic for another stranger online who sent me an FM radio audio card for my efforts. I had absolutely no need for an FM radio audio card, but was more than happy to do something I enjoyed for any sort of tangible reward.
People around Oakley and clients of my dad’s business also became aware that I built websites, and so they — whether trying to support the local kid or actually valuing my services — started hiring me to build websites and logos for their small businesses. I was even hired by the city council to build the town’s website, which I felt was an honor.
I also started building computers for my dad’s business. Occasionally, one of my dad’s customers would hire me to sit down with them for an hour or two to teach them how to use the computer they just purchased. I started earning enough that my parents let me drop working on the farm.
Around this time, I was invited to teach class for a while at school on web development. I didn’t get paid for it, but the reward was just as good, because I got an automatic A and had no homework. The computer teachers at my school were very encouraging and made a long-term, positive impact on me. Again, it’s not lost on me that I’m largely a product of my environment, though getting repeatedly cut from the high school basketball team also does wonders for improving one’s focus.
Finding work during the dot-com bust
I graduated high school in May 2001. My siblings were all older and had moved from home. My dad decided to sell his business and my parents and I moved to Utah the day after high school graduation. The dot-com bubble had reached its peak and was bursting before our eyes. I had been accepted to Brigham Young University, but wasn’t scheduled to start attending until later that summer. I needed work in the meantime.
Utah was new to me. I had visited brothers and sisters, but I wasn’t personally familiar with the area and didn’t have any connections. I found a map — the paper kind— of the county and, with the help of the internet, marked the location of every business that sounded like it might be technology-related. I printed off my resume and then spent several days visiting every X I had placed on the map.
I wasn’t having any success. I still didn’t have much experience and the businesses didn’t have many jobs.
The very last mark on my map was a business named Yello Networks, a startup located on the top floor of the building at University Ave. and Center St. in Provo, Utah. I walked in and saw three rooms filled with empty desks and two men sitting at a large conference table. They explained they were trying to get internet installed in taxi cabs for riders to use during their transit. They had just laid off their entire staff and the two co-founders remained. I gave them my resume and offered my skills, which they said they needed. They then asked how much I charged and I said $20/hr. They said okay and asked me to start the next day.
In retrospect, this was quite an audacious move on my part. Considering the market at the time, I wasn’t worth $20/hr and I had reached the end of my list of potential employers. But, I was young and naive and it seemed to work out.
Speaking of which, I’ll continue to outline my pay through my journey, as I’ve been inspired by Nicholas Zakas’ post, My (Somewhat) Complete Salary History as a Software Engineer. I understand that discussing pay is often considered taboo. My intention here is only to provide insight for your own journey and is in no way meant to boast or anything of the sort. For a cost of living reference, I lived in Utah during these jobs except for an internship in Houston, Texas.
I worked at Yello Networks for a couple months before it became apparent I wasn’t going to get paid. I did the work I was asked (mostly website updates) and they were satisfied, but they kept telling me the business didn’t yet have the money to pay me. I let them know I would be submitting a small claim case at the courthouse and the next day I received a personal check from one of the owners. It was time to find a new job.
Deciding on a major
Starting at Brigham Young University, I knew I wanted to do something with software engineering or graphic design. I narrowed down potential majors to computer science, information systems, and graphic design.
My older sister had finished the information systems program at BYU a couple years earlier. She enjoyed the program and had landed a quality job at Novell. On account of this, I had a good feeling about the information systems major. I visited the computer science program, but got the sense that it was more theoretical and less practical. I also visited the graphic design program, but could see I wasn’t a budding artist like the other students there and I wanted to hone my software development skills.
I settled on information systems, a major that straddles business and computer science. I was not disappointed. On the computer science side, I learned critical skills like programming, software design, database design, and networking. On the business side, I learned project management, finance, strategy, business writing, marketing, ethics, and organizational behavior. Some graduates, like myself, primarily focused on the technical, while others chose to focus more on business. Having a good idea of what I wanted to pursue from day one no doubt propelled me into a more meaningful and efficient education.
I also decided to do the five year integrated master’s degree program. It was intense, particularly INTEX. The name INTEX stands for “integrated exercise”, where we were placed into groups tasked with taking the knowledge we learned across the different courses and integrating them into a single project. The first INTEX was to research and develop a proposal for a fictional airline company needing technology infrastructure for managing inventory and associated maintenance activities. This proposal included risk analysis, economic feasibility, schedule feasibility, technological feasibility, project planning, hardware proposals, and software design. At the end, we presented to people from real companies representing the fictional airline, hoping to secure their business.
The second INTEX was to develop a Java- and SQL-based checkout and management system for BlockWood Video, a fictional movie rental company (remember those?). It involved handling point of sale, video returns, refunds, memberships, late fees, gift cards, and more.
Both projects were very stressful, requiring all-nighters at campus and at each others’ homes. I had never seen a student cry in class until INTEX rolled around. I couldn’t blame him. Even so, I really enjoyed putting what I had learned into practice and felt it was great preparation for the real world. I also made some amazing friends in the process who remain friends and colleagues today.
I’m often asked if I would choose my same path for education if I had to make the decision in today’s environment. Yes, most likely, but that doesn’t mean it’s the right choice for everyone or that it couldn’t be improved. First, I feel like the information systems program at BYU was a solid educational experience rather than just an expensive sheet of parchment at the end. I’ve heard from alumni of other majors, schools, and bootcamps that couldn’t say the same.
Second, as you’ll see, many of my first job opportunities presented themselves through connections made through school. In the tech industry, finding jobs as an experienced engineer is usually straightforward, but finding your first job as a budding engineer can prove quite challenging. Job placement from the information systems program after graduation was about 99%.
Third, it was a relatively inexpensive option when compared to other universities: at the time, an undergraduate semester of tuition was around $2,000 while a graduate semester was around $2,500. Currently, it’s $2,985 and $3,755, respectively. I was also fortunate enough to earn a scholarship that paid for some of that cost.
That said, while I do enjoy education generally, two years of “general” classes probably weren’t the most efficient use of time as far as career impact is concerned. I feel like most educational options right now are somewhere between too little (short-term bootcamps) and too much (expensive universities with unrelated courses). I have no doubt options will improve over time.
Working part-time
I worked part-time through college with a few stints of working full-time. Primarily, this was so I could pay for the usual expenses of a college student, but it didn’t take long for me to see it would pay long-term dividends. All my jobs were in software engineering. They were jobs where I could take what I was learning at school and apply them to real teams and products. I could make mistakes without fear of not being able to feed a family. I could leave school with experience on my resume, complete with recommendations. I don’t think I can overstate how vital it was for me to have a part-time job in my field of interest while going to school and I would highly recommend it to any aspiring student.
BYU Broadcasting (2001-2002, 2005-2006)
After my short stint with Yello Networks, I managed to find a job posted on a bulletin board on campus. It was a software engineering position at BYU Broadcasting, an on-campus organization responsible for running the university’s television and radio stations. I made between $8/hr (starting) and $12/hr (ending) and helped maintain their websites, which were built in Classic ASP. The web development industry was still young and our practices were even younger. To make changes, we would duplicate the file in production from, say, schedule.asp, to schedule-new.asp. We’d make our changes, test them out, and then, like Indiana Jones swapping an idol for a bag of sand, we’d quickly delete the old file and rename the new (or copy-paste the contents). No version control. No staging environment. Just editing files in production.
BYU Broadcasting was where I started getting noticeably better at programming and dealing with more complex things like databases. It laid the foundation for my future career as a developer. I also had the chance to lead the redesign of their websites, so I was able to scratch my design itch as well. We were also assigned to provide computer support for the organization, which I didn’t particularly enjoy, but it was fine.
I made a great friend, Ladd Morgan, at BYU Broadcasting. I remember us eating Little Caesar’s $5 pizzas day after day, blasting Rage Against The Machine when everyone else had gone home, and playing some good practical jokes on each other and co-workers.
Vermotion (2002–2002)
You may have noticed a gap in my years at BYU Broadcasting. There’s a reason for this. In the summer of 2002, while working at BYU Broadcasting, I was preparing to leave for a two-year mission to Ecuador for my church in the fall. To save up some money, I decided to work full-time (and then some) over the summer rather than going to school. July rolled around and my manager, Wendy Waits, called me into her office. She said she was notified about a law or a school policy (I can’t remember which) that restricted the number of hours per year a student could work on campus and I was soon going to hit the max.
This was very unexpected for both of us. Unfortunately, I was forced to leave BYU Broadcasting, but my manager invited me to drop by once I returned from my mission to see if I might be able to rejoin the team.
I still had a few months before leaving to Ecuador, so I needed to find another job. I managed to find Vermotion, a small software agency who was willing to hire me on a short-term basis. It turns out I didn’t do much engineering at all. Instead, I built insurance application PDFs that could be auto-populated by our system. Frankly, it was boring, but I made some money and it filled a gap.
Mission to Ecuador (2002–2004)
My mission to Ecuador wasn’t supposed to be about software engineering at all. I hesitate even discussing it here because my religious views have changed over time and there are so many preconceived notions from all sides about where I was at personally and where I’m at now and it would require an even longer blog post to detail that journey. Regardless, the mission became part of my journey as a software engineer.
After a while in Ecuador, word got out that I was a “computer person”. A couple guys I lived with had recently been moved to the mission office to assist the mission president. As it turns out, a missionary in the office a few years prior, Carson Fenimore (I never met him — would love if he saw this), had built some software based on Microsoft Access to manage some historical records. The software was in need of some enhancements and new modules, so soon enough I was moving to the mission office to develop software and help in other ways.
Here’s the rub: due to mission rules, missionaries could only get online once a week to send a short email to our families. I didn’t know the first thing about Access other than it was some sort of database, which meant I needed to learn with no googling or online tutorials. Fortunately, I was able to learn enough from what had been previously written and whatever I could find in the help docs. This was a unique challenge.
After four months in the oven, Mister Suite was born (a play on words from Ecuadorians frequently saying “Hey you, Mister!”). Mister Suite was a collection of applications for managing mission finances, commissary inventory, visas, communication, and historical records.
I never expected this to happen on my mission, but I must admit it was nice getting my hands back into code and keeping my skills fresh until my return to Utah.
After my mission, I dropped by BYU Broadcasting. Wendy was still the manager there and kindly re-opened a position for me on her team. It was a seamless transition back into software engineering.
Novell (2006-2007)
Novell was the big software company in town and, as such, I wanted to work there. After I built up some experience, I started applying for software quality engineering jobs. I remember my first interview quite well. The interviewer asked me to work through a simple programming problem on the whiteboard behind him. As I walked up to the board, he said I could use pseudo code to solve the problem. I told him I didn’t know that language. If you’re familiar with the term, you’ll probably find this as embarrassing as I do now. I had never heard the term “pseudo code”. I thought it was the name of a programming language. 🤷♂
Needless to say, I wasn’t hired for the job. Or the one after that. Or … the one after that. On my fourth attempt at applying, I got the call I was waiting for. I started as a quality engineer on the Novell Client application.
Most of my time at Novell was spent re-imaging a bunch of computers and manually running them through a series of written steps to make sure the software was working as designed. We really wanted to automate the process, but the demand for manually testing the software rarely afforded us the time to do so. We started to make good headway toward the end of my time there, but I was never able to see it come to fruition.
Novell is the first place I got to see how a real software company functioned. I was able to see people working in roles I had learned about at school (product management, program management, sales, and customer support), engineering teams working in sprints, and a proper software release process.
I made around $14/hr.
During my time at Novell, I wanted to take the summer prior to my final school year to go work full-time at a company through an internship program. I was accepted to intern at ExxonMobil in Houston, Texas, for four months (we’ll discuss this internship later). My manager at Novell made arrangements to hold my position while I was gone, with the agreement I would return after the summer.
After the internship at ExxonMobil, I came back to Novell. A month later, I saw a position open up at a startup located in one of the buildings on the Novell campus. I was too intrigued. One of my professors was involved in a startup named EnticeLabs, so I met with him as he showed me their new digs and the business plan. I met with the CEO and the small team that existed. They were just starting to design the software. I was excited. I wanted in. But, I also felt bad about potentially leaving Novell after they had just held my position for me over the summer.
While I was on the BYU campus, I received an offer from the startup. I kept going back and forth in my mind. Do I take the offer and join the excitement or do I stay at Novell out of a sense of loyalty? I was anguished. I responded to the email, thanking them for their time, but respectfully declining the offer. I hit send. It hurt, but the deed was done. Or so I thought.
The email failed to send due to problems with the wireless connection. I packed up my laptop and headed home.
On my way home, I decided to discuss the situation with my manager at Novell, Tom Brough, who I really liked and trusted. He encouraged me to take the offer. I said, “Are you sure?” trying to secure approval.
He responded firmly, “Yes, trust me, just take the offer and don’t look back.”
So I did. A few weeks later, the entire division at Novell was laid off. Prior to our conversation, my manager had been made aware of the layoff (which included his own position) and shepherded me out of the impending doom.
RateMyApartments.com (2006–2010)
While I was working and going to school, I was also learning PHP and building websites for my own purposes on the side. Most of them were short-lived, but ratemyapartments.com was one I gave particular focus. From a government agency, I was able to acquire an Excel spreadsheet containing information on all universities and colleges across the US. I then scraped information on 50,000+ apartments from various websites. I used Google’s geo lookup service to gather geo coordinates on the schools and apartments and put them all together into a website where students could easily post and read relevant apartment reviews or housing contracts.
I started learning how I could make money from the website through Google Ads. It didn’t make much money. At its peak it made just a few dollars a day. I decided to plow the money back into the “business” just to see how marketing would have an effect. I decided to purchase a large batch of pens with the logo printed on them. I’d then sneak a shoe box full of them into the campus testing center and, after taking a test, I’d set the box on a window sill in the exit stairway. The box had a sign that said “Free! Take one!”. It was fun watching the website analytics subsequently jump as well as some of the ad revenue.
The Daily Universe, the campus newspaper, caught wind of the website and wrote up an article, which was pretty exciting for me and helped boost traffic. It was all a big educational experiment.
A couple years later, I started receiving offers for the databases I had curated, but I instead ended up selling the entire website in 2010 for $7,250. Some time during my college years, I also sold the xeba.com domain name I had used for my personal website during high school. I believe it sold for $1,100.
ExxonMobil (2007-2007)
Before we talk about my time at EnticeLabs, I’d also like to cover my summer internship at ExxonMobil. A summer internship the year before graduation was a common practice for students in the information systems program. I had my eye on two companies in particular: ExxonMobil and Capital Group. They heavily recruited at BYU and I had friends that went on to work at both companies and had good things to say. I was lucky enough to get an internship offer from both companies and decided to go with ExxonMobil. My wife and I were very excited — enough that my wife took a picture of me signing the contract, anyway.
I spent the summer of 2007 in Houston, Texas. An internship at ExxonMobil was a totally new experience in a new location. They pampered us interns by flying us out in a helicopter to an oil rig off the coast of Galveston, hosting us at Astros baseball games, and taking us out to some fancy dinners. They also sent me a $4,500 check each month, which is much more than I had ever made in the past. It felt nice to be valued and I was thankful for the opportunity.
My internship project was an ASP.NET (Visual Basic) application called the ISUB (Internet Site Unblock and Block) system. It was basically a workflow management tool for getting a site blocked or unblocked on the corporate internet filter. To get the internet filter changed, several different people from various groups like human resources, legal, public relations, and leadership had to give approval in a particular sequence. Prior to my project, these groups mailed around forms and spreadsheets and the process would stall or documents would get lost in the flow. My job was to make an app that controlled this workflow, accept approvals or denials, and notify various actors in the process.
The project was successful and the people at ExxonMobil were great, but I could tell the culture didn’t really fit what I was hoping for. A couple things still stand out to me today:
- This wasn’t too long after the Enron scandal, so processes and controls seemed particularly strict and bureaucracy was hard to cut through. Despite my best efforts (and those of my manager), I wasn’t ever able to get approval and a license to install Visual Studio on my machine. I also wasn’t allowed to bring in my own laptop. So, for my full internship, I remote desktopped into a machine on another floor that had Visual Studio installed instead. It was bizarre.
- Oil and gas was the primary focus and received the heavy investment, while most of the technology (except tech related to drilling exploration) was seen as a cost center and just a necessity to keep the office functioning. I was more interested in working for a business that had a greater focus on technology.
EnticeLabs (2007-2008)
After ExxonMobil and my short return to Novell, I moved onto EnticeLabs, a startup looking to shake up the recruitment industry. At its core, it was an advertising network that matched companies looking for qualified job candidates with publishers (website owners). These companies could purchase ads through our system and we would publish them on publisher websites. The company looking for candidates would offer a referral reward that would get split across the publisher and anyone else involved in the subsequent referral process (e.g., friends referring friends).
This was a truly exciting time and one where the world was our oyster. We had dreams of making it big and we had some of the biggest investors in Utah Valley backing us.
The application we were building was very dynamic and Adobe Flex had recently come onto the scene. Adobe Flex was a software development kit targeting enterprise applications and was based on the Adobe Flash platform. It seemed fitting for our needs, so we dove in head first. This is where I cut my teeth on component architectures and what would be considered single-page applications.
In exchange for the excitement of success and allure of riches, we paid in stress and long hours. It wasn’t long until the snack bar turned into makeshift dinner, the nap room transformed into the hotel away from home, and holidays devolved into short parties in the break room. My wife deserves credit for sticking it out through this journey.
About six months into my time at EnticeLabs, in the spring of 2008, I was preparing to graduate from the information systems management program. I was fortunate enough to receive a full-time offer from ExxonMobil for somewhere around $75,000/yr, plus a generous benefits package like health insurance, vacation, and 401k matching.
EnticeLabs also provided an offer. It was $60,000 with no benefits except the ability to buy stock and the slim chance of becoming wealthy someday.
This turned out to be a very difficult decision for my wife and me. My wife had just become pregnant with our first child and was planning on quitting her teaching job in December. The stability and health insurance of ExxonMobil sure seemed nice. We also liked the idea of an adventure living somewhere new. On the other hand, her family had just moved to Utah and having both our families nearby was a strong reason to stick around. I also didn’t feel very passionate about ExxonMobil, and the idea of EnticeLab’s success and stock options paying out handsomely played in the back of my mind. We decided to take EnticeLab’s offer and, after graduation, I became a full-time, salaried employee for the first time ever.
Unfortunately, things didn’t seem to be working out for the business. For one, the Great Recession was unfolding, stomping on the brakes of most recruiting efforts across the industry. Several other things appeared to be contributing factors, including burning through cash too quickly, lawsuits involving the firing and hiring of a CEO, and the inability to successfully pivot into a profitable business plan.
I could see the writing on the wall, and an opportunity presented itself. I had just finished taking a class on Adobe Flex during my last year of school. My teacher, Bryan Elkins, worked at a company called Rain. I had heard great things about the company and took a moment to talk one-on-one with him about how he was enjoying his time there. I can’t remember who reached out to whom, but soon enough I was going out to lunch with a large crew from Rain and discussing the possibility of joining the company. Their projects looked interesting and they seemed like a high-functioning crew, so I joined Rain in July 2008.
My EnticeLabs stock was diluted over time and eventually turned out to be worthless, but I have the paper as a memento of the hopes and dreams of an aspiring software engineer.
Rain (2008–2011)
Rain was a small digital agency of around 30 employees building software for clients. At the time, it was heavily focused on Adobe Flex projects, which suited my recently-learned skills nicely.
My first project was Aspire, an application allowing users to design their own sports-inspired products like posters, shirts, and trading cards but with their own pictures embedded. It was commonly used for youth sports so the player’s photo could be turned into a piece of memorabilia to share with family and friends. It was the first time I had built graphics editing capabilities like rotation, skewing, cropping, masking, filters, and undo-redo. I even started using geometry and trigonometry fairly heavily. My high school teachers would be so proud.
I was able to roll my experience over to StudioJ, an even more complex online scrapbook designer that produced professionally printed scrapbook pages on photo paper. I’ve never made my own scrapbook, but I can tell you all about embellishments and distressing.
It was fun to see our digital product being used to create tangible products that people actually really appreciated and cared about. It was also refreshing to build products that were profitable for our clients.
In the process, we also managed to open source Watercolor, the graphics editing engine that drove our editors.
I then started building music education software for a couple clients (PianoMarvel and Playground Sessions). We would take MusicXML (the text-based output of music production software like Finale) and use it to render musical notation (sheet music). We then synchronized pre-recorded video from an expert with on-screen piano keys to train the user how to play the piano. Finally, we’d receive input from the user’s connected MIDI keyboard as the user played a piece of music displayed on the screen. The software would grade the user’s performance in real time to provide a Guitar-Hero-like learning experience.
I can’t actually play the piano, but at one point in time I could tell you all about how to properly position notes, beams, and accidentals when rendering notation for a complex musical piece. Even calculus came in handy for this one.
Working for an agency was a superb learning experience. In the three years I was there, I was intimately involved with understanding customers’ businesses in industries I knew little about. I faced technical challenges I’d never encountered before. I was on at least four different projects within three years’ time. This was also the point in my career where I was first considered a senior engineer. Specifically, I was a “tech lead”, meaning I led the technical aspects of the projects I was on.
I also made a lot of great, long-term friends and colleagues at Rain. I really bonded with the team and we had a lot of fun together both inside and outside of work. I’ve worked with a handful of them on various teams at my current job, which we’ll get to shortly.
One thing I did not like about the agency life is that I was still stressed out and working a considerable amount of overtime. When bidding for projects, we would usually provide clients with dates for milestones up front. We tried very diligently to hit these dates regardless of circumstance, change in scope, or potential employee burnout. To not hit these dates was a big deal. Sometimes the estimation of these milestones did not involve the engineering team at all, which would add special surprises into the mix.
The other thing I didn’t enjoy about the agency life was tracking how we spent our time— in writing — down to 15-minute intervals. Particularly, I didn’t like the effect it sometimes had on how we approached engineering. At times, I could see an architectural problem likely to cause a maintenance headache later down the road. If it were my own product, I would likely take some time during the software development process to pay down the debt before adding more to the pile. This was particularly tricky to do from the position of a project-based agency and gave me the sense I wasn’t in a position to curate and foster a product I cared about for the long haul. Instead, the process was more oriented toward building the product, shipping it, and moving onto the next project. As I’ve learned throughout my career, this approach isn’t isolated to Rain, but it did seem accentuated in the agency life.
An interesting aspect of joining Rain is that I was given the opportunity to buy a piece of the company, which I did. For $4,000, I was able to own a 1% stake in the company, but if I left before a certain time period, I had to sell my share back to the other owners rather than continue to hold the share. I feel very fortunate the founders provided this opportunity — and not just to me, but to all employees at the time. It allowed me to see the business from an ownership perspective and get a better idea of how it was run financially and operationally. It also provided a small financial benefit to me during my time there.
As you may have noticed, I had been a fan of Adobe products for a long time. I had also attended their conferences in the past and I respected the company generally. They had just acquired Omniture, a local business, less than two years prior and a couple co-workers had recently moved from Rain to Adobe. I expressed interest about working for Adobe to one of those co-workers, John Anderson, and he was kind enough to refer me for an open position. I met informally with the hiring manager and was considering making the move, but was still on the fence.
One factor in this decision was that my wife and I had recently discovered our daughter had a severe disability and would need considerable medical care. I needed to be more available at home to help — both physically and mentally. Rain had also just moved to a high deductible health plan that would end up costing us thousands more in medical costs.
One day, my teammate Nate Ross and I were in a meeting with our client. For reasons I won’t get into, there was an oversight when bidding for the project and, as a result, it caused a large change in scope and a significant impact to the delivery schedule. The client had been notified about the schedule change, but nobody had explained the cause to the client. The client flew to Utah and was rightfully incensed. Nate and I attended this meeting alone with the client and were genuinely very sympathetic toward the client, but weren’t given the liberty to disclose any details on the matter. The responsible parties from Rain skipped the meeting, putting us in a very awkward situation.
After the meeting ended, Nate and I were emotionally spent and took off to get milkshakes. Nate is a good friend, so I mentioned I had been speaking with Adobe and was on the fence, but after the recent drama, I was leaning toward leaving Rain. He revealed he had been speaking to Adobe too and felt similarly. A few weeks later, we were both at Adobe.
Unfortunately, I don’t remember much about my salary at Rain. From tax records, it seems my starting salary was somewhere around $75K and ended around $95K. When I put in my two weeks notice, I was offered an increase in salary, but I had made up my mind and made the move. I also had to sell back my share of the company.
Adobe (2011-Present)
It didn’t take long to realize that I would enjoy my time at Adobe. I could tell it was a very value-driven company and employees seemed to be treated in a way that was conducive to longevity. While we would have one late night (sometimes very late…early morning) software release every month, working overtime was uncommon and I was pleasantly surprised to see an empty office after 5:00 on a Friday. Even the late night software releases have dissipated over time. The company worked hard to positively impact the community and promote respect and service inside and outside the business. Employees were largely competent, eager, and desired to contribute to the success of the company. Top management seemed to have their heads on straight.
I’ve been employed at Adobe for nearly 10 years now, which, as you may have noticed, is much longer than any of my previous jobs. This is mostly because of how events naturally transpired, but I also think it’s a decent strategy new engineers should consider. In your early years, I would recommend moving between companies at a shorter interval for multiple reasons. First, it gives you the opportunity to explore what’s out there: what projects you like, what technologies businesses use, what size company you prefer, and how different teams function. Second, you can usually advance in responsibility and pay faster when moving between companies. Being seen as the beginner engineer at your first job can stick with you for quite a while and increases in pay are typically incremental relative to your current pay. By moving to a new company, you’re being evaluated in the context of the role they are trying to fill, and pay is determined by your experience relative to the market rather than your current pay.
Speaking of pay, my starting salary at Adobe was $105K with a sign-on bonus of around $17K in Adobe stock (now worth about $275K if I still owned it!).
Throughout my 10 years, I’ve worked on a variety of projects and have grown through each one. I’ll try my best to hit the highlights.
Adobe SearchCenter
I started at Adobe on the SearchCenter engineering team. SearchCenter allowed customers to more effectively bid on search query terms for advertising on search engines. It was a PHP-based site and there was a lot of opportunity to improve the user experience if it were converted to a single-page application. I was specifically hired to lead the effort of rewriting the application in Adobe Flex, which I had been using for the last several years.
In April 2010, a year before I was hired, Steve Jobs had posted a meaty rant about how the Adobe Flash platform was a detriment to Apple’s phones and why Apple was dropping support for it on iOS. This caused a ripple effect that prompted Adobe to announce, in November 2011, they would stop developing the Flash Player for mobile browsers and focus on advancing HTML5. The death of Flash and Flex seemed eminent, especially from the inside.
This occurred just after we had started prototyping a rewrite of SearchCenter in Flex. This same month, Adobe also announced they would purchase Efficient Frontier, a SearchCenter competitor, which would shake up the roadmap entirely. There would be no rewrite in Flex. SearchCenter would be replaced by the acquisition.
This marked a significant point in my career where my knowledge of Flex was suddenly worthless, my role was unknown, and I needed to adapt or become irrelevant. Fortunately, many of the patterns I had learned translated well into the development of JavaScript-based applications and components.
Around this time, things at home turned hectic. Not only was our daughter struggling more with her disease, but we had a newborn (our second child) to take care of and we discovered my wife had cancer. Within a couple months, my mom and father-in-law discovered they had cancer as well. It was a lot to deal with. I typically compartmentalize my work life and family life and try not to let one affect the other, for better or worse. That was certainly true during this time as well. I wouldn’t be surprised if a psychologist were to tell me I internalize to an unhealthy degree.
Adobe Analytics
My SearchCenter manager, Dave Sliwa, was cognizant enough to realize that having me stay on the SearchCenter product would lead to a dead end, so we agreed it would be best for me to move to a team that was prototyping a new social feed that would aggregate marketing activities for our customers. This stint didn’t last long, as the Adobe Analytics team needed someone to lead the frontend development of their product and I was quickly pulled in to fill that role.
It was around this time I started learning Backbone.js and RequireJS. Backbone.js was one of the first JavaScript libraries used to structure single-page applications, while RequireJS was one of the first JavaScript bundlers. In retrospect, they were both relatively primitive, but they provided much-needed structure.
This is also when I started ramping up writing technical articles and speaking at conferences. I began to realize how much better I learn material if I’m preparing to teach it to others. I also learned how much I enjoy helping other people grow and succeed. This has fueled my desire to mentor other engineers through the subsequent years of my career.
As a short intro, Adobe Analytics allows customers to send data from their websites to Adobe’s servers. Adobe’s customers can then use Adobe Analytics to analyze that data and discover important insights like how users arrive at and move through their website, where users get frustrated and leave, and what factors affect how users choose to spend their money and attention.
While on the Adobe Analytics team, I built Anomaly Detection and Real-time Reports. Anomaly Detection uses statistical analysis to notify customers when an anomaly is detected on their website, while Real-time Reports provides information about user activity on their site while it’s happening.
I really enjoyed this work, as it let me flex my newly-acquired JavaScript skills and it solved interesting use cases, but it was short-lived. The organization shifted focus to dedicating nearly all engineering resources to resolving product issues affecting our top customers. These issues were almost all in backend PHP code, so that’s where I spent my time for about the next year. While I enjoyed the satisfaction of resolving long-standing issues for customers and thought it was a smart move by the organization, working in decade-old PHP code wasn’t nearly as fun as the type of work I had been doing, and I was excited to get back to my jam.
CoralUI, React-Coral, React-Spectrum
I eventually moved to a team focused on tools that cut across products. I loved our mission, because I had seen a big need for it while on my previous teams. For example, each product team was spending massive amounts of time building the same UI components and visualizations that other product teams were building.
CoralUI, React-Coral, and React-Spectrum were various generations of a JavaScript component library that could be used across products.
Around this time, client-side technologies became quite diverse at Adobe, but many teams seemed to be gravitating toward React. Then, the Adobe legal team shut down usage of React due to its controversial licensing patent rider. Then, about a year later — just long enough to get some teams to transition off React — React removed its patent rider. Not long after that, React not only became accepted at Adobe, but was mandated from the top as the only framework to be used. It was a bit of a mess, but in the end we were able to standardize on a common framework at Adobe. There was definitely angst from some engineers about a top-down mandate, but the significant gains achieved by targeting a common technology are difficult to refute. Sometimes technology choices are out of your control. Don’t take it personally.
This component library we worked on eventually matured into what is now React-Spectrum, an open-source component library not only used throughout Adobe products but also in applications across the web.
DV and CloudViz
Similar to how product teams were building their own components, they were also spending a lot of resources building their own visualizations. I was able to help build common visualization libraries using D3.js that provided simplicity and standardization across products. I also learned a lot about visualization grammar and how to build flexible APIs.
Totem
Totem was a code name for a project that never actually saw the light of day. My team set out to create a dashboard system that allowed customers to pull data from across our marketing products into a single view. It was primarily intended for executives to get a quick view of how their business was doing and be able to dig further if they were interested in doing so. After about a half year of development, our executives pulled the plug.
I mention this project because it’s a common scenario you may encounter in your own journey. Priorities change. Projects get defunded. Employees get moved to different teams. It happens. Again, you’ll be happier if you don’t take it personally.
Adobe Experience Platform Launch
Adobe had recently purchased a product they rebranded to Dynamic Tag Management (DTM). In simple terms, the product made it easier for customers to implement marketing technologies on their websites. There are thousands of marketing technologies and most require customers to copy and paste a block of code into their own website, then configure the code according to their needs. This is a pain for customers for many reasons I won’t get into here. DTM’s purpose was to allow the customer to copy-paste a single piece of code onto their website one time, and then install and manage all their marketing technologies through the DTM user interface.
DTM had its limitations and was lackluster at supporting third-party products. After much consideration, we decided to rewrite the product. The new product’s name became Adobe Experience Platform Launch.
Launch became similar to an app store in that product teams and marketing vendors could build and maintain their own Launch “extensions” and customers could then install those extensions on their websites using our platform.
This was a large, multi-year project. I was assigned to lead the architecture and development of the extension platform, developer tools, and the JavaScript library deployed to customer websites. I also helped some with the Launch user interface, which is a single-page app built in React. Launch officially … launched … in 2017. 🚀
Over time, I gravitated toward working with extension developers and customers. I enjoyed answering their questions, helping them through their problems, and improving the product based upon their feedback. Writing clear and useful technical documentation also became very important to me. It started to really sink in that the most important trait for an engineer is empathy. Care about the customer, a fellow human wanting to go home and spend time with family rather than struggle through another frustrating user experience, and everything else will fall in line. This is when I grew into a role known as developer advocacy — at least enough that it became an official part of my title. I still spend the majority of my time developing software.
During my time on Launch, I was also formally assigned to be a mentor to a summer intern who later became a full-time employee. I really enjoyed this experience. It was refreshing to see through the eyes of someone new to the industry and help her navigate through the maze of complexity that frontend software engineering had become. In many ways, it was nostalgic — not unlike this blog post. She’s also a good human and fun to work with. Shout out to Celeste Robinson.
After I was no longer officially her mentor, she still wanted some additional mentoring and I enjoyed it, so a small group of us continue to have a weekly Mentoring Moment™ where I guide discussion about a piece of technology or work through a problem someone’s been having. I’ve been able to less formally mentor other engineers over the years and I hope to continue and perhaps expand my role in this area.
Launch also gave me the opportunity to get more involved in the open source community. Because of the nature of the product, it made sense to open source almost everything I worked on and publish npm packages. I had been doing some of this on the side, but it was great to get more experience while getting paid for it.
Adobe Experience Platform Web SDK
A few years back, Adobe decided to re-think how we manage data on behalf of our customers. We no longer wanted to have silos for each of our products, but instead have all the data they share in one place. The system needed to support ingesting large amounts of data from a variety of sources and stitch it all together. It also needed to be fast, privacy-oriented, and intelligent. As a result, Adobe set out on a massive, multi-year project called Adobe Experience Platform.
As part of this effort, we also needed to re-think how our customers implemented Adobe’s marketing products on their websites.
Customers had been implementing a separate JavaScript library on their website for each Adobe product they used. Launch simplified the installation process, but it was still a disjointed experience and had several pain points we wanted to solve. We were able to replace all the “legacy” libraries with a new, single library written from the ground up called Adobe Experience Platform Web SDK.
The project didn’t come without skepticism. First, the organization had never done something quite like this before. Each product had its own managers and engineers that needed to be deeply involved and nobody had worked across product teams in such an integrated fashion. There were concerns that some teams might not play nicely with others, since they had their own priorities and motivations.
There were other concerns that it was a technically difficult undertaking. The old libraries and their corresponding servers were handling over 200,000 requests per second and had more than a decade of history behind them. They were battle-tested across many of the largest websites on the web we all use each day. We planned to shift all that functionality to a new library communicating with new servers through new APIs.
Over time, we eventually got buy-in from all the requisite product teams and kicked off the project. Product managers and engineers from separate teams bought into the vision and came together as a virtual team to collaborate. A year and a half later, we released Adobe Experience Platform Web SDK.
This is my current focus in my career. It’s been a very rewarding project, but also challenging. How do we take all these business requirements from our products and consolidate them into a cohesive, unified experience? How do we find the balance between sophistication and simplicity? How do we design it in a way that’s backward-compatible, yet forward-looking? These are the hardest challenges I face each day. Sometimes it can be very frustrating, but when a customer tells you they’re happy with the solution, it can also be very rewarding.
Things I’ve learned
Here are a few random things I’ve learned along my journey.
- Your team is the greatest factor in job enjoyment. Sure, the project you’re on, the technologies you use, and how much you get paid are certainly contributing factors, but when it comes down to enjoyment, nothing beats teammates you’re excited to work with.
- The greatest software engineering skill is empathy. I mentioned this before. If you have empathy, you’re more likely to create delightful software because you care about those who will use it. You’ll create maintainable software because you care about your teammates. You’ll learn what’s necessary to accomplish both.
- You can be a great software engineer without being popular on Twitter. There’s this notion that it’s nearly impossible to become a great engineer because they’re the ones with a massive following on Twitter. This is nonsense and can be safely ignored. You can be a great engineer. The very best software engineers I’ve worked with have little to no social media presence.
- Struggling through bugs is not the sign of a poor engineer. It’s the sign you’re an engineer. Googling for answers and trying different solutions is how every engineer learns and — sorry — that process never ends. You just get more comfortable with it.
- Feedback is a gift. Someone took time out of their day to show you how to improve. Don’t get offended. You don’t have to agree with the feedback, but consider it, appreciate it, and encourage it.
- Don’t stop learning. This industry moves too fast to stay stagnant.
Where is my journey headed?
In the near term, I see a few viable options, none of which are particularly exclusive:
- Increase my scope of responsibility while staying skewed toward frontend development. I can contribute at a higher architectural level that considers more products and integrations. I can translate strategic business goals into design and implementation while leaning on the technical expertise of others for pieces of the system that are less familiar to me.
- Fill more of a mentoring role. This probably requires me pulling away from my own tasks and focusing on helping others work through theirs.
- Increase my focus on developer advocacy. My current role is split between engineering and developer advocacy, with most of my time going to engineering. I enjoy both roles, but shifting my focus to developer advocacy would allow me grow in ways I haven’t fully explored yet.
- Increase my infrastructure skillset. I have limited experience in a lot of the new server-side technology and increasing this skillset would certainly be a new challenge. This would include, among other things, containerization, deployment, message queues, data storage, network topology, and related backend engineering.
- Enter a managerial role. There’s a common (mis)conception in the industry that once you are a senior engineer, the only way to progress is to become a manager. I don’t buy this, since an engineer can provide increasingly more value within the technical realm. Adobe seems to understand this and offers separate managerial and technical tracks. On the one hand, I’d like to explore my abilities in a managerial role and see if I enjoy the responsibilities. On the other hand, I really enjoy solving technical problems and would likely miss coding. I could see myself moving into a managerial role if I had some confidence I could move back into a technical role if it wasn’t a good fit.
My long game is to probably create my own business, either by myself or with others. The business would most likely be a product company, rather than a services company. While not a requirement, I like the idea of being financially independent when I start this process. I believe it would allow me the flexibility to take the time and care to create something truly remarkable, rather than being influenced by the need to please investors or feed my family. I want passion to be the driving force.
As I’ve grown older, it’s hard not to notice how the increasing reality of my mortality has shaped my perspective. At its worst, my job is just to help companies make more money. At its best, my job is to alleviate frustration of real people and help them lead more enjoyable and productive lives. I definitely nerd out on technical innovation and learning new skills, but when I die I want to have made a positive, lasting impact on humanity. In the end, I may not accomplish this through code; it may be a different journey altogether.
