Trust yourself, trust your skills, trust your tools.

By nature, any programmer who has worked for any decent amount of time is going to be gun shy about a lot of things.  We say “probably” a lot,as well as “most likely” and “should”.  We’re not comfortable saying yes, is and will. Because things which we were sure of have at some point not been sure.  Some of this is because the people in business that we are coding for look at things differnently than programmers.  We might say, “So, what you are saying is that orders which are delivered are never picked up by a customer?” And the business people nod and say yes, and are glad you get it. So you go back and you make a couple of kinds of orders, ones which are delivered and ones which are picked up by the customer, and over time logic is added to these that are based on those facts: delivery and pickup, and all is well.

Then one day the business people have a problem, see sometimes when an order is out for delivery, the delivery person gets abducted by aliens, and then the customer might want to come and pick up the order instead of waiting for the delivery person to be rescued or replaced by autonomous drones.And now none of it works anymore, and the programmers are mad because the customer said this would never happen, and here it is happening all over the place all the time. And the business people are confused because they were really just talking about a rule that applies 90% of the time.

And over time, programmers learn to be a little bit scared of absolutes, they lose some of their trust of the world being an orderly place (well it isn’t, after all:) and it changes the way we think.

There’s a classic joke:

Three Americans, an engineer, a physicist, and a programmer were all on a train in Scotland. They looked out and saw a bunch of white sheep. The engineer looks out and sees a black sheep. “There are black sheep in Scotland!” he says.

The physicist looks out and says, “Well, there’s at least one black sheep in Scotland.”

The programmer looks out and says, “There’s a sheep in Scotland who is black on one side.

This is okay behavior at one point, but it bleeds out into other things. I’ve seen a lot of good, senior programmers who were scared of their shadows. Anything new was looked at askance. Anything that works differently is inherently dangerous. That, unfortunately can get in the way and lead to inefficient code. This is really true when the technology is really fundamentally different than the one you are used to.  In the case I”m thinking about it, it’s a C# programmer writing code in JavaScript, and just not really being comfortable.  That’s my read on it anyway, and reading code is a lot like reading the mind of the person who was writing it.

We’ve got an iPad app that is writing with Backbone.js, and is a giant mess of complicated JavaScript. Part of my job is to maintain it, add features, and clean it up where I can.  It’s a product that has many implementations and customers, so there’s a product level config that gets read in. Now, product A was created before Feature 1 was created. Only customers who pay for Feature 1 to be incorporated in the product, get that feature, but it’s part of the base code. (There is, I think a better way to have implemented this in the build process, but that’s not what I inherited).  The app object (which is a global javascript object) loads the products config and runs through a process that turns on and off the features of the product, based on what is on.

    var featureOne = app.product.config.hasOwnProperty("FeatureOneFunctionality") ? 
                           app.product.config.FeatureOneFunctionality : 
    this.featureOneIsOn = featureOne ? true : false;

Um, okay? I mean, it passes the first test of code, it certainly works. It’s mostly okay. But it shows some fear. What’s a better way to write this code, and have it do the same thing?

        this.featureOneIsOn = !!app.product.config.FeatureOneFunctionality;

Some days I’d drop the “!!” off the front, but that forces it to boolean, which is needs to be. Odds are if it’s set it’s true or false already, so the only other value we’re going to get is undefined and !!undefined is false.

But, in C# if you referred to “app.product.config.FeatureOneFunctionality” and it didn’t exist, then that throws an error. It probably won’t compile, even. in C# the product config page would inherit from a standard one, when you add a feature you’d add it to the parent object, with a default value of false, and you’d be done. You could do this with JavaScript, but that kind of inheritance isn’t really right either, and could potentially break this code.

My guess is that this lack of trust of JavaScript is why they are calling Object.hasOwnProperty. Of course, if the config file ever were inherited like you would do in C# all these hasOwnProperty calls would fail. Because Object.hasOwnProperty is asking does this Object have a property named X which is defined on this property and not on its prototype? If an object has a “FeatureOneFunctionality” property that it got via prototypal inheritance, and wasn’t set, it’ll return false. As long as falseis our default, this code is okay (as it defaults it to false) but if we ever had a global feature that defaulted to true, this would cause it to be falseinstead.

There are other ways to check if an object has a property or not, that don’t depend on Object.hasOwnProperty, but that’s neither here nor there. In this case, it’s just a value property, and it’s a boolean. Not having it means it’s false. Pretty straightfoward.

