When I built my own software for my own use, I tended to try and write it starting from its very foundations; it had to be perfect in terms of code quality. Abstractions, modularity, readability... I would try to write software in a way that maximizes those aspects of my code, even for applications as simple as just reading my laptop's battery levels.
That approach might have some merit, but I'll face it: This wouldn't fly when I have a deadline.
Such is the reason why we even have subjects dedicated to project management, especially when developing applications that are... non-trivial; designed for an actual userbase, i.e. client(s), and does more than just do the most basic of tasks. Not only that, but such pieces of software usually requires a whole team; one person can only do so much. How would that team be managed, then? And how could said team work towards a client's requirements, some of which may be ill-informed, unrealistic, or otherwise contrary to what the team has already finished doing?
Now I have to take project management seriously. Over the years did I hear so much about terms like "DevOps", "Agile Development", "CI/CD", etc. online, and I thought I don't have to learn it until the day comes where I get to the level of actually needing to take it seriously. That came closer than I thought!