Material Pompousness

I have a minor in Graphic Design and for quite some time UI/UX work was my bread and butter. My work was well appreciated, got me accolades and I enjoyed doing the work for a long time. I even focused on UI/UX in grad school. However, these days I'm much more at home doing things like security work where if I make a mistake I could only cost a company millions of dollars because and I mean this with total sincerity, it's so much less stressful.

What got to bothering me the most about design work is the pompous language that made me feel like I was being talked down to or I would be talking down to someone else if I used the terms. "Meaningful Transitions", "Material Response", "Consistent Choreography". To my ear, these are phrases that are to sound good and make the speaker sound savvy. Now backend work has issues too with non-words like "performant" but they don't seem to crop up as often there. But no matter where they occur to my somewhat jaded mentality after being in industry for over a decade, I'm prone to dismiss the speaker as someone who knows jargon on hearing these words and phrases. And they may know what they're doing too but, outlook not so good.

In industry these days I often feel my expectation for professionals to know their tools, to talk to each other like professional peers and break new ground to solve problems or create a distinct identity in design is wanting too much. Indeed, making websites just another user of Twitter Bootstrap seems fine for many. B-U-T I look at those sites and I see the next generation of the the I-barely-know-HTML-but-I'm-building-a-website-anyway sites from geocities. I didn't give them my money back in the day, and I don't give these new websites my money today either.

Hello, We're The Doctor

I've heard it said in places that in the long running TV series Doctor Who the companion is there to give the viewer someone to identify with. However, I do believe that this particular assessment would be best inverted.

We are all the lone expert in our own lives, carrying out our days much like how The Doctor bangs around the TARDIS. Thanks to this expertise, to our companions or to any onlooker for that matter, seeing how we conduct ourselves in our daily lives may be outright mystifying.

For us, our companions are those friends and family whose lives and ours get to intersect for a while. But we ourselves, is the only one who is guaranteed to be always there. The constant. The one that we the viewer can identify with, The Doctor.

Technologic Turbulence: Familiarity and Usability at 5,500 ft

When I got my Private Pilot license in 1996 piloting a General Aviation aircraft was a manual and cumbersome process. The radio was nothing more than a couple of seven segment displays with knobs and a toggle button for activating a frequency. There were paper charts and paper airport directories. I remember one time I was on a long flight during my training and my window popped open on me (the planes I get to fly are typically knocking on 40 years old. They're safe but, they've got quirks) sending my charts and paperwork whirling in the cockpit! Now in 2015 there's not much risk of my charts being set to the breeze as my old paper charts and airport directories have been replaced by an app on my iPad. The radio is now also a monster GPS contraption with knobs that are actually buttons too and there may or may not be a touch screen. Make no mistake, the value in this new technology is clear to me. But by golly learning this technology was the most overwhelming part of getting back in the cockpit for me.

Outside the cockpit between 1996 and 2015, I was adjusting to technology weaving itself deeper and deeper into my, and really all our daily lives. Cellphones got smaller and smarter. Dial-up local Bulletin Board Systems gave way to high speed Internet and we all got on-line. In 2010 when I came out to the Twin Cities to look for a place to live, I bought a street map from a gas station so I could get around. Now, and for a few years already, there's an app for that. I was never really jarred by the new technology. The "That's cool!" factor tended to carry the day more than anything. Then I decided to fly again.

Adjusting to the technology in the cockpit disrupted every aspect of my flying. I was learning to use an powerful and wonderful yet complicated app to access information while relearning how to perform as a Pilot in Command after 19 years. For navigating, yeah I could look down and try to match a lake on my map in my app, but I was encouraged by my instructor to get to know the GPS with the less than lovely user interface. Imagine for a moment taking one of the most frustrating and unintuitive apps or websites you know, and having to rely on that to tune your radio so you can talk to a control tower. Then having to use it to find the navigation features you currently need amongst the collection of 12 other functionalities the thing has that are labeled with cryptic symbols, if at all. While traveling 5,500ft off the ground. While needing to make sure you don't put yourself in airspace that you're not cleared to go. While keeping your eyes open for other air traffic.