And never mind that ternary operator later. That was also elsewhere in the code, where two variables were compared, thusly:

    var showThing = showITMode == "showIt"? true : false;

And this is also a lack of trust, either in themselves or in the code. Why not just this:

   var showThing = (showITMode == "showIt");

I added the parentheses because it makes it clearer to the next person than what it would look like before. It’s no more necessary than the ternary operator, but there’s a reason we call that the “obfuscation operator”.

This is part and parcel of the attitude I’m dealing with at work. JavaScript is seen as a scary thing without rules or logic. So we spend a lot of time writing rules around what you can and can’t do with it, and it takes the power away form the language. JS’s truthy and falsey values are weird, but understanding them can help you write cleaner looking, easier to reason about code. Closures and lexical scoping are hard concepts, but can help you get rid of this and the complications it creates. [this is one of those examples that drives OO programmers from type-safe languages nuts. The idea that this can change based on where and how a function is called? That’s foreign and anathema to them. I’m not a huge fan of it either, but that’s a later article]

Just a note that this example does not come directly from work code. It’s an amalgamation of things that are in the code, which is why it might seem worse than it is. This is code that’s running out in the wild and doing its job, it’s just not pretty, and doesn’t pass the second test of code: easy to read and reason about.


The last post on this site before this one is from almost three years ago.  At the time, I was working as a temp for a web development and marketing company. About half my time was spent implementing WordPress sites. I worked on the Ohio Lottery page redesign, mostly implementing from the graphic designer’s photoshop file. I was pretty proud of my skill then, and it is pretty good — it’s pixel perfect to what the designer did on all the browsers of the time.  Today, just saying “pixel perfect design” sends a bit of a shiver down my back, because we can’t predict much about the user’s world except that we aren’t really sure what it is. As developers often say, “If I did it today, I’d do it differently.”

The other half of my time was spent working on digital signage.  That it, we’d sell you a TV screen, and a small (but powerful) computer, let you design what goes on your screen in the cloud, and do the magic that puts together the videos, events, tweets, and other content you want to appear on your screen. We had a product written by another company, tied to windows which worked fine, but needed more features. The vendor was a windows company, and we were more mac/open source focused. So, given that and the fact we couldn’t afford more from our vendor, we rewrote it in javascript, using node. Eventually the whole thing dumped on my lap, and then two months later, we were bought out by our vendor.

I got a full time job, and in the intervening time, my node javascript code has been pretty much retired in favor of the vendor’s (ie, our) C# solution.  Well, we’re the whole company now, and of the dozen or so developers, I’m the only one who doesn’t like C#. It makes me feel about the same way as “Pixel perfect design.”  Can I write it? More or less, it’s not that different than anything else, and there are clean ways to write things, and mostly all we’re doing is what I used to do in PHP, which is shuttle data from a database to a web page.  And I’m way way more comfortable on the front end of this, taking data, and making it into interactive web sites.

That part of my job hasn’t changed greatly — the signs we made were HTML5/css/JS things, often interactive, with maps and events and lots going on in some cases (less in others). It was all, for me, ultimately just providing the best user interface possible. I wrote a video game (a two player video game, in a single browser –that was a challenge!), we put signs in every major rest area in Ohio, connected by unreliable 3G mobile phones, but still had weather and news that was kept current. If I did it today, I’d do it differently.

I’d still choose JavaScript and node as my middleware (and possibly back end).

Twenty years ago, turning off JavaScript in my browser was just one of those things I did, like turning on file extensions in explorer, and moving my Windows toolbar from the bottom to the left. (I’m not the only person I know who does this;)  A decade ago, I was starting to really like JavaScript. At the county, I wrote my first AJAX, and used my first MVC Framework (CakePHP). At my last job (which is sort of my current job) I learned WordPress, and Node, and my happiness with PHP finally wore off. I’ll never be a hate of PHP, it has its place (and this is a wordpress site, for now). ut JavaScript? Well I’ve lived with it long enough that I’m starting to get to know it.

