isn't quite ashamed enough to present

jr conlin's ink stained banana

:: F*ck You, Brain.

i feel fortunate that i am reasonably mentally healthy. There's a lot of people who actually have depression, bi-polar disorder, ADD and other conditions and those people have my respect.

That said, i can understand a tiny fraction of what they go through. i tend to be very hard on myself. i tend to favor criticism more than complements. This is normal, of course, and chances are exceptionally good you do the same thing. i know this because a few years ago when i felt i was at a very low point i wanted to understand what the hell was wrong with me. It was a pattern i found myself falling into and since i didn't enjoy it, i wanted to know what i could do to solve the problem.

Turns out, little, since we as a species are pretty firmly hardwired for it. i found that at least for me, understanding what was going on did help. Later on, finding books like You Are Not So Smart really helped me understand even more of this sort of self inflicted crap.

Part of this is also my industry of choice. Long ago, i consigned myself to be a tradesman in the midst of artists. There are programmers that craft things of magic and joy. These are wonderful creations that improve life in this veil of tears immeasurably. Granted, those things often need to be maintained and supported. At times, bits need to be built out of things stronger than pixie dust and gossamer, and i take a bit of joy trying to make sure that folks don't know that some of the "magic" is now rebar.

i'll also admit that i'm not the best at what i do. Even after working a lifetime in the industry. There are others that i work with that make me look like an amateur. These are people i can greedily learn from, and i'm damn thankful of the opportunity, but it also means that in a culture that spotlights "Rock Stars" and "Ninjas", i'll be the guy near the back of the auditorium clapping.

All of this can be a bit… i don't want to say depressing, but it's certainly draining. i've had numerous, very dark thoughts, but generally can dismiss them. There are days where i feel reasonably good about myself and completely understand that in very short order, my mood will be completely reversed by something. i've learned that this swing happens in both directions, and frankly it's best to simply not let the pendulum swing that hard in any direction.

Take, for instance, right now. At this time, i'm feeling very low. i was responsible for a bit of infrastructure. i drafted the design, implemented code, and got it working, and felt reasonably good about myself. Projects started relying on it. Outside groups started playing with it. There was a significant challenge, i needed a bit of help, and we met the challenge with some tweaking.

The code has since been rewritten by someone far younger than me and is, in many respects, far better than what i originally built. It's lighter weight, more responsive and probably more maintainable than what i had built. i already see ways that it could be improved and expanded.

It's also probably going to be a failure point because of things outside of my control, which may cause the projects that were relying on it to also fail. None of the breaking points are my fault, and i've noted what the problems are, how to address them, and what actions are available to all. When i dismiss fault, i am being very clear. The failure is due to a behavior in a system i did not code for nor did we clearly understand at the onset of the project. If this system is removed, the fault is also removed, however this system is required for it's own reasons. It's a bit like saying "Well, the crop harvest failed due to the dam break."

Still, it's damn hard for me to shake the "This is your fault, and you suck as a human being" mindset. The program was written in a language and construct i wasn't fully familiar with. The younger engineer is, so that's why the code is better after his attention. The failing system is one that i am also unfamiliar with, and the subsystem that is an issue came as a surprise to a good many folk. i view all of these as being "excuses". My psyche demands that excuses don't matter, only results. (Yes, i was brought up in a strict, military household, why do you ask?)

People talk about failure as a benefit. It's how one learns. It's inevitable, and constant, and what makes success so remarkable is that it's uncommon enough to be remarkable. This does not make failure any less pleasant. Culturally, and personally, it's a stigma. Feeling that way is irrational, but very common.

At this point, i'll also think about the various other projects that i feel the need to accomplish, and the sorry state that they're in, the 60+ articles moldering in my unread queue and a thousand other reasons i have to beat myself up. i should be accomplishing more. i'm not. i should be more creative. i'm not. "Nobody else knows how big a screw up you are" as Mr. Savage points out, but i am acutely aware of it.

Like i said at the top, there are folks out there with serious medical issues who are constantly struggling with far bigger demons than me. i admire every day that they succeed in beating those demons and they have every right to scoff at me and my personal pity party. If you're one of those, i welcome your well earned derision.

Possibly, you may feel the same way i do. Here's to letting you know you're not alone.

And thanks for reading my bit of personal therapy.

:: Disposable Medium

i'll admit that i generate content that is disposable. i tweet, occasionally post crap to facebook and sometimes toss images up on imugr. Sometimes, i comment on reddit. All of that is disposable.

It's disposable because i don't own or manage the forum or pay for the servers. It's not mine to archive, index or monetize. My account may be blocked or dropped for reasons i have no control over. Whatever i generate may go away tomorrow and i'll have zero say in the matter. If i'm lucky, i'll be able to pull a portion of the content off of these sites, but who knows if i'll be able to do anything with it.

