Spencer Pope

Work

If you found your way here from somewhere else on the internet, check out the home page for a brief-ish overview.

Resume

For a terse one-page overview of my professional experience, you can download my resume here. I also built a React-based widget version of my resume that you can check out on my resume page.

What I've done

My resume is boring…

… So, I'm writing this post as an exercise to start changing that. One thousand interesting words about my professional career will hopefully follow.

It started in 2017. The owner of a local tech company asked me if I liked messing around with computers when we met at my university's job fair. I told him I did, and I started as a software tester for Instant Technologies in Portsmouth, New Hampshire a couple of weeks later. The company sold instant messaging software, so I would use the application and report anything that seemed off to the developers. They considered the input from the testers and decided which items were worthy bugs that should be fixed. It was the first time I saw software development in real-time and grasped the concept of priority as it pertains to a team of workers making something.

First corporate job

The following summer I had an internship with Sovos in Wilmington, Massachusetts. They sold tax compliance software. As a product management intern, I shadowed developers and stakeholders during their scrum ceremonies. The only thing they encouraged me to do was study the methodology they were running. I'd focus on one scrum team for 1-3 weeks and have one-on-ones with its members to ask for career advice and get their thoughts on the department. I'd also ask if I could help them with anything and occasionally a developer would teach me how to build a form or a product owner would have me write some user stories. Learning how the business value of several different applications was delivered to clients using the same methodology across each team taught me how small groups of people can set goals with ambitious timelines and meet them by planning and executing.

Learning software development

After that, I finished college and started as an Applications Analyst at Definitive Healthcare in Framingham, MA. I took this role because it was the closest any company I interviewed with seemed willing to let a lowly business student get to their application code. I was glad to be surrounded by engineers. The company sold its clients access to a web app that allowed them to create reports from healthcare data Definitive was buying from the government. The app allowed users to query about twenty different databases that we referred to internally as products. A product might provide specific information regarding hospitals, physicians, or long-term care facilities. Some products were as specific as renal dialysis centers, and each of these had a corresponding database. Users were able to choose which product they wanted information from and fill out a form specifying filters to be applied to the database. The forms were built with ASP.NET on the front end, which is a scripting language that allowed us to build custom filtration forms for each product from a shared design template. On the back end, C# controllers would ingest the user's inputs and apply them as parameters to a SQL stored procedure that was executed against the database. The controller would then return the resulting dataset to the client which was displayed as an ASP.NET datatable. As an Applications Analyst, I built new products with this design pattern when the company acquired new data. I made adjustments to existing products by committing changes to both the SQL and .NET codebases. I solved bugs that came in from the product support team and made copious laps up and down the repositories while investigating them. I learned the tenets of source control and practiced the ABCs of being a software developer while supporting the product's evolution.

Becoming an engineer

My team took learning on the job seriously at Definitive, and we decided to learn the popular JavaScript framework React.js. Motivated to apply our new skills, we collaborated with engineers to develop a new build step in the application's deployment process that transpiled a TypeScript/React project and added it to the .NET app's minified JavaScript. This allowed us to render custom React widgets inside any known elements in the legacy application. We also developed a REST API using Node.js that could run stored procedures against the database and return results to the client in JSON format. Subsequently, we engineered a new workflow that allowed us to build custom client-side user interface features and integrate the company's data independent of the rigid framework we were previously confined to. The first feature my team produced with this pattern was an everpresent quick search field that users could enter a term into from anywhere in the application. We built a custom results page for quick searches that displayed relevant data grouped by product. This was the first search that allowed uncertain users to query all the products they had access to at a basic level. It also displayed a limited number of rows from databases the user did not have access to and encouraged them to contact their customer success rep to purchase full access to that product. The success of these features elevated my team to new roles as Applications Engineers and solidified the legitimacy of our new React-based development workflow. We drove all these changes to the organization in two years while simultaneously adopting git for source control, automating manual deployments with Azure DevOps, and migrating from dedicated servers to the cloud.

Working for a startup

I left Definitive Healthcare to pursue a role building React apps, and landed at a startup in Reno, Nevada called Blockchains Inc. They were building software that used the decentralized protocol Self Sovereign Identity (SSI) to share data between entities. I joined the Web Team as a Web Engineer where I was responsible for building user interfaces that implemented a REST API the Backend Team provided. I worked closely with backend developers when testing new endpoints they delivered. A problem I noticed early on was that I would receive user stories from product managers that included a Figma file they collaborated with the Design Team on, but no technical details. It was up to me to determine how to achieve the functionality implied by the design. I would talk to the Backend Team about this who also collaborated with the product manager on their API, but it was commonly obvious that the API endpoints for a feature were developed in isolation of the UI designs. It then fell on me to reconcile the differences. In my time there I built the onboarding flow of the application and reused the React components I built for it to create two more flows that were core to the application. Onboarding involved the user creating Verifiable Credentials for their account which are the standard units for sharing data with SSI. The creation of Verifiable Credentials became thematic to the app's core functionality, so building reusable components that enabled credential creation was critical for scaling functionality throughout the app while keeping user experience consistent.

Leading a team

Ten months into the two years I spent at Blockchains my manager left the company and I was selected to replace him as Technical Lead of the Web Team. This meant retaining all of the responsibilities of a Web Engineer while also inheriting ownership of the team's methodology and our app's architecture. It became my job to know the expectations of the product department and to make sure my team's needs were understood by the other teams we depended on. Communicating my team's technical capabilities through both discussion and documentation became a way to empower the company to solve problems collaboratively instead of in silos. We then bootstrapped a new React app using Next.js and migrated all of the functionality we had built in the legacy app over to Next.js. During the migration, I made architectural decisions to deviate from bad practices that were holding us back in the legacy app. The old app used a store to hold large amounts of global state. Many would have reached for a state management library to streamline that developer experience, but I opted to simplify our state management strategy altogether so we didn't need convoluted data stores or third-party tools. I hired two senior developers to advise me on architectural best practices and one junior developer who I learned even more from by teaching things I thought I understood.

What's next

I'm now looking carefully for my next opportunity. Check out my Now page to read about what I'm doing now.