My general advice is to focus on quality when starting. Code is generally used longer than expected. Bug fixing can be more costly in time and resources than writing the original code, particularly if done by someone different to the author. As you write better quality code, your speed will improve.
A quality focus forces you to think critically about your code. If you are open to improvement, your code quality will improve and this could include ways of doing it better and faster. Trying to get code written as fast as possible may have the opposite effect.
That said, I would time box tasks. For example, give yourself a day for small a task and go with whatever you have at the end of the day. People will accept a beginner or junior developer taking a bit longer but they will not accept you taking a week. Talk to other developers, particularly your peers and team mates, to work out how long is acceptable for each task.
The quality versus speed focus may shift from task to task. For example, prototypes will generally be "build it as fast as you can" compared to long lived production code, which will generally by "build as good quality as you can". You may be given a simple but critical bug that needs to be fixed ASAP. Be aware of the requirements and context. If you find that difficult now, do not worry. It will come over time.
As for your boss expecting code to be produced quickly, of course your boss is going to want code written faster - time is money with software development. However, it ultimately costs more to write lots of poor quality code that contains bugs, is slow or hard to maintain. Non-technical managers may have difficulty explaining that.
Also remember that software development is a team exercise, not an individual one like you had in academia. Have a go yourself but discuss your solution with other developers. Read other developer's code to and understand why they made the decisions they did. You will produce better quality code and produce it faster this way.