In that moment up there, I was that "dumb" user to those who are savvy with the technology by virtue of growing up with it and being in it all the time. I've done usability testing, and I've seen users struggle with designs I thought were the easiest thing ever and I learned from that. Adjusting to the technology in the cockpit gave me the experience of being that user!

I did adjust to it and I got my savvy, though it was a lot to take in. And no one can take my technology in the cockpit away from me now either! It's mine! 🙂 My devotion to the difficult technology comes from back in 1996 when I was flying from Green Bay to Woodbury, WI to have my practical exam, cause I got lost. Below me all I could see was trees, trees and more trees. Well, there was this cloud of smoke on the horizon. I called the airport on the radio and hoped that the cloud would act as some reference for them to help me figure out where I was but nope. They had no idea what I was talking about. I didn't panic, I found some matching shapes on my chart to the land sprawling out below me and I found my way to the airport and proceeded to pass my exam. Today, on getting used to the hard to use but gosh golly is it useful technology, I can't imagine my getting lost story unfolding for anyone.

I want to take away how much that technology in the cockpit shocked me. As a Software Engineer I don't get many experiences of being a non-power user when it comes to technology. This experience is a opportunity to remember that what's easy for me, isn't necessarily easy for all. May my experience of wrestling with technology at 5,500ft help me remain mindful of keeping a plan for everyone. 🙂

Having a Complete Lack of Style is a Good Thing

In this era of open source projects I'm more than a little surprised that official code styles still exist at companies. After all, on any given day I or any developer could find themselves diving into company code, AngularJS's code, Bootstrap's code, or any one of the innumerable third party libraries that end up in code bases these days. With all these differing contributors we developers can and do end up plumbing through a wide array of code styles thereby making adhering to one style for one part of the code nothing more than busy work. With consequences.

Through the ether I can hear an argument for, "I can tell what code base I'm in by how it's written,” and I don't care about that. I also think we'd be better off as teams if no one cared. Remember, all code in your project is you and your team’s responsibility whether it came from someone in house or is something off of GitHub or even if it came from a StackOverflow post. I would hope and expect a professional developer to be able to read the code where ever it came from and the casing of variables or where they are placed will be of no consequence to their ability to perform their job.

In all my 12 years of doing professional development, the only thing that style guides have ever really been good for taking the teeth out of code reviews. With style guides, the focus of code review observations often become about how something is or isn't commented per the style, or variables don’t have the right naming convention per the style or something else inconsequential is out of place per the style and what's missed is (true story) the code itself doesn't even compile because the author coded foo("bar", , 42);. That function with a missing parameter made it through review I’m sure in part because the code around it looked up to style. Company style guides are a distraction of low hanging fruit for developers to grab and "contribute" to the project instead of doing a service to the code by picking it apart and looking for actual problems.

Then there's blindly following the guide because "That's what we do” and at this time I find myself at a great point to bring up goto. Early on in my computer science education I learned we don't use goto. It's bad bad bad and so we just don't don't don't. I followed that guidance blindly for years until rather recently I saw some sample code from Microsoft. In it goto was used to skip creating additional COM objects when the initialization of one of the required objects failed. By skipping, the goto brought the flow to the cleanup of the objects that had been made. Well that's a great use! Why run code that doesn't have a chance at succeeding anyway? Sure there's other ways to deal with this type of failure but my point here is, the goto based solution was valid.

Edit 5/27/16: I had something here about just needing well organized code but I've had to admit to myself that my motivations for well organized code were misguided. I had also said you didn't need meaningful variable names cause I was waxing academic so I'm going to change that stance to for corporate code, ya need rare strings for quick grepping. Origination to the point where a rare string can be searched for in 1 second or so affords decent productivity. With as fast as machines are today, that leaves a lot of latitude to conduct development which remains good cause in doing so, you may find yourself learning new tricks from others by way of freedom of expression! 🙂

Forgiveness and Tolerance: Great for People, Not so Much for Software

Despite being someone in technology I tend toward minimalism with technology because I, like many, believe that most technology doesn't work and the pro-ported benefits technology typically isn't worth the extra complications it brings.

