...and something I've thought interesting since Java's inception is that Thread.stop() is not realiably implementable, semantically, in any language. Ada language developers knew this and accounted for this in the language initially but the Java folks failed to pick it up until well after 1.0--deprecated now. Just goes to show you that understanding concurrent programming models is much more useful than concurrent programming languages in the long run.
Hardly, Ada was mainstream in the 80's and even in commercial circles at the time. Didn't Modula have one, though it was not really mainstream. Java Developers' lifecycles are too short it seems to appreciate standing on the shoulders of language giants that preceeded them. Where do you think Java Threading got some of its best ideas from? What do you think Java's lifecycle will be?
This is a very good software engineering in practice question. Though I do not know your particular situation in detail, I would first suggest that you look for strengths in your coworkers rather than finding obvious weaknesses. A sure way to motivate a colleague is tell them how cool or interesting something is and explain this in such as a way that they see your comment is truly genuine. In short, you should get more involved with them. Avoid the closest programmer mentality. I have a lab full of folks who work for me and most of them have that mentality (I'm working on them). I try to engender a sense of discipline and constant communication through engineering tools and practices, such as those in applied CS; this keeps everyone focused on the problems and not on each other. For example, how many design patterns are known between you? Do you share the same understanding of them and the heuristics that accompany their application? SW engineering discipline requires a common articulation framework through which you and your colleagues can conduct meaningful and respectful debate, not pissing contests. Another thing you can try is to make facetious fun of your own mistakes without undermining your sense of competence. This lets your coworkers know that you?re human and not just the one outperforming them. This makes you more approachable. This may all be from left field but perhaps it can be on some help.
It would help for everyone to read some history (humans don't live long enough) regarding the evolution of engineering disciplines from their respective sciences. Software Engineering is just that. Computer Science lacks many of the formalisms to properly discipline the engineering that results. And that is all there is to it. This does diminish software engineering as a proper discipline, however. If you have been building systems as long as I have (20+ years) and you have an engineering degree at least (and you have an open mind), then you have ground to talk on. Otherwise, you are arguing with yourself to no end.
My opinion, in short, is that if you think that all there is to software engineering is just code, then I'll tell you what I tell the "coders" in my lab that keep repeating the same engineering mistakes: you don't understand the problem space and that's why your "code" does not work. Understand the problem (a science) and the code solution will present itself.
By the way, the "coders" work for me, not the other way around.
I don't think we should give a damn about what a Microserfer has to say about why, when, or how M$ got into its current perception mode. I'll use a quote from a former IBM manager of mine: perception is everything; the truth is of little importance. I'm laughing as I look at the Borgy-Bill at the top of the slashdot page now...A Borg by any other name is still a Borg!!
M$ must reap what it has sown, including
its Borg-like perception. I will admit
that words like vindication, absolution, etc.,
crossed by mind as personal driving motives for such a book. Read it and know thy enemy (better)? Maybe a page or two wouldn't hurt.
Slashdot Mirror
...and something I've thought interesting since Java's inception is that Thread.stop() is not realiably implementable, semantically, in any language. Ada language developers knew this and accounted for this in the language initially but the Java folks failed to pick it up until well after 1.0--deprecated now. Just goes to show you that understanding concurrent programming models is much more useful than concurrent programming languages in the long run.
Enjoy!
Hardly, Ada was mainstream in the 80's and even in commercial circles at the time. Didn't Modula have one, though it was not really mainstream. Java Developers' lifecycles are too short it seems to appreciate standing on the shoulders of language giants that preceeded them. Where do you think Java Threading got some of its best ideas from? What do you think Java's lifecycle will be?
Enjoy!
This is a very good software engineering in practice question. Though I do not know your particular situation in detail, I would first suggest that you look for strengths in your coworkers rather than finding obvious weaknesses. A sure way to motivate a colleague is tell them how cool or interesting something is and explain this in such as a way that they see your comment is truly genuine. In short, you should get more involved with them. Avoid the closest programmer mentality. I have a lab full of folks who work for me and most of them have that mentality (I'm working on them). I try to engender a sense of discipline and constant communication through engineering tools and practices, such as those in applied CS; this keeps everyone focused on the problems and not on each other. For example, how many design patterns are known between you? Do you share the same understanding of them and the heuristics that accompany their application? SW engineering discipline requires a common articulation framework through which you and your colleagues can conduct meaningful and respectful debate, not pissing contests. Another thing you can try is to make facetious fun of your own mistakes without undermining your sense of competence. This lets your coworkers know that you?re human and not just the one outperforming them. This makes you more approachable. This may all be from left field but perhaps it can be on some help.
It would help for everyone to read some history
(humans don't live long enough) regarding the
evolution of engineering disciplines from
their respective sciences. Software Engineering
is just that. Computer Science lacks many of the
formalisms to properly discipline the engineering
that results. And that is all there is to it.
This does diminish software engineering as a proper
discipline, however. If you have been building
systems as long as I have (20+ years) and you have an engineering degree at least (and you have an open mind), then you have ground to talk on. Otherwise, you are arguing with yourself to no
end.
My opinion, in short, is that if you think that
all there is to software engineering is just
code, then I'll tell you what I tell the "coders"
in my lab that keep repeating the same engineering
mistakes: you don't understand the problem space
and that's why your "code" does not work. Understand the problem (a science) and the code solution will present itself.
By the way, the "coders" work for me, not the
other way around.
I don't think we should give a damn about what a Microserfer has to say about why, when, or how M$ got into its current perception mode. I'll use a quote from a former IBM manager of mine: perception is everything; the truth is of little importance. I'm laughing as I look at the Borgy-Bill at the top of the slashdot page now...A Borg by any other name is still a Borg!! M$ must reap what it has sown, including its Borg-like perception. I will admit that words like vindication, absolution, etc., crossed by mind as personal driving motives for such a book. Read it and know thy enemy (better)? Maybe a page or two wouldn't hurt.