Ask HN: How do you deal with operational work as a software engineer?

I see chasing weird bugs as part of development job, not something separate. As long as it has weird bugs, the feature is not really done. As a side note, developers who do "only development" and offload all weird bugs to someone else tend to create less maintainable software overtime - they lack feedback and tend to favor whatever makes them produce new stuff faster over what makes us all avoid those weird bugs.

As for infrastructure and first line support, lobbying management for more people continuously is just about the only long term solution.

The other thing is planning and transparency which helps the above. Keep plan with realistic estimates to show it management each time you talk with them. Do your best work, definitely dont slack etc, but dont skip corners to make something look like done when it is not. Instead, move dates in plan and send it to management again. The point is to convince them that there is really more overall work then possible by one person. (If they get offended over that or treat you badly over that, find a new job.)

If I don't fix bugs and I don't help my customers with setting up servers and the like I don't think I'll get new projects with them. Why would they trust a developer that disappears? It's as simple as that.

Some of those activities are paid, but fixes close to a delivery are not and it's OK. Usually I set up a maintenance contract for quick activities, like small new features or investigating puzzling events (not necessarily bugs.) I have a ticketing system to keep track of those activities. Customers have access to it.

Obviously one has to make clear that maintenance will slow down development.

> As a side note, developers who do "only development" and offload all weird bugs to someone else tend to create less maintainable software overtime

My problem is that I have become that someone else.

Time Management for System Administrators has some ideas I think: http://shop.oreilly.com/product/9780596007836.do

(I haven't read this cover to cover but I has more or less read his and Christina J. Hogans book cover to cover I thing and I've also bought a couple of copies of the above book to share.)

Summary of what I've learned and found useful from those and other resources:

Get someone to step in for you half the time. (If only to fill in a ticket or - in a real emergency: call you.)

Manage expectations. (You don't expect hard interrupts except for emergencies. )

Make support requests asynchronous. (Mail, support tickets - not calls. Even when you (or someone else) are available for real time support, - make chat the preferred option.

You do realize that this is just as vague as the original description?