Programming

May just be bias from my experience, but a lot of back end stuff is cloud now. I had to learn how to design, deploy, and maintain Azure resources. Programming is still in C#, but now I have to give extra considerations into the limitations and abilities of Azure Function Apps. To me, it's like a puzzle. How can I design a system to best achieve what the company needs done? Do I use Cosmos DB, Storage Tables, SQL? Every step of the cloud infrastructure design is up to me.

The last part of you post is pretty true though, lots of desktop apps now are just web wrappers. Stuff like Discord, Spotify, Etcher to name a few.

As a backend developer- we make everything work. We are the glue behind the scenes.

Everything goes through our code.

We are god.

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.

As a backend developer you're not doing anything with "looks". No interface design, HTML CSS, or anything like that.

The most common backend work involves the following:

• ETL process creation
• proprietary API maintenance
• third-party API integration
• Database data manipulation

I enjoy it. It feels like I'm designing special wires that connect different computers together. It can be repetitive if you're not designing your code to be extendable. If you're writing the ideal code, you're always writing new stuff. If you're just copy-pasting from other examples, that should indicate that there is a general solution that's being ignored.

I’ve been a backend web dev (now full stack) for over 10 years. Many things are rather boring CRUD apps. This is the part I enjoy least, but it can be dealt with rather quickly. The projects I enjoy the most are the ones where the business logic is rather complex, since that is almost always done on the backend. It’s a nice feeling, to build something custom for client that will fit their exact workflow and spit out the numbers or the reports or whatever that they need to make their business work efficiently. Where I work we decided against the cloud and use a docker based architecture on physical servers. There is also quite a bit of server administration / devops involved if your company does not have a specialised person. Many desktop apps have a server component, whether they are web apps or not. In these case there will be a backend component.

It depends on the company for how much any developer role will be responsible for, but a backend developer would typically be responsible for anything that isn't the user interface. I'm unsure how often the web app statement is true, honestly.

As a lead backend developer I'm responsible for the overall scalability of the platform I work on. Scalability ties to performance, throughput, and maintainability. In my specific position, I tend to leave performance of the code to the members of my team who are implementing a feature while I am building designs that focus more on throughput and maintainability.

This obviously requires a knowledge base of the language I'm working in, but also various mechanisms for distributing work across multiple services and locating bottlenecks in a platform to target for improvement.

I currently work in a combination of Python and Rust. My last position was Golang. Cloud infrastructure comes in to play quite often. AWS knowledge will be really useful in this field. Some relationship database knowledge will go a long way. Learning how to properly build and use a cache.

Overall, I would say it's not repetitive in the long term. Early on it might be a lot of hammering out other people's designs but you get a greater degree of flexibility as you progress and learn more.

It depends, and there's a lot of variation obviously, but,

A frontend developer writes the stuff that runs on the client,

A backend developer writes the stuff that runs on the server (it can be repetitive--any programming can be, but it certainly needn't be. It's not always as flashy as frontend but there are still some exciting challenges),

And finally, a full stack developer does whatever the company wants, and damn it, they had better enjoy it too.

You're looking at a description from a pure backend dev?

A pure backend dev will only be a role in big companies and projects that have enough work or scale where such a specificity is possible and worth it.

Most developers may work on backend, but as part of the project, and shift roles according to needs and tasks.

Not to overwhelm you, but I'd definitely also suggest looking into learning SQL and familiarizing yourself with Linux if you haven't already.

Is it rather repetitive, or is there always something new to do?

Really depends on who you're working for / what you're working on. In general, a programming job shouldn't be repetitive; the repetitive parts should be automated (and you should have the autonomy to automate them yourself). If a job is truly repetitive, something is probably wrong.

What does a backend developer do?

Well, that really depends on the architecture of whatever you're working on! I've done some fairly miserable work where the backend was 90% just an interface that the frontend used to access the database, communicate with external APIs, and schedule background jobs. I've worked other places where the bulk (or entirety) of the web app's logic happens in the backend, and the front end is just there to act as an interface to the user, and that's much more enjoyable. But yeah, the bread-and-butter is going to be:

1. Dealing with data storage
2. Dealing with external APIs
3. Creating an API (whether you're doing server-side rendering and not even doing any AJAX on the front end, or if you're creating something meant for third parties to program against, it's still an API)

Then you'll also have challenges that you wouldn't have with non-networked desktop application programming:

1. Performance implications of many concurrent users
2. Diagnosing issues remotely, whether it's your code or something on the OS level of the machines your code is running on
3. Synchronization / coordination, especially once you've started dealing with your performance issues caused by lots of users. Your standard mutex or semaphore won't work across multiple instances of your backend running on different machines, maybe even in different regions.