Also, in all but a few exceptional cases I would prefer a good programmer who gets along with others over a superhuman coder with poor people skills. The first one will function in a team, coach others to make them better coders as well, and won't be shy to propose better ways of working, tools, processes, etc. The second one will probably end up pissing everybody off.
It's your job as a manager to help those with poor people skills get along with the others. To manage the disparate skills of your team.
Seriously, what do you think you were there for, to get estimates? Something that can be replaced entirely by a tracking too?
What happened to Blackberry that caused them to go from technology pioneer and market leader to being so clueless and completely blind to the market that it took them literally years to realize that the world had left them behind?
The market changed from a B2B market to a B2C market. Blackberry was very good at marketing to businesses, but had no idea how to market to consumers.
When the iPhone came out, Blackberry sales initially increased, but eventually even business people favored the consumer devices.
Estimation is such a crucial skill, too. If you can't do it, you can't make good design decisions. Imagine this scenario:
You are adding a feature to your project. Should you:
A) Spend time integrating a library into your project
B) Spend time writing the code to do that feature.
If you don't know how long B will take, you can't possibly make the right decision. Estimation is just one part of the skill involved here, in addition you'll need to know how the library will affect the long-term stability of your project, how likely it is to be supported in the future, how you'll be able to handle if it is no longer supported in the future, etc.
Any time you are putting an estimate on the table without sensible requirements behind it, you are gambling.
Then get the sensible requirements. Work with the customer to figure out what they want and need (and maybe also what they think they want).
That is part of being professional.
Usually this is because you've already estimated it to the best of your ability but the powers above aren't happy with the uncertainty, where they harass you into giving a magic number or narrow little gap or to talk down your estimate until it's the number they're happy with.
If someone makes an estimate for you, or forces you to make a lower estimate, then you have no obligation to meet that estimate.
Be professional, and hit your estimates, but learn to let people know that things take time. These are soft skills.
Agile Manifesto - February 11-13, 2001 Extreme Programming Explained - published October 1999
That's good enough to say "it came first":)
As long as you understand, I'm not going to argue about the definition of "first."
And yes, I learned this tip about estimation from agile:
When you make an estimate, afterwards check to see how accurate the estimate was, and use it to improve the next time.
Using this method, over time I've gotten fairly good at not missing estimates. The only times I miss are when there are a lot of unknowns (and even then, I can usually give a reasonable outer-bound).
That seems like an obvious tip, but it's amazing how many people don't use it.
And looking back, I messed up on some in that list, too.........make_unique(new...) should be unique_ptr(new...) and I don't think there's an "alloc," I was thinking alloca(), but that allocates on the stack not on the heap!
A method's accuracy is less important than the persuasiveness of its arguments about why it was inaccurate.
In other words, "how can I take this failed estimate and blame it on someone else?" lol
In that case, your company has serious problems, of which estimates are the smallest.
Robert Martin recently wrote a book called Clean Coders which discusses exactly how to deal with that problem.
Essentially, he says if you want people to treat you like a professional, then you need to act like a professional. I highly recommend that book, it's good.
Refusing to do estimates is not acting like a professional.
One of the major complaints about estimates is that it "takes too long." Seriously, if estimations take any appreciable amount of time, you're doing them wrong.(unless you need to estimate some massive project, in which case you understand why estimates are needed).
If you want to remove the "time sucks," get off slashdot, get off twitter. When I turn off the internet while working on difficult code, I literally get twice as much done. I've measured this several times (and you can tell from this comment how much I will get done today).
Slashdot Mirror
Also, in all but a few exceptional cases I would prefer a good programmer who gets along with others over a superhuman coder with poor people skills. The first one will function in a team, coach others to make them better coders as well, and won't be shy to propose better ways of working, tools, processes, etc. The second one will probably end up pissing everybody off.
It's your job as a manager to help those with poor people skills get along with the others. To manage the disparate skills of your team.
Seriously, what do you think you were there for, to get estimates? Something that can be replaced entirely by a tracking too?
I have no problem when people insult Republicans.
I start to roll my eyes when those same people are 'fans' of Democrats.
Picture terrain like this. The hedges make it hard to travel through, and give cover to defending machine gunners.
"Only buckets of money from taxpayers and customers can lead to new reactor construction. The Clean Power Plan contains no such buckets."
This quote from later in the the article is priceless (and a little horrifying):
“Nuclear power requires obedience. Demand what you really need. Just look at Donald Trump. What can possibly go wrong?”
Not sure what to think of it.
Blackberry makes some stylish hardware, so it could be a good move.
Move into a new market, while not leaving your old market.
What happened to Blackberry that caused them to go from technology pioneer and market leader to being so clueless and completely blind to the market that it took them literally years to realize that the world had left them behind?
The market changed from a B2B market to a B2C market. Blackberry was very good at marketing to businesses, but had no idea how to market to consumers.
When the iPhone came out, Blackberry sales initially increased, but eventually even business people favored the consumer devices.
lol it's inference, but maybe interference is a better name for it lol
So now are we going to see a trade war, where each side tries to make the other side look worse?
Trade wars generally don't end well.
the audit trail *will* eventually lead one of two places -- the actual person who wrote the "benchmark mode" code and checked it in,
That should be easy, right? CVS annotate (or whatever they are using) should bring it up. Are they not using some kind of source control?
Yeah, auto is what you use when it's really tough to figure out what kind of declaration should actually be used. Kind of like C# 'var'
If 'new' is now deprecated, and using a factory smart-pointer function is the recommended way, the it's fair to list it.
That's a nice comment.
Estimation is such a crucial skill, too. If you can't do it, you can't make good design decisions. Imagine this scenario:
You are adding a feature to your project. Should you:
A) Spend time integrating a library into your project
B) Spend time writing the code to do that feature.
If you don't know how long B will take, you can't possibly make the right decision. Estimation is just one part of the skill involved here, in addition you'll need to know how the library will affect the long-term stability of your project, how likely it is to be supported in the future, how you'll be able to handle if it is no longer supported in the future, etc.
I've wondered about the C2 website......did the ideas get developed there, or Was it a place people merely recorded after the ideas were developed?
If someone makes an estimate for you, or forces you to make a lower estimate, then you have no obligation to meet that estimate.
Yes, you do. It's called keeping your job.
If your job depends on you meeting impossible estimates, then you're not going to be in it very long, no matter how hard you try.
Any time you are putting an estimate on the table without sensible requirements behind it, you are gambling.
Then get the sensible requirements. Work with the customer to figure out what they want and need (and maybe also what they think they want).
That is part of being professional.
Usually this is because you've already estimated it to the best of your ability but the powers above aren't happy with the uncertainty, where they harass you into giving a magic number or narrow little gap or to talk down your estimate until it's the number they're happy with.
If someone makes an estimate for you, or forces you to make a lower estimate, then you have no obligation to meet that estimate.
Be professional, and hit your estimates, but learn to let people know that things take time. These are soft skills.
Incidentally, This Manifesto against the agile manifesto entertains me.
eh,
:)
Agile Manifesto - February 11-13, 2001
Extreme Programming Explained - published October 1999
That's good enough to say "it came first"
As long as you understand, I'm not going to argue about the definition of "first."
And yes, I learned this tip about estimation from agile:
When you make an estimate, afterwards check to see how accurate the estimate was, and use it to improve the next time.
Using this method, over time I've gotten fairly good at not missing estimates. The only times I miss are when there are a lot of unknowns (and even then, I can usually give a reasonable outer-bound).
That seems like an obvious tip, but it's amazing how many people don't use it.
I'm going to need an estimate for how long it's going to take you to say Mooooooooo........and can you come in and work on Saturday? Yeah.
And looking back, I messed up on some in that list, too.........make_unique(new...) should be unique_ptr(new...) and I don't think there's an "alloc," I was thinking alloca(), but that allocates on the stack not on the heap!
A method's accuracy is less important than the persuasiveness of its arguments about why it was inaccurate.
In other words, "how can I take this failed estimate and blame it on someone else?" lol
In that case, your company has serious problems, of which estimates are the smallest.
Robert Martin recently wrote a book called Clean Coders which discusses exactly how to deal with that problem.
Essentially, he says if you want people to treat you like a professional, then you need to act like a professional. I highly recommend that book, it's good.
Refusing to do estimates is not acting like a professional.
In the 70s, we got Mythical Man Month
in the 90s we got Extreme Programming, followed by Agile.
Now we get #NoEstimates. I think we can do better.
One of the major complaints about estimates is that it "takes too long." Seriously, if estimations take any appreciable amount of time, you're doing them wrong.(unless you need to estimate some massive project, in which case you understand why estimates are needed).
If you want to remove the "time sucks," get off slashdot, get off twitter. When I turn off the internet while working on difficult code, I literally get twice as much done. I've measured this several times (and you can tell from this comment how much I will get done today).