Why do developers spend so much time fixing infrastructure instead of coding?

> I used to think programming was mostly writing code, but now it feels like understanding infrastructure and deployment is becoming just as important. You don't code in a vacuum. > Is this normal in real-world development? Yes. You cannot describe an organism without also describing its environment. The stripes on a zebra make no sense with the context of the savanna, the lions, and the herd. Likewise, you cannot write code without also being cognizant of the environment it is expected to run in terms of. You can't abstract away the world. But what you can do is hire an Operations team to handle some of this bullshit for you. > How long did it take you to get comfortable with deployment/cloud/infrastructure stuff? I still stumble over it every day. If I wanted to admin and deploy I'd have gone into IT more specifically. > Any advice or resources for beginners to learn these skills properly? 1) RTFM 2) Write standards compliant code. The OS isn't just a mouse cursor, windows, and the user experience, it's a tech stack FOR YOU, the engineer. I look at my Debian environment and I think to myself how I might utilize `systemd` to manage my services and UI, how I might use `D-Bus` to discover and communicate between processes, how I can use `rsyslog` to tag, stamp, persist, quota, and propagate my logs, how I can use `apt list --installed | grep lib` to see what sorts of functionality I already have available to me, standard build tools to configure, build, and package the project for CI/CD... 3) Make smaller independent units of software. Everyone starts with a monolith. I dunno, it just happens that way. But eventually you start to see where the monolith has creases you can use to split off independent units. Now things can crash and restart without taking down the whole. You can do things like guaranteed delivery to make sure nothing is lost but effort. The system becomes the monolith, though even that doesn't have to stay that way. It ultimately means when something breaks, the problem is inherently smaller and more constrained, though the consequence can still be bad, as usually systems are rather fault intolerant, so one domino still takes down the whole. 4) Document your shit. You want to know what you have, where it is, how to access it, and who is responsible. And when you start using the system resources and standards available to you, your task of administrating and debugging all this becomes a lot easier, because standard tools and processes are more likely to "Just Work(tm)".