Ahh, when nontechnical people are trying to supervise technical people...
My developers won't give me access to my server
11–15 of 15 posts
Re: My developers won't give me access to my server
#12It's funny, the first thing that came to mind here was "this guy sounds like he's trying to phish his way onto somebody else's VM", but alas, it wasn't that interesting.
I'm rather confused why this is trending as high as it is on hacker news though.
Re: My developers won't give me access to my server
#13Re: My developers won't give me access to my server
#14I worked for a guy who had a habit of refusing to pay people for work they did. All the other developers has logic bombs in the code.
Even though I've worked for some total jerks over the years, I could never be tempted to insert a logic bomb.
I did get blamed for one once after I left a particularly bad gig - they deleted "some old files" - the SVN repo - from an old server and lost anything that wasn't a year-old+ checkout on another developer's machine.
But this was the same shop that disabled SQL Server transaction logs and backups since they ran out of disk on their web server.
Re: My developers won't give me access to my server
#15When I'm working consulting for a non-technical client, I like to formally put together a 'how to fire me' document.
Including things like 'here's how to disable access to github, the server, the database, change ssh keys, here's where the backups are, these are the services you need to change over, this is how you request a final invoice and pay it, here's how you engage another contractor or consultant, here's a rundown of the project to get them up to speed', all of that kind of stuff and more I can't think about at the moment.
I think it's very important to make sure the client knows that they are in charge - and it makes it easier to do things your way, since the client has a very clear picture of what power they have and how it operates. This means they can trust you to do your job well, and actually makes them less prone to interfere just to reassure themselves they can.
These are useful in a non-client environment too - having a run sheet for your job is great for when you're out sick or on vacation. If you can't be sure that your work will be just fine without you, how can you really enjoy a vacation?
I think we spend a lot of time automating our technical tasks, while missing a bunch of easy 'automation' in terms of checklists and documentation. Make it easy for someone to fill your shoes for the day if needed.