I am probably the wrong person to answer this question though. I am not a firm believer in structured work hours unless there is an absolute customer requirement. I have hours in the day where I am more productive and hours where I am completely unproductive. I have learned to manage that to maximize my productivity. However, during those "down" hours some may view it as not being productive, but what they don't know is that I have been up since 4am and probably got more done by 7am than they will all day. I view it as if the job gets done properly and on time it doesn't matter how it gets done.
So if you want breaks, you just have to take them. If you want to work 6 hours instead of 8,10,12, (or take part of your day to continue your education), you're going to have to "just do it". But no, I wouldn't expect anyone who is responsible for your output to give you 'permission' to work fewer hours, or work less intensely. They will always ask for more, and you've just got to learn how to push back.
In other words: You've got to learn how to be just as strong as an advocate for your own well-being as they are for the company's. Once you learn these skills, it's quite possible to have a good work/life balance, and to make time for the things you find important.
If you don't know what's expected of you, that's something you could discuss with your manager.
If you're doing what is expected of you (and being nice to colleagues etc.) or, ideally, exceeding those expectations, then you will probably enjoy your job more, and feel less pressure to conform to specific work hours.
Of course, different companies and teams/managers have different cultures. Also, in some countries you're expected to stay later than your manager. She, in turn, is expected to stay later than her manager.
Call me crazy but I believe that it is possible to build a company where people can do amazing things without being forced to work extra hours. It's definitely on my to do list with my startup.
Part of doing the job as a programmer is research and design. You don't just sit down all day and write code, you have to write documentation, you have to do research to find ways around bugs, you have to design the UI and data structures.
For example I would write Pseudo code on paper to work out design flaws before I entered it into the computer. I would write Flow Charts and other things. I even developed my own method of developing data structures and database tables on paper as well.
When I got stuck I'd research things in a book, or I'd search for the answer on the Internet. Companies paid for a MSDN subscription and have to make it pay off by searching the knowledge base esp when dealing with API calls that change with each service pack. In using Visual BASIC 6.0 sometimes I'd have to ask a developer at Microsoft via MSDN when I found a bug in Windows or Visual BASIC itself that killed my project and find a way around it. Crystal Reports we used and talking to Seagate Software at the time was the only way to fix CR issues. We had an issue where if the user wasn't an Admin on a Windows PC it would show duplicate rows, and Seagate got a service pack out to fix that issue.
Everything I did on the Internet, on the phone, or reading books was job related and going towards solving problems and using resources. But my managers didn't always see that as work because they wanted me to solve the problems by myself, which would have taken a lot longer and impossible without a service pack to fix bugs.
I never read a book, used the Internet, or made phone calls for personal things, they were all work related.
Yet a service pack is like the size of a CD-ROM and takes five hours to download, so they noticed I was using 5 hours of Internet when that happened. (This was in the late 1990s when the Corporate Internet was slow).
Other programmers who didn't do the same things I did to solve problems, could not solve them and the projects got reassigned to me to fix them, because I was able to fix problems.
No matter how good you are, you will get stuck on some problem and need someone else's help to solve it. If it is a bug in the language or OS, you'll need a service pack or a way to get around it.
You managers might not always understand that you need to seek help by reading a book, looking in a knowdlgebase, or talking to a developer on the phone to solve things.
Your programs work on the old OS with the old service pack, but as soon as new ones come out they break compatibility and trying to figure out what changed without contacting the company that made the updates is really really hard to do.
