Menders, Makers, Mentors

[elfs]

Andrea Goulet is giving me an existential crisis. The CEO of a software development consultation shop, she recently wrote an article called <a

href=”http://corgibytes.com/blog/makers/menders/software/2015/08/14/makers-vs-menders/”>Menders vs. Makers</a>, and something happened this week that makes me think, maybe I’m in the wrong line of work. I’m starting to suspect I’m a mender in a business that only values makers.

This week, I was working on a code base that provided a hierarchical tag editor for an inventory system. I had recently added a new feature that made it possible to see individual elements of the tag system on the Collection page; you not longer had to go visit a single object to see if it had, for example, a <em>location</em> tag; you could just say on the Collection page, &quot;Show me all the objects that have a location tag, and add a new column, <em>location</em>.&quot;

Now that we were able to see the tags, a new problem was found: it wasn’t possible to delete tags. Odd nobody had noticed that before. Since I was the last person in that code base, it was my duty to fix it. Down into the legacy code I went.

The tagging code was, well, intermingled. Validating the tags, determining the changes between the version on the client and the version on the server, writing those changes back, were all in a single gigantic Backbone sync method involving empty arrays, for loops, and concat methods. I spent about four hours, during which I:

<ul><li>

Replaced all <code>for</code> loops with <code>map / reduce / filter</code>

</li><li>

Separated the model validation into its own method

</li><li>

Used underscores’s <code>intersection / union / difference</code> functions to create instruction sets for deleting and adding to the tag system

</li><li>

Used Backbone’s <code>set([_], (void 0), {unset: true})</code> method to delete the tags, rather than hammer the event bus with a series of change events in a <code>each</code> loop.

</ul>

. I struggled a <em>lot</em> to make sure I was using names that explained what each thing did.

In short, I did with my code what I did with my writing: try to make every line a <em>pleasure</em> to read, something that told a story about what was happening and what was going to happen next. I hope when someone sees <code>overlappingTags = _.intersection(newTags, restrictedTagNames)</code>, it’s obvious what’s happening, and it should create anticipation that soon there will be a line that checks to see if <code>overlappingTags</code> has anything in it and, if it does, reports an error with the offending tags.

I’ve always had fun doing stuff like that, turning unreadable mash into clarity. Even my recent bragging project, <em><a

href=”https://github.com/elfsternberg/polyloader”>Polyloader</a></em>, is actually a fix for the &quot;All Python on the filesystem ends in .py&quot; bug that sorta firewalls.

I’ve found this industry doesn’t really <em>like</em> menders. Code editors, people who go in after the fact and apply measures both aesthetic and qualitative to the code they see, are often seen as nothing but agency overhead by managers.

On the other hand, I’ve yet to meet another developer who resented menders. They like menders; they want to learn from menders how make code better. Menders tend to be older, tend to know more, tend to be broadly learned and strongly opinionated. Nothing &quot;just gets thrown there.&quot; It has to be fixed, it has to work, it has to be right. And I’ve yet to meet a software developer who didn’t want to get it right. Often, they just don’t know how, or nobody’s ever told them how.

Let’s show them how.

Comments

[thnidu.livejournal.com]

Did you mean to post this as HTML code?!

teaching?

[(Anonymous)]

Don't just make things, make them better: more functional, more elegant, more efficient, more whatever... Isn't this what teaching is? "Here's a new way to do task X" and "here's a new perspective or subject" and "here's a new way to think about this"?

Mending is about making, I think, but it's the same reason that people have trouble accepting that "editor" is as important a job as "writer".