[erlang-questions] Rhetorical structure of code: Anyone interested in collaborating?

[zxq9]

On 2016年5月5日 木曜日 10:15:26 Garrett Smith wrote:
> I can't even believe I read that - is that article a troll? It's very
> convincing, apart from the content.

Don't worry, you're not the only one who doesn't agree.

But after years of seeing entire operating system stacks reimplemented wrongly in javascript, only to be swept away by even crappier rewrites that achieve less with more, I'm not in disbelief or even shock.

You have this same understanding of things deep down but can't accept it, and shouldn't, because this approach is indeed wrong.

As a counter example...

I'm currently working on a team that has just arrived at its magical moment (luckily for me, just as I have arrived), pushing past a gigantic ball of mud (which one of the guys called, in a wonderfully astute use of political office language "a single-component architecture" -- most hilarious joke I've witnessed played straight IRL since leaving the Army), endowed with management that actually trusts us, and that has actually been given an appropriate amount of time for us to experiment a bit, write a lot, present some competing ideas, and collectively settle on component responsibilities and work together to define concrete interfaces among components.

And... holy crap, nobody feels depressed when its time to go to work anymore. The code makes sense. We discuss amongst ourselves the best way to convey the purpose of the project, its components, and the code to different types of readers. When a new requirement comes up there is an *obvious* place it should belong, etc. I'm no longer stuck totally SOL if the guy who happens to know how to unjigger the floop in called back callback module some_unmemorable_name_that_makes_no_sense.erl is on vacation for a few days. Writing documentation is not only possible (we forget how hard it is to even document stuff beyond a certain point of project Hell), it is actually enjoyable, and presenting our new direction to the company in internal talks is actually fun again. Etc.

And... despite the impulse to say "all that documentation and deliberation is a waste of time" we are *obviously* moving at a pace that dramatically outstrips that of the previous ball-of-shit approach.

None of that positive action would have been possible without 1) the team being in a good state, and 2) all of us actually caring about detailing all this "stuffy old engineer stuff". Also, I'm probably the oldest guy on the team (and I'm not very old) -- the pack of young geniuses is *relieved* to do things like establish which direction we're headed before rushing off into an editor.

Blah blah. There is a whole world to be learned about learning within projects. I doubt anyone cares much about my anecdote outside of hopefully being able to relate to it (and its unspoken anti-examples), but my point is that your instincts are right and the whole concept of "poking" as the sole method of coding is insane.

The stuff we make is always a bit messy. Pretending that things *should* be messy is like denying that the mess exists. That's a more destructive attitude than embracing the reality that iteration toward clean implementation is the natural order of things (and that sometimes new requirements set the realization of your unending trek to perfection back a million miles or so).

Meh. This whole thread has caused several cascades of thoughts, emotions and recollections that I don't have time to sort through. Your reaction to that article brought me out of lurk mode, though.

-Craig