Being at a company with such a strong C# has actually made me care more about my JavaScript. I’ve learned that I, personally, don’t like strongly typed languages. Our C# code has some beginnings of the kind of stuff I saw in Java a decade ago.  Lots of nouns. Things that did things to themselves, but only in this one way. If you wanted something different, make another. A few weeks ago, I wrote an app that made use of a full service layer. Matching the patterns set by my co-worker (because this is what you have to do in a professional environment) in order to add four operations on a table: Edit, Save, List, and Set Password (it was a user table), required creating a dozen files, and editing 3-4 more. (This includes the controller getting the data, but not the models and view models I was using).

That code, for the large part, was cut and pasted from another sequence of code. I don’t know why we do it this way, I know it’s been like that for years, and to change this pattern is more than I can do.  The thing is, I don’t really understand it deeply. I know what each piece does. I even understand why we’re using a service later on this project. I don’t understand why it was implemented this way. I do understand that every programmer at my work understands it enough to implement it. The code, in large part because it doesn’t do much, is clean. It’s easy to reason about what it does — just not why.  (And I’m very happy with “easy to reason about” as a definition of code which is good enough.  Good enough code is what we’re shooting for here.)

On the other hand, I’m starting to see the Ossification of classes that came with Java. And the “this is the way it’s done best practices blah blah blah” speech that goes with that. Maybe you’re happy with that, but I could write the SQL queries to do my 4 things in about 10 minutes. (And writing them, as stored procedures was part of the task).  That gets me the data. Another half-hour to pass it through my service layer in any reasonable system (and Javascript, being typeless can handle this pretty well, one JSON string is pretty much like any other JSON string)  Instead,I sent 2-3 hours writing (copying) rote code, and then another hour going through and fixing all my syntax errors. Every line of code, every file added to implement something adds syntax errors. I’m not a perfect typist, and I’d be worse without the Intellisense in Visual Studio (then it would probably take me another 2-3 hours to fix the syntax errors instead of one). By the time I’m done, I have this byzantine thing that works, and I’m mentally tired, and I haven’t made anything that does anything much.

It’s huge, complex and it feels like gears that don’t do anything. I get the feeling that I could probably simplify this by having all the models implement an interface, and having all the service stuff implement an interface, and then the number of files I need drops in half or more. Everyone implements the same basic interface, and even the controller code is simpler. But it’s far far too late in this project for that. But all this type safety and structure makes someone happy, I think. It just isn’t me.

I read through the code that has been written by some of these C# people – people of intelligence and capability whose C# code is excellent, and I marvel at it a bit.  The amount that they try to shape it into C# is where it becomes crazy. JavaScript is not C#. It’s not strongly typed. And most very importantly JavaScript isn’t and Object Oriented language. Stop trying to make it work like one. (React.js does this some, the way that Backbone is implemented in on of our projects really wants to be OO).

I’m not saying you can’t do this with JS. ES6 has added the keyword class. But just talk to someone who’s done more than a few months of JS about lexical this and scoping. JS’s this does not work like any OO language ever. Even PHP is clearer on $this.

And I feel like I’m starting to get it. I write JS code, I listen to people who know JS online, and I find my code is like theirs. My code is nothing like the code I wrote a year ago, or even a few months ago. It’s better, and simpler in a way that I can’t explain.  I think I’m starting to get this.

Want to know how much I think I get it? So much I know how little I get it, that’s how much.  And it’s that learning and the experience I’m getting (and the fact that I’m working harder and better than every before) which is why this loosely typed, open source guy is working at a windows/C# shop. So long as I keep learning what I want, and keep getting better, I’m going to stay. Because Mastery is of the primary things that motivates me. (It’s more important than Authority and Purpose in the MAP style, at least for work).  I don’t think I’m the only programmer like this.

One of my goals this year is to extend my Mastery of what I love in code. Primarily this is JavaScript, but it’s also everything in the Human Interface sphere. Graphics tools, animation, responsive design. In the past few months, I’ve gotten a good grounding of Adobe Illustrator and that’s made me more productive than anything I ever knew about Photoshop. The most recent project has gained me kudos at work (and from the customer) for it’s look and feel. It’s simple, and most of my work has been in picking tools, and parts of tools that most cleanly express what the customer wants. But that’s the job, and I’m feeling good about it.

This week I talk to my boss about all of this, and where I’m going. Because I am a bit of an odd man out at work — my skills are needed because not everyone has them, but they also mean I don’t ‘fit’ in the way I could. I like my job, so let’s deal with it while it isn’t a problem. This is also something I’ve never done. Maybe I’m mastering this too.