I get äöøåøæðüÐ, etc using caps lock as an extra modifier key. Consult the nearest xmodmap-file near to you..

Caffeine promotes anxiety. When getting stressed out, it's best to avoid caffeine altogether.

Good advice, but hard to follow after you've been laid off a couple of times even if you're very, very good.

The problem for me is that when I'm stressed out I can't make myself meditate. I just completely don't feel like it. However, I micro-sleep, instead. And it start very quickly when something stops me, like a meeting.

You can't do a proper job in all companies regardless of how good you are.

The manager can delegate the blame and the engineer gets fired.

I took a C-programming job after a decade of C++ and I've been wondering whether I'm employable in the long run. Especially so, because I'm not doing low-level stuff. I think that were I do embedded, I'd be just fine.

It certainly helps that you're motivated and I don't know for how long you can keep that up. I know that most people would at least risk burning out w/that rate. In addition, working that much makes it less efficient. You don't get as much done in an hour, when you do so many of them. This is especially true in the long run and you might not even notice.

Having said that all, YMMV. My both parents work like 60 hours or more a week and they have been doing it for decades. But they haven't been programming. If you can really effectively write programs at that rate, I'd say that is rare, unless you are writing something that's quite routine. As said a lot of times, it really depends on the task complexity.

BTW: Your body probably won't like you working that much, either. Especially in the long run. But we are individuals and it might be that you're a bit different. However, I doubt that to some extent. Are you really being effective??

Yes, fooling themselves and their customers as we speak. It's been done in our field for at least 50 years. Certainly for longer in other engineering fields. I sometimes run out of hope w/this ever being fixed. I have no idea what most managers are taught at school regarding this, but I do know that it's not working in practice. And luckily, so do some of them. Unfortunately only some.

Well, as the matter of fact, one of these people is a compiler specialist and the other one is the most senior technical person in his company. We all agree from personal experience that not doing more than that amount of work works the best in practice. We've been in this field 10-15 years, each.

I have personal experience that working about 30 hours a week works well. I am energetic, my thinking flows well and I get lots of stuff done. I have also worked myself to the ground by attempting to do more. That doesn't work and my experience has been mirrored by other experienced people who have tried.

If you still believe in measuring in this field, you have a long way to go. There's no good measure of amount X of work done in time Y, because it cannot really be compared w/other work unless you're doing basically the same exact thing twice. And we mostly don't.

The bottom line is that there's things we can't really measure effectively. I know that this drives the managers mad. However, I can only tell them what works and what doesn't. What does is that you remove all the obstacles from doing only the real work and minimize task switching. Then let the people do that for 30 effective hours a week. That how I'd basically run a software company. Of course there's more to it, but that's out of the scope of this discussion.

Above all, however, do not take my word for this. Go and find out yourself. Trial and error, adapt and improve.

Oh sure, I was very productive, as well! :-)

It depends a lot on what you're working at. Sometimes it takes me a week to write those ten lines. It really depends on the context. It's rather different if you're adding buttons to a GUI or if you're optimizing a communications module.

We once had a bug that took several months to fix and there were three people working on it. Eventually we created a partial solutions, because no better could be done w/o replacing the hardware. It just wasn't doable.

I have to admit, though, that I was quite junior at the time and wouldn't waste more than a week or two on such a problem these days. We spent lots of time trying to solve something that wasn't solvable.

No ownership, no buy-in. That's more or less the way it is. A very good point, indeed.

I've done that as well. I know two other senior programmers (who are very good) also working only 30 hours a week. What I've learned from this is that you shouldn't even try to work more than that. If you really have to stay at work more than this, it's best just to spend the time talking to people.

I guess part of the problem is that many managers haven't been doing serious programming in their career. They just don't get it, because their work is so vastly different. I also think that most managers are afraid of losing control if they let people do "whatever they want" even if it is what works best for all parties.

Some of them learn. Many don't. Many are new and haven't even had the chance to learn how it really goes. Sometimes it helps when they see that it works the way you say it does, sometimes that's not as important as seat time.

See, when a project is getting late the managers need to make sure it looks like they're doing whatever they can to catch up. This means people have to put in the extra hours even if it just makes the project even more late. So we're not really operating in a rational environment. That's one reason why rational arguments might not work.

I once worked from home for two weeks. It took me about 7 hours to get about 4 hours of actual programming done.

I also learned that it's way more fun to be in the office w/other people than working like this for more than a few days at a time.