Welcome to the IT industry. It can be a hard place. But trust me, you can learn how to make the best out of it.
Working at my first job as a software developer and it seems every task comes with a deadline of this Friday. Mostly applying patch works or undoing previous features. I do have the technical skills, it is not like I cannot do it, but the pressure makes me feel overwhelmed.
Working on hard deadlines is common in software development. People are waiting for us to finish things. When we are late, then we cause problems all the way downstream to the end-users. Which is why we are expected to stick to schedules.
However, the only people who can realistically estimate how long we will actually need to finish something are we. Managers are really just guessing, especially when they don't have a developer background themselves. Which is why it is important to push back when we get unrealistic deadlines. When you don't believe that it will be possible to complete a task in the time the project managers decided it should take, tell them as early as possible, so they revise their schedule.
In particular, I have this tendency to take my own time on things, think it through wide and deep, understand it upwards from the lowest abstraction level visible to me and then do it.
The problem is, developer hours are expensive. Too expensive to spend them on understanding every single detail. Yes, in a perfect world, we would have a wide and deep understanding of the problem domain, so we can provide the absolutely perfect solution. But the perfect is the enemy of the good. It's far more important to find a good enough solution on time than a perfect solution which comes too late.
Further, it seems a lot of the job has reduced to meetings, zoom calls,
It's a common misconception that software developer is a job where you just sit in a dark office hacking code all day. It's actually a very communicative job. I like to compare our role to translators between humans and computers. The humans tell us what they want the computers to do, and we tell the computers. And when the humans don't understand why the computers do what they are doing, they ask us to translate for them. That means we need to spend just as much time talking to humans as we spend talking to computers (by programming).
However, sometimes there is a tendency of some people to overdo it with the communication aspect when it comes to scheduling meetings. Some managerial types like to err on the side of inviting rather too many than too few people. So you might sometimes find yourself in a meeting where you wonder what you are supposed to do there. When you feel that you get invited to meetings which are not a useful use of your time, feel free to push back and tell them. Remind them that developer hours are expensive, and the time you spend in their meeting is actually more expensive than just the meeting itself, because you also lose time for getting mentally back to what you were doing before.
But one positive thing about working from home during the pandemic is that when you are stuck in a meeting where you don't belong but can not get out of, is that nobody will notice when you actually work on something useful in another window.
chasing people (members of other teams, or my own) for the necessary information,
This usually gets better with time. You will figure out how to get which information quickly or know enough about what's going on so that you have the information yourself.
going through stacks of old emails to figure out who said what,
Try to improve your system for organizing information. Everyone has their own system for this. Some have elaborate filing schemes in their email clients. Some people use applications like One Note. Me? I just have a text file on my desktop where I write down notes about everything I am working on right now. You need to figure out a system which works for you.
preparing necessary justifications of why I did X the Y way etc.
Documentation is important. It might seem like annoying bureaucracy now, but in a couple years when someone need to figure out why someone did something the way they did it, then good documentation can be a real life-safer. Still, excessive documentation can cause more trouble than it's worth. And when quantity is valued higher than quality and you end up with a lot of documentation which isn't actually useful, then it can actually become harmful.
So when it comes to documentation, try to work smarter, not harder. Spend time on the documentation of what's actually relevant and only do the most necessary part of those things which are not. When you established a bit more clout in your organization, you might also try to actively influence the documentation habits in your organization by suggesting changes to your guidelines. Try to convince people to abandon unnecessary documentation and better organize documentation which is important.
However, recognizing which is which is also something that requires some experience. So that's something you might want to get involved in later.
It seems I am not really learning anything for sometime just by fixing endless bugs and applying patches.
I feel you. Everyone wants to develop new software. But supporting old software is also an important part of our work, even though it is a lot less fun. But don't think that you can't learn from it. By fixing buggy software with awful spaghetti code architecture, you can learn a lot from other peoples mistakes. You will see a lot of ways how not to do things and what kinds of problems they will cause later. This can really help you to create less buggy and more maintainable software later when people trust you to develop some software of your own.