This is an ad.
Brown M&Ms, or Why No One Reads the Manual
41–50 of 153 posts
Re: Brown M&Ms, or Why No One Reads the Manual
#42Earlier quoted context omitted.
> after a bit of an ear bashing you actually helped them? Hang up, charge your emergency hour consultant rates, and tell them you're available once they sign the agreement.
I would help. The people who are suffering the most are your former coworkers. Presumably friends. Definitely people you may work with in the future. I'd rather be known as the guy who helps than the guy who is rude about consulting rates.
Asking to be paid for work is not being rude.
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.
Re: Brown M&Ms, or Why No One Reads the Manual
#43Earlier quoted context omitted.
> after a bit of an ear bashing you actually helped them? Hang up, charge your emergency hour consultant rates, and tell them you're available once they sign the agreement.
I would help. The people who are suffering the most are your former coworkers. Presumably friends. Definitely people you may work with in the future. I'd rather be known as the guy who helps than the guy who is rude about consulting rates.
Alternatively: Help your co-workers and friends by normalising getting paid for real work outside of what is contracted.
Re: Brown M&Ms, or Why No One Reads the Manual
#44This is quite strange, having organized a large music festival this kind of document were split among different teams. Meaning that people in charge of the backstage are managing their part (getting food, M&Ms, specific brand of beer, and other non nonsensical request, etc) and the people in charge of the stage and technical stuff are taking care of technical requirements (and aligning them between different bands sh…
If the backstage team didn’t miss the M&M detail, does that give you any information about the overall attention to detail of the promoter?
(If it does, then it seems like the lack of that information is itself information.)
Re: Brown M&Ms, or Why No One Reads the Manual
#45This is quite strange, having organized a large music festival this kind of document were split among different teams. Meaning that people in charge of the backstage are managing their part (getting food, M&Ms, specific brand of beer, and other non nonsensical request, etc) and the people in charge of the stage and technical stuff are taking care of technical requirements (and aligning them between different bands sh…
It can tell you something about hiring practices. The quality of the host of a restaurant probably shouldn't tell you about the staff in the kitchen, but in reality if they made the choice to go cheap in the front the the house they also very likely made the same choice in the back.
Re: Brown M&Ms, or Why No One Reads the Manual
#46Another tip: when writing communication (like email), start with TL;DR. Explain quickly who should read it and why. Start with the important stuff first, follow up with details and less important stuff.
I usually write an email in the order that I am thinking on it. First comes a paragraph or two of the details of the problem, then concluding with a sentence saying what I would like the recipient to do.
Every time, I then go back and move that concluding sentence to the top. That way, the email starts with what I would like to happen, and if the recipient doesn't have any objections, the remainder of the email can be skipped entirely.
Re: Brown M&Ms, or Why No One Reads the Manual
#47Another tip: when writing communication (like email), start with TL;DR. Explain quickly who should read it and why. Start with the important stuff first, follow up with details and less important stuff.
Not just tl;dr but as a pyramid.
In US schoolsg english classes teach writing as an inverted pyramid where you give details (pyramid base) and end with a conclusion (pyramid point). In contrast, technical writing and journalism teach an inverted pyramid where you start with the conclusion (point) and fill out the details (base).
Think of The Atlantic long form articles contrasted with traditional newspaper frontpage stories. The Atlantic is telling a story to build context before getting to what you wait. A newspaper article tells you who was murdered with what and where and then builds up more context.
Re: Brown M&Ms, or Why No One Reads the Manual
#48A few years ago I left the company I was was working for. We had an internal doc wiki that hardly anyone used. I was one of the ones who did and I would document code changes and things like how to setup a dev environment and to list known gotchas. 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…
Wow, that is exactly my Story, up to the jdbc driver!!
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)
Re: Brown M&Ms, or Why No One Reads the Manual
#49A few years ago I left the company I was was working for. We had an internal doc wiki that hardly anyone used. I was one of the ones who did and I would document code changes and things like how to setup a dev environment and to list known gotchas. 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…
First thing you do is email them a contract with a _reasonable_ consultant hourly rate. You literally handed them documentation in advance and they didn't bother to read or test it. Don't feel bad, don't get angry, get paid.
Re: Brown M&Ms, or Why No One Reads the Manual
#50A few years ago I left the company I was was working for. We had an internal doc wiki that hardly anyone used. I was one of the ones who did and I would document code changes and things like how to setup a dev environment and to list known gotchas. 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…
Wow, that is exactly my Story, up to the jdbc driver!! 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…
In this case the server app had multiple DLLs imported from other projects and they had been compiled against a specific version of the Oracle .net driver.
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.