John Passaniti wrote:
> John Doty wrote:
>> To you it's all about the code. But the code is only a tool to get the
>> larger job done. The larger job's needs *always* to have priority,
>> because the code is only a tool.
>
> What I really enjoy about our conversations is how you so fearlessly
> discuss the work I and my company does.
You snipped what you said that triggered that discussion. Are you afraid
it sup****ted my contention?
> You should really hire yourself
> out as one of those pretentious management gurus who sweeps into a
> company without knowing what it does or how it works (or relevant to
> this discussion, what problems it solves). Just fly in, offer some sage
> advice, clever canned phrases, and the same template used with every
> other company.
It seems to me that you, Paul, and especially Elizabeth have been doing
exactly that in this thread.
>
> No, to me it isn't all about the code. But at the end of the day, that
> pile of semiconductors does nothing without the code. And that code
> isn't just streams of symbols. It's the expression of quite a lot of
> domain knowledge that we have. As is the comments we embed in it that
> help others who may not be domain experts understand what is going on.
I agree. But you cannot make rules to make this happen, at least not if
the job is nontrivial. That just drives the best people away and creates
a culture of evasion. What you *can* do is create a collaborative
culture in which people are motivated to help each other out, and that
includes good do***entation, clear coding style, and comments. But
geniuses still make their own rules.
Some of the code in HETE-2 is commented in French. Should that be
tolerated in a project whose common language is English? In this case,
the domain expert was French. His method for getting that domain
knowledge into the code was to work with a particular professional
programmer with whom he had, over years, built a working relation****p.
She couldn't speak or write English, but she could not have been
replaced by someone who could. So, the code comments, while present,
were unreadable by most of the team. Still, it worked out fine.
>
>>> Dismissing the im****tance of internal do***entation by suggesting
>>> it's something you can "pretty up" later is telling. We consider
>>> "the real application issues" to *include* internal do***entation.
>>
>> Yes. But they are *secondary* because the code is secondary. Code
>> do***entation is im****tant, but it must never be allowed to interfere
>> with primary objectives. Of course, the right do***entation assists in
>> achieving the primary application objectives, but that judgment must
>> always be made from the application point of view, not from some rigid
>> notion of what constitutes a "professional programmer".
>
> How it is "rigid notion" to say that a professional programmer should
> comment their code? Nobody here has held up a style guide that makes
> ridiculous statements about how to comment. Nobody here has offered
> some metric giving an arbitrary amount of comments one must provide.
> These discussions assume that a professional does the right thing using
> their professional judgment. Funny that.
Yet Elizabeth and Paul make totalitarian comments on what must not be
tolerated. What do they mean by those?
I would think a professional programmer should be able to follow project
interface standards and use a revision control system. But on HETE-2 we
had a consultant writing critical spacecraft code who just wouldn't do
either. We had to do it for him. Why should we put up with that? In a
"well managed" project this wouldn't be tolerated.
The answer is that this guy did everything else superbly: design,
do***entation, coding, and testing. And he did it for a bargain price.
So for a tiny amount of extra work, we got a result well beyond the
state of the art, while staying within a tight budget. But a "well
managed" project wouldn't have tolerated him, and would therefore have
blown the budget for an inferior result.
>
>> NASA projects tend to have rigid do***entation rules that produce
>> rooms full of worthless do***ents. People waste vast amounts of time
>> trying to find useful information in all the fog. Sometimes there's
>> nothing but fog, which is even worse than no do***entation at all.
>
> I just checked my W2 form. It doesn't say NASA on it, so I'm struggling
> to find the relevance. Oh, maybe you're talking about all the other
> NASA programmers lurking here in comp.lang.forth. There are so many of
> them.
Elizabeth will assert there are "many". ;-)
>
>> I agree completely, and that's one of the many reasons it's really
>> nice to have the kind of person you and Elizabeth call a "professional
>> programmer" around to help the expert. But the expert is
>> indispensable, while the programmer is a luxury.
>
> You really need to look for another job. Such sad stratification in
> your field where people have fixed roles and titles. Depressing. Where
> I work (and actually, this is in my experience quite common), there are
> very few people who are *just* programmers. Where I work, I'm an domain
> expert *and* a programmer... and so is pretty much everyone else.
>
> I think we get into these discussions for two reasons.
>
> First, your apparently depressing work experience is all about
> stratified roles,
No, my own work experience is about radically *unstratified* roles, but
much of my experience working with *programmers* is that many love
stratification. And just like you, they deny it. They're like an
American who has looked over the border into Canada and believes they've
seen the world.
> and you assume this the norm for everyone. You've
> apparently been saddled with programmers who are pretty limited in what
> they can do. They can write code, but apparently not much else.
When the "else" takes a lifetime of study to master, I can hardly
complain that the programmer hasn't mastered it. But what I can complain
about is the common belief among programmers that such mastery isn't
necessary.
> And so
> when anyone writes the word "programmer" you knee-jerk and hit the macro
> key that issues one of your canned rants against programmers.
>
> Yet when I or Elizabeth or 85% of the other people in this newsgroup use
> the word "programmer," it's in the context of embedded systems. We're
> "programmers" in that we write code, but we're also burning our fingers
> on soldering irons and consulting data sheets to figure out the slew
> rate of a line driver. We're "programmers" in that we're worrying about
> the efficiency of a routine we wrote, but we're also in the field
> talking to end users and we're at the compliance testing lab getting FCC
> approvals.
Soldering. Yes, you go a few feet outside the "programmer" box. What if
the job requires you to go miles?
>
> Forgive us all to hell for using the colloquial term "programmer" in a
> newsgroup about a programming language since that's 95% of what is
> discussed here. And that's the second reason we seem to get into these
> discussions repeatedly: You've got some rigid lexicon in your head that
> apparently isn't swayed by little things like context or colloquialisms.
> When someone here uses the word "programmer" this to you isn't just a
> description of what someone does, it's a limitation on what they do. For
> you, a programmer is a mindless robot who is given a set of instructions
> and follows them without understanding.
But you yourself use the word "programmer" in this way. In a previous
message, you wrote:
> The most recent job candidates I've interviewed are pretty consistent in
> how they view their role. They are programmers and the language they
> use matters far less to them than the design. Programmers are finally
> starting to see that while language is im****tant, it's only one small
> part of what a programmer does. Coming up with a design, communicating
> that design to others, tested not just the code but the design itself--
> all of these things are what modern programmers care about.
>
> Take one small example: design patterns. The whole design patterns
> movement is about identifying common approaches in programming and
> expressing them in a language-independent way. When you take a
> well-known pattern (such as Publish/Subscribe), it is expressed not in
> terms of code, but in terms of intent. This is what modern programmers
> care about. Mapping intent to a language is an entirely separate
concern.
You are not describing domain experts who happen to write programs: you
are describing programming specialists. So which is it? You assert one
point of view when speaking in generalities, but your details tell a
different story.
>
> I guess there are programmers like that in the world. I don't work with
> them. Nobody I know works with them. Everyone I know who calls
> themselves a programmer shockingly knows something about the domain they
> are writing code for. This is why they are fun to go out to lunch with.
Sure they know *something*. But are they world experts with years of
experience? That's the level of domain knowledge I often need people to
have.
>
> Your experience with NASA must have scarred you deeply.
I've mostly managed to avoid the difficulties. Also, I've done more work
with ISAS than NASA, and they're much more sensible. But I was once
called in to pick up the pieces of a NASA project that had collapsed
under the weight of the sort of totalitarian management that Elizabeth
and Paul advocate. That was extremely unpleasant, but I got it fixed.
> Well, thanks
> anyway for the heads up on what must be a terrible place for programmers
> to work. Feel free to cite any other places you have experience with
> that follow this model so we can all cross them off our lists.
--
John Doty, Noqsi Aerospace, Ltd.
http://www.noqsi.com/
--
History teaches that logical consistency is neither sufficient nor
necessary to establish practical, real world truth. Those who attempt to
use logic for that purpose are abusing it.
|
