If you are contracting in a situation like this a reasonable rate could mean $250-$1000 an hour. Really depends on what kind of money your currently make.
A better approach in the case would be to offer to investigate, and provide a flat rate. You can charge $3000 flat fee, and you may solve it in 1.5 hrs.
They accepted :(.
you actually helped them? Hang up, charge your emergency hour consultant rates, and tell them you're available once they sign the agreement.
I'd rather be known as the guy who helps than the guy who is rude about consulting rates.
> after a bit of an ear bashing
If someone from my old employer calls and asks me politely for a bit of help with something I know well, I'd help.
If they call to yell at me about how I left behind a fragile system or how I left them in the lurch by quitting, the correct response is to tell them to get fucked, if they then ask for help after that, the correct response is to tell them to go fuck themselves.
Normalising that kind of abusive behaviour is not going to improve the lives of the co-workers you left behind.
You could warn him in advance about an impending negative issue. You could use lights, fireworks and even shout in his ears, but he would ignore you.
The the issue would occur and cause problems, big problems.
He would then ask "Why didn't you warn me?"
I would pull out my paper trail of emails, meeting notes etc.
To which he would reply "You didn't try hard enough to get my attention."
And that is why you don't put a career salesman in charge of your IT department.
“This is exactly the sort of behavior that made me leave. Do not contact me again. If you need something from me, have Steve call me instead.”
Let the people who actually gave a shit about you be your point of contact, not baby Napoleon.
Then you have angry baby Napoleon directing Steve to communicate with you and nobody wins.
If they call and ask they are in complete, dangerous illegality (I had once an American company czll me about an ex employee and they could not understand that).
Some companies used to ask for references, they were referred to friends and they do not ask anymore (this is a general case).
I had one of those for about a year and leaving after just over a year was a question I got used to answering.
This is a cliche but it can't possibly be true. I mean, it is extremely expensive to file a lawsuit, you probably lose, and nobody will ever hire you again, because it is public record.
The kind of person to lay into you like this is not going to give you a glowing reference whatever you do.
Spending 10 minutes on the phone to answer questions is one thing, as long as they are respectful, but more than that means that they want you to work for them.
Often, if made redundant by a company, you cannot return to work for them (as employee or contractor) for a year, otherwise you have to pay back your redundancy pay.
That leads to a potentially hilarious conversation about rates.
"I'll do it, my rates are 100 per hour plus 10K if you want me to start before June next year"
That being said, the issue with redundancy packages is that taxes are involved and those guys will be inflexible if they find out that your package turns out not to be tax-free after all.
Anything that takes more than an hour should be billed. If the guys at the company are really your friends, they would fight to see you get paid.
I picked up the phone, said my name, and as soon as they dropped that, I said "Oh, he's dead" and hung up. My former boss sent me a text later going "Very mature, but very funny"
Edit: Boss was the only one who had his head on straight
When people treat you that way, you politely say "If you want my help, change your tone."
If they don't, hang up.
That was the first time they called.
I made a perfect confluence-wiki, for every server a page, for every application on that server a sub-page.
The Code-repo-links the config's the howto's everything was in there, the second time about 2 month after i went for the other job, they floded a Oracle-Db, called me and asked really rude what a shit installation i made, so i asked for the server pointed them to the Wiki-site and the first sentence boldly written said: DEV-VM -> DB-scheme-migration (DONT put DATAS IN, 20GB-DISK)
My docs clearly stated that you should not update the driver unless you were willing to rebuild all the other projects as well. I could only deploy one copy of the driver file, so it had to be the version all the different parts of the application were expecting. It was an old app, whoever started development on it didn't know about repositories and DB singletons - there were DB connections all over the place.
The annoying thing is that the .net error message they were getting actually stated what the problem was in fairly clear terms, yet they still called me.
I really enjoyed this read. I think it contains actionable suggestions that I will incorporate into my job. Consultable documentation, all in a single location sounds like an improvement over what I have now.
The focus of my approach has been a bit different so far: since I know that nobody reads the manual, I strive to make the manual short: "Run this one command and it will do everything for you." My thinking is also that it lowers the bar of skill for new hires. There are some unfortunate consequences of this:
1. Maybe we don't want to lower the bar of skill after all (maybe we do - good workers are hard to come by where we are).
2. I am something of a single point of failure. If I go, I'm sure things will still get done, but it won't be done well (very subjective of course).
Anyway, I'm excited to try and improve my processes to make it easier to grow.
This is also why we've never Dockerized. It masks too many issues and no one seems to have a clear understanding of how all the garments are stitched together.
As for containers, I’m not sure I follow. We ended up using vagrant and then test kitchen for our VMs, which really helped with on boarding. The team had too many people who couldn’t be expected to troubleshoot much of the backend anyways. We had stayed away from containerization because it added complexity without any clear benefits for our use cases. But test kitchen definitely papered over the need to get a local environment running with all the dependencies, which might change with different services, and that seemed like a good thing.
1. Nobody has to install dependencies. Docker is the only dependency (with compose).
2. Everybody has the same configuration.
3. Software versions are (mostly) tightly controlled. This requires whoever sets up the dev environment to make sure they use specific versions, and not :latest.
4. Devs don't need to spend time worrying about how the dev environment works, just the code.
This means that my README for a project usually has a section describing setup that just says:
1. run `dev/install` (any libraries from eg. NPM, go modules, etc.)
2. run `docker-compose up`
3. Check that the application is running on port XX.
This actually works great, and it does allow new devs to get to work quickly, and it does allow us to use devs that know very little about the underlying software that we're using, unless something doesn't work correctly. And that does happen, much more often than I would like. Then it takes my time and theirs to get up and running, and that was definitely not the goal.
That way the wiki stays up to date. Most corporate documents/wikis are worthless after a few years because things change but the wiki didn't. You need to constantly update it.
Few people took any notice of it.
That nonsense would last exactly as much time as it took me to recognize the words and to hit "end call". The phone is for my convenience, not theirs.
Minor tangent, but that got me to wonder: would that be legal under the GDPR, which only allows you to use data for the (legitimate) purpose it was collected for?
In this case, they gathered next-of-kin info for (I assume) disbursal of benefits when the employee is dead or incapacitated. “To find the employee after he quits” would be out of that scope, then, right?
In Ireland next of kin is purely for cases where the person has been incapacitated/hurt and someone needs to be told. Nothing to do with dispersal of benefits etc. There's a separate process for all that.
I blame the manager who came from a sales background. His response to every problem was to "call someone", rather than have the team work out what was wrong.
Not actually getting paid/having an employer there can be quite liberating...
Since nobody who ever writes me is a customer, and I am not getting paid anyway, I am more or less free in what level of politeness I apply. I usually try to model my response after the initial requests I receive - taking into account other factors like people who might be genuinely upset; or confuse me with the person who actually uploaded a piece of content.
We have users from all over the world, and it's rather interesting to see particular patterns/attitudes with certain types of locales.
For example, Americans - by and large - are too lazy to read the few lines of text on our contact page detailing what information we need to address what kind of problem, and often are rather rude from the get-go, and really like to threaten with their lawyers (plural!) in the initial email when it comes to copyright or related issues. This then leads to me asking for the missing details, followed by a lot of them demanding to talk to my supervisor, to which I then point out that they are not our customers and that being rude or even outright insulting the only person who could potentially help them (for free) isn't maybe the best idea they ever had... And if the supervisor demand came up, I point out that I do not have a supervisor, I demand to talk to their supervisor instead.
It would be unfair to only unload on Americans, tho. We got a lot of Portuguese users, and tickets from the Portuguese are even more rude on average and of course nobody bothers to read the instructions, tho nobody ever demands to talk to my supervisor. The French are polite but like to make outrageous demands, but seem to read the instructions. Germans are "professional"-polite but tend to write LOOONG emails, and when it comes to copyrights usually cite a lot of completely unrelated laws, but again read the instructions. Middle/South Americans are usually polite but constantly think the Subject line is where all their text is supposed to go, and do not read the instructions. I'd say the most pleasant people are the East European (mostly Polish and Russian) people who write me... I don't remember anybody outright rude from East Europe ever, tho the language barrier - our website is English only incl the instructions - is often rather obvious (but I will not fault anybody for that, of course).
Point being: the level of RTFM in my limited experience differs quite a bit depending on locale.
During my final week when I was doing code handover I sent an email around the company pointing out that the wiki would answer most of the questions they might have about the apps I worked on.
Three months later my phone starts ringing. I was in a new job so I didn't answer, but they kept ringing. Then they started calling my wife as she was listed as my next of kin. My wife also didn't answer as she was with a client. After a few hours, my wife picks up the call and texts me that my previous employer was desperate to speak to me. So I called them during break and after a bit of an ear bashing I was informed their whole warehouse system was down and all business had stopped.
After a bit of diagnosis I realised that they had fallen for the first gotcha I listed in my docs, they deployed the wrong DB driver. I asked why they didn't read the docs. They responded "what docs?". I explained that I sent an email round before I left with guidance on the app. Rather than apologise they berated me for not doing more to alert people to the existence of the information. It was that attitude that contributed to me wanting to leave the company in the first place.
I think the moral is that no matter how good your docs, some people will always ignore them even when the world is collapsing around them.