A space to ponder, discuss, speculate, disagree, and learn.
Expected topics include:
Expected topics include:
- Technology
- Politics
- Defense
- Philosophy
- Humanism and Transhumanism
- The Future
Reflections: Progress on OpenSSL, and Greybeard Wisdom
I'm finally pulling out of a months-long depressive funk, and touched my openssl patch again. On one hand openssl isn't exactly pleasant to work with (hardly any comments, bizarre formatting, obscure internal interfaces), but it felt good to be writing some C and making progress on my #1 project.
In addition to writing the code, I really should be documenting the whys and hows of the changes, like I promised my friend Chris. I didn't remember that until just now. Perhaps enumerating my subtasks in Trello would help.
There are some other projects I'm adding to the list, but won't let myself work on them until the openssl/openssh patches are done, and until I've gotten some progress made on ZACL: One is restd, a utility which wraps a Mojo instance to provide a fully-featured REST service with a minimum of boilerplate. Another I haven't named yet, but it overlaps with both DrunkenFay and the Black Tea Project: a distributed service of multiple Lucy instances with an ElasticSearch-compatible API. I've mentioned the latter a little on my Wikipedia User page already, under the Black Tea Project section. Finally, I'd like to try installing Redmine for personal use. If nothing else the exercise should improve my understanding of Ruby and Git.
Also, I'd like to try to be more active on this blog here. I have several topics lined up, but never get to actually writing about them, so thought it would help to simply expound upon things I've already written about a little. To that end, I'm adding a new category, "Greybeard Wisdom", for writing about engineering practices and methodology. Picking lines from my Code of Engineering should provide me with seed content for a while.
Why the new category? There seems to be a need. Methodology isn't taught in school anymore (and it's been pointed out to me that most schools have never taught it; I was lucky), so most engineers in the industry have no notion of guiding principles for which methods to apply to their projects, or why.
I tried to talk a bit about the "why" at Cyan, but it was a bit like spitting into the wind. I didn't realize it at the time, but I was making references to things with which I assumed my coworkers were familiar. They were not, so everything I said came across as confusing babble. On top of that, the courses of action I suggested flew in the face of current industry practices (which, despite being popular, are ill-advised), so it's not too surprising that they opted to ignore what I was trying to say and do the obvious-seeming thing (like rolling releases in what amounted to the company's fork of the Ubuntu operating system, when the team had neither the manpower nor self-discipline to make rolling releases work).
At the same time, I think there really is a desire out there to learn (or at least listen to) the "why" behind traditional engineering practices. I have no statistically valid data to back this impression, only a series of anecdotes. Here is one for illustration's sake, from a recent IRC chat:
See what happened there? Homer (author of the linked blog entry) may be right (I think he makes mostly valid points), but he never explained the principles upon which his arguments are based, why they are important, or how they logically support the rejection of systemd, pulseaudio, and its ilk. Instead he made vague references to "well-established principles" and provides some links of at best oblique relevance.
The result? These two young readers, zg and twm, don't try to examine his case in depth. They reject it as the ravings of an insane, closed-minded asshat. How long will it be before they and others like them treat "principle" as code for "lunatic old fart lecture"? If they haven't already. (With Homer's example to go by, can we really blame them?)
I'm better at writing than speaking, so perhaps this blog will provide the better medium for expression. I will also try to go back to first principles and explain the logic bridging those first principles with good engineering practices. Once written, I can refer people to them instead of trying to be glib on the spot.
That's the plan. Time to execute.
In addition to writing the code, I really should be documenting the whys and hows of the changes, like I promised my friend Chris. I didn't remember that until just now. Perhaps enumerating my subtasks in Trello would help.
There are some other projects I'm adding to the list, but won't let myself work on them until the openssl/openssh patches are done, and until I've gotten some progress made on ZACL: One is restd, a utility which wraps a Mojo instance to provide a fully-featured REST service with a minimum of boilerplate. Another I haven't named yet, but it overlaps with both DrunkenFay and the Black Tea Project: a distributed service of multiple Lucy instances with an ElasticSearch-compatible API. I've mentioned the latter a little on my Wikipedia User page already, under the Black Tea Project section. Finally, I'd like to try installing Redmine for personal use. If nothing else the exercise should improve my understanding of Ruby and Git.
Also, I'd like to try to be more active on this blog here. I have several topics lined up, but never get to actually writing about them, so thought it would help to simply expound upon things I've already written about a little. To that end, I'm adding a new category, "Greybeard Wisdom", for writing about engineering practices and methodology. Picking lines from my Code of Engineering should provide me with seed content for a while.
Why the new category? There seems to be a need. Methodology isn't taught in school anymore (and it's been pointed out to me that most schools have never taught it; I was lucky), so most engineers in the industry have no notion of guiding principles for which methods to apply to their projects, or why.
I tried to talk a bit about the "why" at Cyan, but it was a bit like spitting into the wind. I didn't realize it at the time, but I was making references to things with which I assumed my coworkers were familiar. They were not, so everything I said came across as confusing babble. On top of that, the courses of action I suggested flew in the face of current industry practices (which, despite being popular, are ill-advised), so it's not too surprising that they opted to ignore what I was trying to say and do the obvious-seeming thing (like rolling releases in what amounted to the company's fork of the Ubuntu operating system, when the team had neither the manpower nor self-discipline to make rolling releases work).
At the same time, I think there really is a desire out there to learn (or at least listen to) the "why" behind traditional engineering practices. I have no statistically valid data to back this impression, only a series of anecdotes. Here is one for illustration's sake, from a recent IRC chat:
Code:
<ttk> http://slated.org/the_poetterisation_of_gnu_linux (sfw) <twm> Wow, what an asshole. <zg> twm: He's the kind of guy who doesn't like to change <zg> He names a bunch of programs and that they're bad, but he doesn't give specific details on why they're bad.. <zg> Also, he basically tells Windows developers who want to develop on GNU/Linux to 'fuck off' (not literally), instead of informing them on what they should know/learn to become more acclimated with his own style <zg> "Hey guys, let's yell at idiots instead of telling them what they're doing wrong!" "Okay!!" <ttk> that seems like a valid criticism of the author's approach <ttk> though I suppose he might not see educating would-be developers as worthwhile, given his ideal of "a small number of competent developers producing software to a high technical standard" <ttk> .. which seems like the same formula which led to the marginalization of BSD <zg> true <zg> I was thinking about replying, but why bother? Let the old man die in his arrogance. * ttkay gets back to work, but will mull over your criticisms of the article. I disagree with his statement about limiting participation to a tiny elite, but generally agree with his sentiment of know-nothings forcing change for change's sake, replacing tried+true systems with inferior alternatives. <zg> Yeah <twm> It was the statement about limiting participation that made me call him an asshole, to clarify. But I disagree with most of the rest of what he said. <twm> Since he failed to support his positions at all, I feel safe rejecting it as the ravings of someone who just doesn't like things changing. <twm> Particularly when it comes to init systems. I don't care that much whether we pick systemd or Upstart as the new init, but legacy init scripts need to die.
The result? These two young readers, zg and twm, don't try to examine his case in depth. They reject it as the ravings of an insane, closed-minded asshat. How long will it be before they and others like them treat "principle" as code for "lunatic old fart lecture"? If they haven't already. (With Homer's example to go by, can we really blame them?)
I'm better at writing than speaking, so perhaps this blog will provide the better medium for expression. I will also try to go back to first principles and explain the logic bridging those first principles with good engineering practices. Once written, I can refer people to them instead of trying to be glib on the spot.
That's the plan. Time to execute.
Total Comments 0
