Feel free to tell about what your day looks like. I’m exploring different positions so it’d be very valuable to me. I’ve already done a few courses in C# and Python, they seem to be quite common. My goal here is to get to know this role better, for now I have limited information about it. Is it rather repetitive, or is there always something new to do? What part of it do you enjoy the most and the least? Is it true that many desktop apps are really webapps?

  •  goatsgomoo   ( @goatsgomoo@beehaw.org ) English
    4•1 year ago

    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.