Sites, even very popular ones, shut down all the time. It's a well documented fact of life. All the stuff you put on that site disappears when they decide it's no longer profitable/viable/fun anymore. Heck, there's even a team that tries to rescue your crap before it disappears forever. All of that kinda rose up when i tweeted:

i was half kidding, but honestly a bit serious. For reasons i'm still not quite sure about, Medium has become the latest blog substitute. The replies i got on that tweet were equally unsatisfactory. Yes, posts do look pretty-ish, provided you can figure out to get images to do what you want, but you're pretty damn limited, and let's face it, every post is basically "Large Hipster style banner pic with Headline, followed by paragraphs of 22px Georgia font. Ok, so this blog clearly illustrates that i have zero modern styling sense, but it's not terribly difficult to duplicate that look.

You're also fairly limited in the sort of things you can do in your text. In my blog, i've got carte blanc. There, i've got the limited styling features that they demand i use. i suppose the next item would probably be the network effects, i post there because all the cool kids post there, therefore i'm a cool kid too! This is like standing in front of stuffed toys and claiming to have given a Ted Talk. (Granted, there are some that probably should have stuck with the stuffed toys, like this one:



$7500 spent to hear that talk. Money well spent, huh? And granted, that one was probably for laughs, so there's this one instead). Granted, since folks don't seem to like RSS anymore, it's a bit harder to find interesting articles outside of twitter, facebook, reddit, buzzfeed, digg, slashdot, your aunt's forwarding email, bathroom walls, …

Honestly, it's the message, not the platform that makes one cool or interesting.

i get that some folks don't want to run their own site. That's fine, it can be a hassle to make sure that software is up-to-date. What i don't really understand is the value folks are seeing. Is it like the early days of the internet where things that weren't written in comic sans on a gray background were considered to be believable, published articles? Is it that these folks don't really want to be all that closely associated with what they're creating? Is it that blogger/wordpress.com/facebook/google+ isn't the latest new thing? (Ok, Google+ is probably never really going to be a thing.) Is it that they don't care if what they're spending time making lasts longer than a reddit karma cycle? Do these folks not realize that the most effective way to build a known presence on the web is to have a known presence on the web?

i have absolutely no idea.

For throw away stuff, i don't mind using disposable services, but i think i'll keep using stuff i have some control over for things i want to stick around.

:: The Streetcar Problem

Streetcar-CrashProgramming nerds love theoretical technical problems like The Prisoner's Dilemma, or The Dining Philosophers. Here's a fun mental exercise for your afternoon: What would happen to your favorite library/service/product if the principal engineer was suddenly killed by a streetcar? For an astonishing number of services, the answer will probably not be "continue to work seamlessly".

(i'll note that i decided to break this out of a different post about Being Nice for Selfish Reasons: Work Edition. i decided that it's a question that needed it's own post.)

Most projects, like most movements or causes, tend to have a singular leader. There's a lot of reasons for that, including the facts that running a successful project kinda requires someone to make hard decisions, say "No, we shouldn't do that" a fair bit, and "We're going to go in this direction, in spite of your personal interests". There are ways to present all of those statements, sometimes in friendly, happy ways, other times like a overbearing jerk, but there are ways. The problem is also the Achilles Heel of Open Software Projects: Getting someone else to give a damn about what you're building. You have to be nice enough or provide enough value that people want to help you and deal with your pushy ideas on how to do things.

There's a weird psychological edge to successful software development that many folks don't think about. If you even think about the tools and services you use, you probably associate them with one or a very small group of lead folks. These are the captains of the project and in some respects are cult leaders for their ideas, even if they aren't in direct control. Python has Guido; jQuery has jresig; PhP has Rasmus; etc. Larger projects like Webkit require a large, organizational structure to deal with the huge, complicated code base. However, even these projects have a small group or even an individual who is the acknowledged leader. This is pretty much how humans set things up.

So, what happens when such an individual leaves a project? Usually, it's "not good things". In the sudden vacuum, there can be a power struggle as folks fight to become the replacement, or things drift as the next person in line has a slightly different view of how to do things. In rare instances, it's possible for the project to continue or improve, but that's usually because one of the goals of the individual at the helm was to ensure that he or she is replaceable. Yeah, not a lot of folks think that way. It's very uncomfortable for people to confront their lack of permanence.

All of this does impact you, however. You invest in a given resource. Whether you like it or not, you become dependent on that resource more and more. When the streetcar comes, you're also subject to the repercussions. If you're lucky, skilled and have the time, you can fork the project and keep it alive long enough to find a suitable replacement. If not, well, you're dorked.

It can also be exceptionally difficult to keep your product "Streetcar proof". Sure, there's principals of abstraction, but the big problem is that there are reasons you've picked a technology or service over it's competitors, and those reasons will be reflected in the core of your product's design. Replacing or degrading those will not be easy, or potentially possible for whoever is maintaining your code.

Yeah, that's right. You're also subject to Streetcars.

So, when your personal streetcar arrives, how will folks deal with it?

:: Building A Worse Toaster

Sadly, i'm rolling misses on my Google Fu this morning, but i believe that C.J. Cherryh wrote a short story about an elderly woman who wanted a new toaster. It being the future, the device delivered itself and promptly started doing the laundry, fixing the car, reprogramming the TV and all sorts of other wondrous tasks. The Matron, tutted, jabbed a fork deep into the machine. It sputtered, fell over, sparked and finally a warmed, lightly browned piece of toast popped out of a slot.

While the story is funny, it's also really useful to remember when building a tool.

Ultimately, you want your tool to be as simple as possible. This is the general theory of Unix. Little things that work well together. The problem is that building simple things tends to not be very popular.

As a software engineer, i am both subject to, and constant advocate of, feature creep. i want things that just do a bit more. i mean, sure i could have something that's just a front end to a database that allows me to enter a blob of text and then later display it,… but it could also have an inline editor, ooh, and a search function, and it'd be neat to have plugins… And, well, you wind up with WordPress.

Same with things like jquery, which started off as fairly simple and small, then became, well, jquery1. Even protocols go through that sort of progression (mind you, i already ranted a bit about "human vs. machine readable"). Darn near everything tends to start simple, but get increasingly more complicated.

As is usual, a number of things tweaked me about this point. One was an old rant about how even though people spend most of their lives in front of a computer now, most don't know how to use one. The other post talks about developer inequality and a longing for Hypercard. Both pretty much highlight the same thing, and i could argue against both equally.

For the first, i'll note that computers are media delivery devices and people tend to prefer to consume more than create, and that's ok. A fair number of people have no idea how to maintain their auto or understand the mechanics of municipal transit but use it to come and go. Granted, if they're taking an intro course on how to do car repair, probably a good idea to show them how to change the oil and rotate the tires, much like an intro class to computers ought to discuss programming.

Thing is, you can teach programming to kids. You can teach auto repair to kids. Hell, you can teach quantum mechanics to kids. You just have to make them want to learn about it. Javascript isn't hard. Packing it full of complex crap, frameworks and other stuff to make it "easy" makes it hard, but by-and-large most kids can grok the fundamentals pretty darn fast. No, they're not going to be able to understand using Promises to trigger component events in the Shadow DOM by the end of the week, but i wouldn't expect that.

Give 'em two weeks.

Likewise straight HTML is delightful because it's actually nearly readable. Pretty print it and it's pattern matching you can easily wrap your head around. Heck, explain to someone that The Web® really is basically a bunch of fancy telnet calls, and it's like watching a light bulb go off.

Sadly, that may go away with HTTP22 or SPDY, s/telnet/curl/ and you're basically back in the game again.

The final thing to note about all of this is that folks will surprise the hell out of you. They're not going to follow your arbitrary rules and will pretty much use whatever you hand them as a hammer. Done right, that's not a problem.

In fact, it could be a huge benefit.

Good Sir Tim Berners-Lee never expected people to use his protocol to do face to face video chats. Heck, he wasn't all that hot on documents having things other than links, but he was willing to let folks be creative with his toy. Heck, i've built stuff, given folks instructions on how to properly use it, and they've blissfully ignored me again and again.

This is typical (regardless of my continually trying to either ignore or change it), and should simply be part of any service you build. If anything, that sort of abuse should be lauded.

So, when you're building your next toaster (or library, app, interface, device, whatever), ask yourself:

  • Is this doing the least it can to be useful?
  • Can it talk to other things easily?
  • Does this tool make zero presumptions about the user or the way it will be used?

Answering those questions will pretty much tell you how successful your thing will be.
Otherwise, you're just making a worse toaster.

1i'm not knocking jQuery as bad, i'm just saying that people have decided that jQuery is how you write javascript. Javscript has evolved and adopted a lot of the things that jQuery started. The problem is that folks immediately turn to jQuery $(".foo") rather than use local commands document.getItemsByClassName("foo"). There are good reasons to use jQuery. There are good reasons not to. Ultimately, though, you should balance the decision on what you need to do rather than knee jerk use a tool.

2It's funny how long HTTP2

:: Rules of Deployment

The following are JR's Rules of Deployment:

Note: The following may be sweary.

1) Server, then Client, then Marketing

Everyone's job is hard. So why the hell would you make it even harder by forcing folks to work on highly unstable things? First, build the back end server your thing is going to talk to. Get it to the point where it's stable, reliable, and predictable. It supports all the API calls properly, has reasonable security, sufficient redundancy and nobody is going to ask why the box is down.

Once the server is stable, then start building the client for real. You've got a reliable box and test cases you can use. Yes, there may be some additional tweaks to the server needed, but the core API should be fine enough to do productive work. Get it working to the point it's minimally viable (hell, feel free to roll it out as alpha to get some real usage models and proof the load support).

Once you've got a working client and sufficient knowledge, then you can start marketing and planning on your release, and not a god damn second before then. Yes, this means risk. It also means that customers/vendors/whoever won't be screwed because you're going to have to slip delivery dates because you forgot internationalization, or that we live in a base 10 world.

2) Know What You're Building

