In May of 2024 I was promoted to the role of Lead Software Engineer of the Simpson Strong-Tie CS Director team.

I lead the the Simpson Strong-Tie CS Director team from a development perspective; including planning out and prioritizing work with Product Management and other stakeholders, organizing work in our Project Management tools, partnering with Engineers who own specific features and projects to ensure their success, and continuing to participate in the team's work as an individual code contributor.

I also mentor the engineers on my team, partner with them on their goals and where they are wanting to take their career in the future, and make sure they have what they need to do the work they are being asked to do.

The CS Director application is a large WPF based on-prem distributed desktop application that forms the core of our customers truss manufacturing businesses and organizes their production, billing, and design operations under one "roof".

Responsibilities:

• Organize, plan, and when ready delegate projects to the engineers on the team as project leads.
• Support and partner with project leads on the team to see projects through to completion.
• Create Proof of Concepts and initial architecture work for upcoming projects.
• Mentor and train engineers on the team.
• Advocate for and implement changes and improvements to the team's processes.
• Serve as the technical point of contact for stakeholders outside the team.
• Coordinate with the Product and UX teams to ensure upcoming work is adequately documented and ready for work.
• Participate in higher level cross-team architecture, planning, and software direction discussions.

Key Takeaways:

• I won't be taking complete project ownership as much as I have in the past; I can't commit to the time it requires amongst my other responsibilities.
• This marks a shift away from what I can do as an individual and towards what I can do for the team.
• I'm really excited about this shift and am looking forward to serving my team in this capacity.

At Simpson Strong-Tie I serve as a senior software engineer on the CS Director team.

Specifically I serve as the technical lead of my team. This means that I lead the engineering efforts of my team in the planning, discussion, and implementation of new features, improvements, and bug fixes to the products we are responsible for. This often involves lots of meetings with stakeholders in both my team, other teams, and at times customers to make sure the work we are doing best meets the needs of customers.

The other engineers on my team don't report to me, but I consider it my core responsibility to make sure they have what they need to achieve the team's goals.

The CS Director application is a large WPF based on-prem distributed desktop application that forms the core of our customers truss manufacturing businesses and organizes their production, billing, and design operations under one "roof".

Responsibilities:

• Review PRs from teammates and assist them as needed.
• Participate in planning, preparation, and implementation meetings as needed.
• Work on sprint work and other items in an individual contributor and project lead capacity; taking ownership of projects where needed.

Key Takeaways:

• I don't implement as much as an individual contributor as I used to and I have learned that there is much greater joy and accomplishment to be found in enabling and equipping my team to be more successful.
• A small team that works well together is far more valuable than a single extremely strong individual contributor.
• A dedicated note taking application and a daily process of recording what has been and needs to be done on that day has been extremely helpful. I've had a lot of luck with Obsidian .

I ended my time at Logos as a software engineer level 2 on the Sermon Tools team which is responsible for the Logos Sermon Builder and Sermon Manager tools across the Logos desktop, mobile, web applications, and their associated backend services.

I (along with my team) was responsible for all aspects of the sermon tools from planning, implementation, and ending with deployment across the various applications that used them. This includes the backend service and database that housed Sermon data, the shared React web components that made up the UI, and the points of integration in the web, desktop, and mobile applications.

This was a real full-stack experience and represented an interesting approach to managing a software project. From the surface one would think that a whole team (several devs, a lead, and an assigned UI/UX representative) for just these two features was overkill, but when taking into account how many different things are involved it made a lot of sense.

This role also served as a continuation of my experiences on the Logos Desktop team. I continued to lead the development of several new features and improvements, and had even more opportunities to grow and acquire more responsibility.

Responsibilities:

• Create the backend code in SQL and C# for the services that wind up running in azure for a new feature or bug fix.
• Add support for new backend features or bugfixes in C# WPF, objective-c, swift, and typescript in each of the applications that expose the Sermon Builder or Manager (depending on which tool the work is for).
• Add the typescript and react code necessary to the appropriate component for users to interact with the new feature or bug fix.
• And lastly, I Test and ship the changes end to end; a process involving Terraform, Github Actions, and maybe Jenkins.

Key Takeaways:

• React can be very annoying, and it's not my first choice for a web frontend framework.
• Rich Text Editors are really really complicated. Adding IME and RTL text to the mix just makes things even more complicated.
• Sharing UI between desktop, mobile, and web applications is a really neat solution to reducing code duplication between applications, but it isn't simple to set up.
• Robust distributed data synchronization between local customer housed data stores and cloud hosted databases is very complicated.
• A well established automated build pipeline is incredibly helpful when developing a component that is consumed in many consumers and save a lot of time. That same tooling can also be used to do anything that can be implemented in code. The limitations are only those of your imagination.

I began my time at Logos as a software engineer level 2 on the Logos Desktop team which is responsible for the Logos Desktop Application on Mac and Windows, and occasionally on some backend web services.

