switch to room list switch to menu My folders
Go to page: First ... 51 52 53 54 [55]
[#] Sat Jan 12 2019 18:27:56 EST from wizard of aahz @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

Just means you get more frequent flyer miles.

[#] Fri Jan 25 2019 18:10:15 EST from LoanShark @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

+1; creative use of the word "fook".

Vaguely similar stuff going on at the job I left last year. People complaining publicly about how the company is "going through the pain of growth" and there's a lot of "undocumented legacy."

That's your fault, guys. Should have better treated the folks who knew that legacy

[#] Sat Jan 26 2019 22:13:57 EST from wizard of aahz @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

If people were to document things then it would be too easy to get rid of them.

My recent trick for people who want me to train replacements or just make millions of changes to already existing processes is to request a copy of their policies and procedures so I can make certain that the software is compliant and in synch with their approved processes. It's amazing how quickly things are no longer an immediate emergency.

[#] Mon Jan 28 2019 09:55:48 EST from IGnatius T Foobar @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

+1; creative use of the word "fook".

Ah yes, I see you've met the training twins, Fook Mi and Fook Yu. They charge a premium to both show up at your site at the same time.

I suppose no one really wants to document themselves out of a job. Or automate themselves out of a job. But if you *do* a good enough job, you get to be recognized as the SME (Subject Matter Expert) and you become reasonably secure.

[#] Wed Jan 30 2019 12:32:33 EST from fleeb @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

Sometimes, the documentation itself involves so much effort to wade through, you're better off with the human beings.

[#] Wed Jan 30 2019 12:37:12 EST from wizard of aahz @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

Sometimes, the documentation itself involves so much effort to wade

through, you're better off with the human beings.

Well fleeb.. There's a discussion in there. For years I've been pushing clients to make certain that they have documentation and human backup. I'd say "What happens if fleeb gets hit by a truck? Then where are you?"

About a year ago, my business partner gave me grief for that line. Told me to stop being so negative. So now it's more like...

"What happens if fleeb wins the lottery? Then where are you?"

See. I made it better. Well sorta. But the problem still remains. If you rely on a single person you have a nasty single point of failure. People and documentation backup both are needed.


[#] Mon Feb 18 2019 10:55:10 EST from fleeb @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

It's an issue of degree, though.

Firstly, the code itself should be easy to understand for someone wading into it. If not, it's already a disservice.

Secondly, if the company doesn't maintain redundancy in human resources, they don't really care about the product. That is, everyone on the team ought to have someone else within the team that can back them. Othewise, it's just shitty management.

That shifts your question from "if fleeb [dies/wins the lottery] what do you do?" to "if the entire team [dies/wins the lottery]", which changes things.

For a product as complex as the one I currently work on, even if I wrote pristine documentation for absolutely every minute detail of the thing, my suddent departure would destroy this product for lack of a backup. It would take someone a long time to come up to speed, regardless of documentation.

At the end of the day, it's a balancing act. I can spend all my time writing documentation that makes it crystal clear how the product works, without writing any code to make it work, or I can do nothing but write code without any documentation at all and leave it to everyone to figure everything out after the fact. Or, I can do something in between.

I'm doing something in between. I'm writing just enough documentation to convey where I'm trying to go with the overall design, but not so much as to delay development. If I can get another developer to understand where we're going with whatever I've written (and if I can get my manager to grasp it, and if he can get the marketing folks to grasp it), it has done its job.
The rest comes down to writing clean code that documents itself as well as it can.

[#] Mon Feb 18 2019 11:11:25 EST from wizard of aahz @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

That is useful if it's code.. But when it's your business processes? THen it gets scary

Go to page: First ... 51 52 53 54 [55]