|
And that of course would never happen on CP?
I had so many solutions deleted, because the questions were all of a sudden gone, I've essentially stopped bothering with answering any questions at all.
OriginalGriff wrote: if you aren't part of the "ruling clique"
Nothing to say, no siree!
OriginalGriff wrote: And sometimes the other answer magically changes to include what you said...strange that
Now that can't happen here, or can it?
 
"I had the right to remain silent, but I didn't have the ability!"
Ron White, Comedian
|
|
|
|
|
|
I looked-up you subject (replace text inside Word's shapes) and found a lot of ideas how to do it (simple Selection do not contain the shapes and not the text inside shapes)...
You should do some Google, or reopen the question to let me (or others) to point you to the right direction...
Skipper: We'll fix it.
Alex: Fix it? How you gonna fix this?
Skipper: Grit, spit and a whole lotta duct tape.
|
|
|
|
|
I already resolved it myself.
If you've never failed... You've never lived...
|
|
|
|
|
Glad to hear that. By the way, don't judge the entire site based on the actions of a few people. Lots of sensible folks here as well 
|
|
|
|
|
Just record a macro doing what you want and you'll see the code you need.
There are only 10 types of people in the world, those who understand binary and those who don't.
|
|
|
|
|
Actually I get it done by considering the content with all the shapes. Check for shapes and fill it with the content.
If you've never failed... You've never lived...
|
|
|
|
|
A bit early, I know, but deal with it. 
That chamber has a small door (5)
Good luck!
You have just been Sharapova'd.
|
|
|
|
|
Very good!
I'll not answer it now - far too early and I want to give the others a chance.
Possibly a little too easy?
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
|
|
|
|
|
OriginalGriff wrote: Possibly a little too easy?
Yes, that's kind of how my clues are. 
You have just been Sharapova'd.
|
|
|
|
|
Maybe - but it's a good one! 
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
|
|
|
|
|
I got an idea what i could be, but well i prefer waiting to see if i was right XD
Rules for the FOSW ![ ^]
if(this.signature != "")
{
MessageBox.Show("This is my signature: " + Environment.NewLine + signature);
}
else
{
MessageBox.Show("404-Signature not found");
}
|
|
|
|
|
Cabin ??
That's what came to my mind when I read the word "chamber"
|
|
|
|
|
Nope, sorry. That's not it.
You have just been Sharapova'd.
|
|
|
|
|
Oh, okay.
Gotta think of something else having a door.
|
|
|
|
|
This one is too easy. I won't tell the answer, so that others can find out.
|
|
|
|
|
Sure. But if no one answers it, I will declare you or OriginalGriff as the winner. 
You have just been Sharapova'd.
|
|
|
|
|
OK...
THAT CHamber has a small door
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
|
|
|
|
|
I just got it that HATCH is the solution... but darn 2 minutes late!
Rules for the FOSW ![ ^]
if(this.signature != "")
{
MessageBox.Show("This is my signature: " + Environment.NewLine + signature);
}
else
{
MessageBox.Show("404-Signature not found");
}
|
|
|
|
|
Yep! Too easy, wasn't it?
You are up tomorrow.
You have just been Sharapova'd.
|
|
|
|
|
The following thing has happened to me twice now. Is this a company anti-pattern?
An experienced developer is recruited to join a startup looking to build out its team. The team has been working for 12-24 months and has begun to ship. But they have worked very quickly. There are many bugs. There is no documentation. Test cases are minimal. Important internal APIs are, um, quirky. The senior staff are also quirky, not having needed to interact with teams much until now.
The performance of recent hires is compared to the productivity of the senior staff. But the senior staff built the existing software from nothing. They have 12-24 months of experience with the quirky APIs. They actually wrote the code, so they know what it does. They never had to learn it from scratch. Not so the recent hires.
The performance of the recent hires never meets management's expectations. The senior staff, after all, built the whole code base in 12-24 months, but the new guys can't figure it out. The new hires get sacked after six months, to be replaced by newer new guys, but the result is always the same.
Managers at startups always emphasize the need to work quickly. Gotta get a product out before funding dries up. Don't refactor. Don't document. Gotta work quickly. But the result in even a short time is code that is difficult to work with and impossible to learn. It's my personal opinion that these companies' management have done wrong by demanding the original developers work quickly. The result is so much technical debt that it is hard to scale up the company's staff. It takes the same number of months to do a job quickly as to do a job deliberately, you just spend the time doing different things. Getting done earlier is better, but this only happens if the company never needs to staff up.
Anyone else recognize this pattern?
|
|
|
|
|
|
Jörgen Andersson wrote: Yes, it even has a name - Brooks Law[^]
Brooks' Law describes the decrease in producitivity in a project as it scales due to communication issues introduced by adding staff. Since poor APIs and missing documentation amount to poor communication, technical debt multiplies the inherent effect of Brooks' Law.
The result then, is that if you want adding staff to shorten the development time, you have to pay attention to communication, and therefore to technical debt. Right?
Thanks for this observation. It makes more sense now.
|
|
|
|
|
|
Great explanation.
And yes, it happens all over the place.
Now I'm going to invoke a word that could start a hailstorm of replies: Scrum.
Honestly, if you read the book, Scrum: getting twice as much done in half the time[^], written by one of the original creator of scrum, you would learn that all of the things you mentioned are the original reason that they created the Scrum methodology.
The heart of scrum solves those issues. But, Scrum (agile) is explained by many people in the wrong way and developers don't want to hear it. And what those people at that company you mentioned are doing may be called Scrum by them -- even though it isn't Scrum.
That's why to understand everything I'm saying you'd have to read the book. But that's far to long.
In Summary
You are right. It's an anti-pattern.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