This was an amazing experience for me. I was able to develop a lot of experience working on a robust code base using technologies that I had previously only been able to dabble in or only worked on in a sole contributor role. It also gave me the chance to really learn what it meant to work on a team closely with other software engineers and to experience how coordination with a UI/UX team could work.

I was also afforded a lot of opportunities to take ownership of the development of new features from planning through implementation, and that gave me a taste of leadership that I hadn't had before. I had led the development of features before but never had a chance to really lead an effort and have other engineers working with me.

Responsibilities:

• Work in the Logos Desktop Mac and Windows code bases to fix issues, implement new features, and enhance existing features.
• Participate in meetings regarding new upcoming features and improvement work including evaluating specifications provided by the UI/UX team.
• Review code for other teammates.
• Make improvements to the shared infrastructure that other teams use to interact with Logos.

Key Takeaways:

• A well refined long lived C#/WPF codebase can be a really cool thing to see.
• Objective-C can take a lot of getting used to, but it is an extremely powerful object oriented language and almost certainly underrated and held back by being tied to the Apple ecosystem.
• Having UI/UX support readily available on a team is invaluable when creating new UI for customers. Software Engineers generally do not make the best UI/UX designers.
• Logos was always willing to let engineers take the lead on new feature development and other work, even if they didn't necessarily have the experience for doing so. They gave me a lot of opportunities and chances to succeed that forced me to grow, and I really appreciate it. Trust your engineers, even junior ones.

At Drake Software I lead the software development efforts of the Data conversions team and assisted in the development of various features and tools for other teams.

Drake Software was my first experience working full time in a company where software creation was their business. My work on the data conversions team was pretty fun; I had many opportunities to reverse engineer complex file formats and create code for parsing them and mapping them to Drake's own formats and was exposed to the wild world of code generation. There was only one other developer on the team and they were largely responsible for data mapping so I had a lot of responsibility and freedom to maintain and improve our conversion applications and tooling.

I also blew up my first production database, and quickly learned how important it is to not just have backups of critical data, but also know absolutely certainly that the restore process for said backups actually works...

In addition to my responsibilities on the data conversions team I also led a number of projects on other teams in wildly different tech bases.

Responsibilities:

• Improve, update, and maintain the WPF tooling and desktop application that manages the data backing all of Drake's conversions.
• Improve, update, and maintain each of the C++ Drake Software conversion applications.
• Map data between other applications and Drake Software's data model.
• Assist other teams with their projects as needed and available (Winforms and Angular)
• During tax season answer support questions from Drake Software customers.

Key Takeaways:

• Code can be data, and generating code for data can be a perfectly viable way to ship data to customers without needing to worry about the format to deliver it in or any runtime issues.
• Reverse engineering undocumented file formats can be very fun.

My first experience as a professional software engineer was at Lewis Taylor Farms (LTF)

A couple of years before I came along a University of Georgia graduate student created a .NET/WPF based inventory and greenhouse management application for LTF to use to manage their growing business. This student moved on and I was hired to continue working on and maintaining the application.

This included coordinating with LTF employees to determine requirements around new features, fix bugs, and maintain the infrastructure that the application relied on.

The application used a WPF client on individual user machines backed by an on-premises MySQL database for storing data.

All LTF orders go through this application, and all seed inventory, customer, and much employee information is managed in it as well.

Responsibilities:

• Improve, update, and maintain the LTF Greenshouses desktop application and infrastructure.
• Coordinate with LTF employees for the adding of new features and addressing bugs.
• Design and implement new tools and processes around the application.

Key Takeaways:

• DB indexes are very important; the DB had none when I inherited it and adding them dramatically improved application performance overnight.
• After some not so great application updates I created a development and testing environment that lived alongside the production one and it proved invaluable when evaluating new features and using LTF employees as QA.

Projects:

• Created an automated backup application to take snapshots of their production DB and move them to a long term storage device.
• Implemented an automatic update feature using WinSparkle that was very successful.
• Made many dramatic improvements to their DB schema and made further improvements to application performance by improving how the application interacted with the DB.

At the University of Georgia (UGA) part of the Graduate Assistants I was offered included serving as a graduate teaching assistant which quickly grew into taking on full instructor responsibilities for a couple of years.

In my role I served as an instructor for a couple of introductory Computer Science classes:

• CSCI-1301: Introduction to Computing and Programming
• Intro programming course. Used Java while I was there.
• CSCI-1730: Systems Programming
• Introduction to Linux/Unix and C++.

Responsibilities:

• Create course work, prepare lesson plans, and lecture in class for a variety introductory computer science classes at UGA.
• Coordinate course work grading with other teaching assistants.
• Hold office hours to help and support my students as necessary.

Key Takeaways:

• Teaching is really hard, but I also really enjoy it.
• Graduate students were ill prepared and equipped when they begin their role as instructors.