5 ms·
This is for contract work, which I exclusively do, so may not apply to employment. I've never done employment. Seems like a bad deal to me. Anyway, cliffnotes o
by wayn3 10y ago
This is for contract work, which I exclusively do, so may not apply to employment. I've never done employment. Seems like a bad deal to me. Anyway, cliffnotes of my standard contract:
- I work remotely. Under no circumstances will I ever show up in person at your office or any other location that requires me to spend time away from places I want to be.
- I bill 2 weeks in advance. You chose to buy hours of my time and my compensation is tied to those hours. My compensation is not tied to any kind of result. If you are unhappy with the result, there is no way for you to sue me. If you decide to hire me and then waste my time with meetings and your IT department not being able to procure a simple ssh key, that is your problem, not mine.
- I understand that you have deadlines, but so do I. I need to be places and under no circumstances will I ever work more than 40 hours in a week as part of this contract. If you need more resources, we will have to talk about a separate contract.
- I do not care for your employees. You are hiring me because you need me to fix their mistakes, do not expect them to be happy about that. If you want to make it my job to be their nanny, I'm cool with that, but don't expect them to suddenly drop the wilful incompetence.
- You get a weekly e-mail update which should suffice as far as communication is concerned. Anything beyond that has to be initiated by you and will consume time that I could spend working productively.
- I work with Python, exclusively (and some fun low level languages but nobody works with those anyway). I understand that back in 2013 someone decided that node.js was a great idea and now they left because it wasn't all that great, but that's not my problem. If you want it fixed, we can rebuild it in python. It will work phenomenally.
- I do absolutely not do any kind of User Interface work. I know people who do and can manage them for you. But I will not ever touch anything like that personally. Watching paint dry is at least an order of magnitude more entertaining.
- This is a contract negotiation, not a job interview. You can ask me technical questions if it makes you feel better about yourself, but time spent on such nonsense will be considered billable hours.
Those are the things that matter to me. Other things do not. I charge extra for boring work, like "restFUL API". No its not difficult to instantiate a framework to write some endpoints.
Its perhaps not surprising that my list of priorities doesn't touch on usual employment stuff. Its not employment, after all.
- Flammy 10y agoI'm curious what type and size of companies and industries you primarily work with?
- wayn3 10y agoThe average customer is a manager of a small team between 6 and 15 people inside a company of 150-300. For some reason, there are a lot of managers who have budget but are denied headcount by HR, which forces them to work with contractors. Don't ask me why that is. A lot of processes in old corporations make very little sense in the way you would expect common sense to play out.
- nameless912 10y agoThis policy makes sense in the context of veteran employees: if a department is given a block allocation of funds instead of a headcount, it becomes much more lucrative to get rid of a senior employee and hire two individually somewhat less efficient, but together more productive, new guys than to keep the one experienced guy on. Headcounts protect the old guard and allow managers to say "I will keep x people on my software team" rather than "I will spend x dollars, so you're all getting a pay cut/fired".
- wayn3 10y agoDo people still actually believe that two warm bodies outperform one senior engineer who has worked on this particular software for years and therefore knows his way around it?
- PeterisP 10y agoIt depends on the situation. There are cases where a senior engineer outperforms three or more warm bodies and cases where two warm bodies would be much more preferable, it depends on the content of that job. And I have witnessed a case where simply removing "one senior engineer who has worked on this particular software for years and therefore knows his way around it" was a key part of finally getting that software on track, as he was providing literally negative value. Also, relying on particular single people who "know their way around" some code is an organizational smell - if you have such a dependency then that's a management problem/business risk that needs to be fixed. You do need shared ownership and people who can replace each other, and (except for the very short term) a better engineer will be more productive than a worse engineer who has been stuck on maintaining that code for years.