Programming

I'd call myself a backend developer. Primarily we build data stores and APIs that encapsulate low-level business logic for cloud applications. Some backend teams mostly make CRUD APIs, but my team tends to work at a lower level, such as file objects, transformations, CDNs, bulk operations, etc.

Things we have to deal with include:

• If holding 100 billion objects is expected, we need to figure out the most important access patterns for that data and how to incorporate it into an API that will scale horizontally and have reasonable and stable performance. This can be tricky, as the best solution is sometimes more complex than using a simple SQL database. Sometimes specialized database types, or multiple databases holding different aspects of the data are required. This is very close to the sorts of things a DBA might do.
• If files can be included or attached, we need to design a redundant file system solution for holding those files. Sometimes its as simple as plugging into a cloud object storage like S3, sometimes the requirements dictate something different. Basically figuring out what off-the-shelf cloud solutions we can use and how to use them, or when to build something custom.
• Batch job processing is a big thing. Our biggest project required us to create our own scheduling system based on containers and clusters and autoscaling nodes based on load in order to handle a million tasks per day. This is an example where you may do things similar to what an SRE team might do, managing infrastructure with your code.
• Lots of API design stuff. Higher-level backend developers and frontend developers don't want to know or care about the complex stuff under the hood, they just want us to provide a simple API that just does what they want. Sometimes it can be tricky to design an intuitive API that abstracts over some of the hairy details.
• Cost is a big deal too and sometimes you have to be good at estimating costs and figures. When the operating budget is strained and 80% of it is backend (because well duh, it does most of the work) then management will be looking at you to either optimize costs to run the software, or to prove that the operating costs are reasonable for the expected results.

So sometimes wearing multiple hats. Personally I enjoy what I do a lot because it always presents a challenge. I love solving complex problems, and almost monthly I get to play around with large-scale software problems where the naive approach will almost certainly perform like crap and needs a more clever design.

We're a cloud-first company though so primarily in the context of that.