Tag: perl

Python docs, more on wget

Things I have learned today:

  • Python has a lot of modules that are documented well enough to make you cry. Other modules are documented so poorly that it will make you cry. Why am I using GNU parallel? Because creating a bounded threadpool in Python, a task that seems like it should be pretty straightforward, was documented so confusingly for me that I just ended up using the command line instead.
  • wget is a surprisingly easy way to hammer your CPU; run eighteen simultaneous processes and watch the CPU bleed. Great fun for all! (If you can’t guess: parallel is being used to fix this.)
  • I will be fascinated when I learn Gutenberg well enough to leverage it. It’s supposed to be like Medium’s editor, and I suppose it is; I don’t like Medium’s editor either.
  • The best and worst thing about programs to allow you to play Solitaire is how easy it is to play a new game; you end up not valuing a given hand, because if it gets difficult… redeal. That means you lose some hands you could win (“eh, too hard”) and means that you also don’t really value winning as much as you used to, because you can play so many hands so quickly.
  • I find no irony or contradiction in appreciating the Avett Brothers alongside Rush and Yes and Pink Floyd and Led Zeppelin and Weather Report, but I expect others to be surprised at my choices in music. I think other people think I am easily pigeonholed, and maybe I am, but not along the lines of music genres… I think.
  • I ache when my friends ache. Sometimes I wish I did not, but I think the world would be much, much sadder for me if I couldn’t share others’ pain.
  • GNU parallel uses perl. This is amusing. It works; it’s great; it’s still amusing.
  • I like jokes that don’t have victims, generally speaking, but I have no problem using a few specific people as the targets of jokes… Paul Finebaum comes to mind. Give us a rest, Paul. We know you like the SEC.
  • Other people whose voices I could do without: Stephen A. Smith; Sean Hannity; Tucker Carlson. By the way, Tucker, not that you’ll ever read this, but…
  • YES, diversity is a good thing, and while we can argue about specific granularity and I have no problem conceding that there has to be a certain amount of homogeneity in value systems, only a total moron would dare argue seriously that cultural diversity, in and of itself, is a Bad Thing. Shut up, you knob. I appreciate that you use a cannon where a scalpel is better suited, and I hope you know that this is what you’re doing (and therefore you’re being obtuse on purpose) but every now and then it’s good to remember that nuance is A Thing To Use.
  • I decided I was going to try to publish one of these a day, and that streak lasted for ONE DAY.

My Actual Skillset

Recently, someone said that I needed to put more of the things with which I’m experienced on my resumé. They’re right, but it’s not an easy task, for a few reasons.

The main reason is that it’s too long. If you can name a mainstream language, chances are I’ve done something meaningful with it. Perhaps it’s not been a major project, but I’ve probably kicked the tires of each language enough to understand what it’s about, the paradigm of the language and ecosystem.

It’s not just limited to mainstream languages, either. There’re some obscure languages that litter the landscape, like Louis II, and even some custom languages, including some to which I contributed.

More than languages, it’s libraries. Java is one language, but it has thousands upon thousands of libraries and utilities providing functionality for application developers. Those libraries range from frameworks like Java EE to Spring, all the way down to matrix and artificial intelligence libraries and over to tiny utilities that just make tasks easier.

The problem here is how to specify with what I have experience, in such a way that my experience stands out in useful fashion.

The other main problem is how and why I have that experience, and what that experience means.

When I was in my twenties, and I’d not used C++ for a few years, a friend of mine and I sat down for what would now be a pair programming session. It’d been a while for C++ and me; I remembered what do to, but when confronted with the actual blank screen, I spaced.

I don’t remember what we did next; we probably played guitar for a while.

That moment stuck with me, though. It hit me again when I was working on the Alcyone, my MIDI foot-pedal controller project, which is written with C++. When I sat down to write it, my first thought was vague panic: how well did I remember C++? Was I good enough to get it done well? (The answer was: well enough, and yes, thank you.)

I use that sensation all the time. It was the basis of my employment by TheServerSide as editor in chief, the guy who’s supposed to vet content for quality and accuracy, and the guy who’s supposed to provide an actual perspective.

And there we have another problem with my experience: depth.

A while back, someone lambasted the Miami Hurricanes’ fanbase, pointing out that it was a mile wide and an inch deep; all their fans are band-wagoners. (When the team does well, they’ve been fans forever; when the team struggles, well, the beach is over there, are the ‘Canes playing today? By comparison, we Florida State fans are actual fans.)

Well, that’s me and a lot of technology, honestly: because TheServerSide watched everything, generally from Java’s perspective but not limited to Java, I encountered it all. Every obscure library wanted to be promoted, so I’d get notices of everything.

I read hundreds of posts a day, trying to understand not just the posts themselves, but whether they were relevant for a wide enough audience that I needed to tell my readers.

Once I decided that a topic was relevant, I had to write it up in such a way that I was actually trying to explain it to my readers. That meant I couldn’t see some obscure fuzzy logic library and think “Oh, that sounds neat,” and then copy and paste some blurb from the project website.

I had to download the project, perhaps build it. I had to understand the problem domain the project was trying to address. I had to try to use it, to see if the project’s claims were accurate, and to see how I actually felt about how it was used.

Therefore, my experience wasn’t just a mile wide and an inch deep – I had to approach everything, and build my experience to the point where I could conceivably use the project to actually do something. I had to come at everything with my tiny grains of knowledge and build a fortress against the ignorance, so I could tell others something they needed to know, whether they knew they needed it or not.

It wasn’t an easy job.

However, that was perfect for me: it played into my skills as an architect, and as someone who integrated information quickly and well, and into my desire to connect people with information.

However, how do I use all of this? Well, as a architect and a consultant, I’m good at approaching problems cold, and seeing how possible architectures map to those problems; I am not limited to seeing things from Spring’s perspective, or Hibernate’s, or Mule’s, or Rails’. I’ve used them all, and I have a good idea about what I think works well, and why, and where they don’t work well.

And if I’m wrong? Well, I don’t let my ego carry me too far down a wrong path; I know I’m human, I know I rely strongly on my ability to integrate and learn. So what, if I recommend Spring for something at first, and find that something else would be better? I had to learn, and I do learn.

So the issue with my experience is two-fold: it covers too much to be useful, and the best aspect of it is the experience of using and learning, as opposed to raw mastery of a given limited set of technologies.

I’m not really sure how to leverage that in the cold light of a resumé.