I work with a 7-person (6 devs and a lead) on a 20-year-old financial reporting application. We either pull or receive data from about 7 different systems where folks record contracts, funding documents, purchase requests, purchase orders, invoices, bills, etc. and pull them all together to build reports and UIs where users can search across all the data, and have it unified in one place. That’s about 90% of our workload, anyway. More recently, we’ve adopted workload from a couple big legacy systems that got sunsetted, where we’re actually the data-entry point, feeding data out to the main billing system.

Day to day, I work on everything from PL/SQL (Oracle’s SQL variant for compiled stored procedures) where the majority of our business logic lives, to VB.NET where two different HTTP Web servers live, as well as a large automated testing suite for that database business layer, to TypeScript where most of our UI logic lives. Occasionally, I might dip into plain JavaScript/jQuery or ASPX to work on older features.

There’s plenty of time spent writing code, but there’s also a LOT of time spent just discussing things among team. Probably about half of the time, overall. Part of why the project has lasted 20 years is that we’ve gotten very good at being able to interpret what non-technical finance and acquisitions folks want. Like, they might come to us and say “hey, can you add inter-departmental purchase requests to report X”, but they can’t always tell us what an “inter-departmental purchase request” is, or where that data lives in the external systems (and that’s not like a criticism, that’s just the reality of the fact that these people are accountants, not engineers). So, we’ll have to probe for specific requirements and/or reverse-engineer it out of an external database.

I also do open-source work in some of my hobby time, which is pretty much all C#.