One thing to add to the points about documentation: if you as a developer either don't write it or do a half-assed job of it, then you won't be able to just hand it off to the systems guy - you're going to end up doing 2nd/3rd/whatever line support for it because the documentation is YOU. And that, of course, will mean less time for coding.
In my limited experience, you can never make the system guys love you, nobody can.<p>Simply put, system guys have a lot of downtime, where they do stuff that they enjoy, rather than work. So anytime anyone interrupts them from this, they are going to be annoyed, it is only natural. You are taking them away from fun, to something boring, and annoying to fix.<p>Regarding the article, I am not sure why hosting considerations aren't talked about at the beginning of the project. Even working with non-technical people, this has always been one of the first issues. Are we going to host it here, are you going to host it, can it use a shared platform, does it need a database. This is all thought about at the start of the project, and if need be a systems guy is bought in.
One missing item is instrumentation and metrics. Understanding and debugging a complex application is made much easier by having an abundance of easily collectable metrics that describe the running or cumulative state of the system.
Another one: usually one of the first places a sysadmin is going to look when there is a problem is the log file. A good sysadmin will be able to read compiler-generated errors but still may not be able to do anything if the messages reference cryptic variable names and methods from code they've never seen. Spend a little time thinking about how an end-user, rather than a developer, would read the log file.<p>Obviously don't short-change yourself if you're the one who will be writing bug fixes and need detail, but a little can go a long way here, especially for problems a sysadmin may be able to diagnose and fix (connection issues, resources issues, etc.)
Great read, but I was hoping for some secret advice on how to be loved by sys guys/gals that can't be known to us programmers unless somebody tells us :)
This is one of the reasons for programmers making startups to use "platforms as a service" like Google App Engine, Heroku, Rackspace Cloud et al. They really do simplify deployment and managing systems, and let you focus on code, particularly for platforms that traditionally are hard to scale without a lot of knowledge and work.
Can I just indulge in a bit of patriotism here? A few paragraphs in, I knew I was reading a British dude, and was confirmed right by the URL. Sure, no doubt there are many shibboleths to tell, but the main clue was the joy and easy humour of the writing. Just an incredibly British style, an utter lack of fear in mingling jokes and serious points.<p>The biggest thing the author won't dare admit - that he's a nice guy. That he cares about making it easier for others. I guess it's self-effacing, and I can see how others may prefer actual open honesty, but this is the way I work, and as such, this prose is like a warm bath to me.<p>"What are the five things most likely to break it? If somebody is trying to fix a problem and you left them a solution on page 5 of the manual they’re going to be really, really grateful. Once it’s working again they’ll buy you a beer to say thanks for all the trouble you saved them. Seriously, they will."
Most of those excuses mentioned really come down to one of two things: arrogance (I know best so you don't need to know) or laziness (why bother because see former), both of which are hardly unique to programmers.
It's much simpler than this. Buy him/her a case of beer. That's all you have to do. Works wonders. People bend over backwards for you after you buy them a case of beer. It doesn't even have to be good beer; you could get some shitty $40/case beer and they will love you. Soma.