But, how will you be able to build a server, then client like that? Easy. You write up requirements. Not "User Stories" because i have yet to see anyone figure out how to build Integration tests off of "Bob wants a sandwich, so he presses a button on his phone and a sandwich arrives." You don't have to generate MILSPEC-25 compliant requirements that detail every action of every menu choice you're ever going to need, but you had better figure out the overall functions, interactions and compromise points before you even fire up your editor.

NASA doesn't send probes to Uranus by chucking cellphones "Somewhere. In that direction. i guess". The think that crap out because they DON'T have a huge budget and unlimited resources.

If you're a developer, demand to see the competitive product feature comparison chart. You're going to be building stuff that uses it, it's every bit a required resource as a man page. Yes, this means you can't be "agile". It means you know what the hell you're building and lets you recognize if you're making a mistake.

You will make mistakes. You will toss code, ideas and work out the window mercilessly. If you find you're incrementally redesigning your entire project, stop that project and design a proper one.

3) Know Your Critical Path

If you have a delivery date. Write it in large type on a very visible wall. You know what you're building, and the order it needs to be built in. You know that you'll need to do at least two weeks of systems testing, plus at least two weeks for patches, two weeks for deployment. Those are not things that can be done in parallel, so that's a month and a half of blocked time. You'll also need to build the damn thing, so figure your time, accounting for one additional month for every "cutting edge" or unfamiliar tech you're going to use. That IS being optimistic. Reality will probably demand more time because "cutting edge" means "broken and unsupported features" and unfamiliar generally means "you have no idea what it really does". These are common words you don't like hearing from your doctor or car mechanic so why should you want to hear them from your own team?