Really consumers of software need to complain more to the authors when the programs/websites/apps don't work or are buggy or are hard to use cause issues are all over the place. Instead, as I learned in grad school, users will typically blame themselves for not understanding how to use hard to use software. This behavior by users allows Software Engineers to be like weather folk: We can be way off, but we will be forgiven time and time and time again.

To the people of the Internet and beyond I say: It's not just you. It's the software too. Blame us. Help us, make us, help you. After all, without your input we have no idea what we're supposed to be doing for you! 🙂

We Can't Even Write for Loops Anymore???

In C# I like and use LINQ so the idea of using something to extend my abilities in iterating over enumerables is not foreign to me. And typically I do gravitate toward a foreach loop for some, basically, syntactic sugar that keeps me from having to use an indexer. I've also never in 12 years had a problem reading an indexer as part of something being iterated over a for loop. If I had to do something with say parallel arrays, I'd probably be inclined to use a for loop there vs. LINQ. Or if I needed finer control over the enumeration, such as say parsing command line arguments. In that case, my work history has made me someone who likes to not like to cede control to some helper and I've never had a problem reading an indexer. Or writing indexers where needed.

So in JavaScript, why did I find myself getting so opposed to changing a for loop to use a third party library? Something that behaves like LINQ, which I again, do use?

All I wanted to do was find the first instance of a key in an array to look up something in priority order in a hash. So I wrote what was basically:

for(var i = 0; i < keys.length; i++){
     if(source[keys[i]]) {
          return source[keys[i]];
     }
}

return safeFallback;

I guess an alternative would have been something like:

var result = keys.findFirst(function(key) {
     source[key] !== undefined;
});

if(result) {
     return source[result];
}

return safeFallback;

Which is "better"? I guess the double ]] indexer in the first isn't esthetically pleasing but is it wrong? More difficult to maintain than a function callback? I'm sure some would say so. But for they like me, their answer is their opinion.

As a contractor I do aim to yield to the opinions of those that work at my contract. I missed that today cause I didn't identify a .findFirst style method before I ran out of time. :/ Kicker is one came through in a code review I looked at. That my answer was staring at me in the face just didn't click. Had it, I'm sure I would have changed my code.

There is something about surrendering a basic thing like looping to a third party library as a rule that bugs me. Writing this I do think some of my hesitation is due to when I interview people, I like to ask LINQ questions cause if you don't know what you're doing with LINQ you can really easily write lousy performing software.

foreach(var item in collection) {
     var foo = usesItemAsIndexer.ElementAt(item);
}

I've seen something like the above in production code and performance has a bad time because of it. So, yeah, how does that findFirst method I called above work under the hood?

Given that a for loop is so basic and fundamental to programming, I think it being so should count for some ease of use and maintainability too. So in the end, because it was a big deal to my client I do wish I'd found a way to convert the loop. For me, I'll never complain about such a thing and use a for loop in my own for me work whenever I like. 🙂

Reinventing the Wheel, Iterating the Wheel

When researching how to solve a given development problem, I often find posts online that say, "You want to do thing? Well I have written a library to do thing! Just use my code, don't reinvent the wheel!"

I don't know how other devs react to that. Me? I'm  a, "I'll take a look at your wheel" kind of gal and will proceed to strip said wheel down to figure out how it works. I might not need your whole wheel after all, I might just need a spoke. Or, I might find a good seed to iterate on which I will then go ahead and plant in order make something new grow. Both of which I gather are idealistic points of Open Source software.

In the face of deadlines and getting developers block, I don't know how often that ideal is achieved. I do think it's important to try though. That way ya get to expand your knowledge by figuring out how something works and discovering how others solved a problem. Along with developing a healthy, reason based distrust of content on the Internet. 🙂

Not News

If step one of some new computer attack is, "An attacker first needs administrative access to a machine." it is not news. How they got administrative access might be interesting though.

Self Vs. That

In order to make sure I'm referencing the intended JavaScript object I've always set self to equal this:

var self = this

I've recently seen that used instead of self. I know why we need a way to keep a reference for this. I don't know why we have to have this = self = that. Objective-C already has self as this.

Why did we have to introduce a third word?