Lay out the critical path. Know what impacts what lays beyond it. Recite the critical path every morning in unison in the parking lot. Whatever it takes so that folks know that having a problem isn't what's bad, it's not communicating that there's a problem.

4) Build for One or Infinite

This gets into design and deployment bit again, but basically, you either need one of something, or you need an infinite amount of them. If you only need one, focus on that, and don't bother adding in clever crap. If you need infinite, build it as a service. (Again this is where "knowing what you're building" really helps.)

5) Make It Safe From Yourself

As a VERY smart paranoid security person once said: "Hackers have infinite time and resources. If there's a weakness, they will find it. If you, the person that wrote the code, can't figure out how to break it and do anything other than what was intended, hackers will have that much harder a time."

i constantly look for exploits against my own code. i sandbox anything the user has access to whenever possible. i always ensure that the owner of the server has the least amount of access possible.

6) Build Simple.

More moving parts == more things that can break.

If you're bringing in hundreds of libraries and support frameworks, you had damn well better need every line of code from them. Libraries are feature and code sinks. Very seldom are they pruned, and honest profiling can show how bad a lot of those "easy-*" or "simple-*" things really are. Be brutal about how little you need. If you're using a 10 line function out of a 2,000 line library, yank those 10 lines (and credit in the comments). If nothing else, this will let you see how crapped up those 10 lines are and if you can't do it simpler yourself.

i mean, it'll all show up in the profiler anyway.

You're running a profiler, right?

7) Document

Code is self-documenting if you never want someone else to deal with it. You don't need API guides if you never plan on someone else reusing your code. There are a lot of corners you can cut if the code is disposable.

If, however, you want to do other things with your life than support a 6 year old XML parsing library, write some damn documentation. If you're writing in some edge language, give people a reason to want to learn it so that they can help pitch in. You could write the most amazing thing ever in heavily obfuscated Perl that generates Pentium byte code and people would treat it like toxic waste unless you explained why the hell you needed to do that.

Granted, if you did that for "fun" you're an idiot and deserve to have the project rewritten on you, but that's beside the point.

Your documenting for your QA, Ops, NOC, and Customer Support groups. Even if those folks are you 2 years from now when things break due to expired dependencies.

Before you can tell someone to RTFM, you have to WTFM.

There are other rules, and if need be, i'll define those as well.
These are the core.

You're welcome.

Blogs of note
personal Christopher Conlin USMC memoirs of hydrogen guy rhapsodic.org Henriette's Herbal Blog
geek ultramookie

Powered by WordPress
Hosted on Dreamhost.