The Interesting Problems

The Interesting Problems

As a programmer I hate writing boilerplate code.  You know- the “stuff” you have to get setup before you actually start solving the problem you set out to solve.  There are a lot of code generators out that these days to address the boilerplate issue, but even then there are a lot of well-solved problems that we programmers have to solve over and over again. I wrote some time ago about the problem of inventing all of your own in-house technology, and the take-away is that there are a lot of well-solved problems.  Don’t write your own CMS system unless it offers something new and unique.  Don’t invent a new programming or data standard.  And please, for the love of all that is holy, don’t invent a new programming language. But let me flip that over and talk about what sorts of problems are worth solving.  If you work for a business, most of your problems are shared with other businesses, but a few are unique to just you.  A lot of the time, that uniqueness comes down to what you know, how you know it, and how you can show it to your customers. With that said, I think there are two really interesting and compelling problems in modern software development.  They are both related to what you know and how you communicate it. Problem #1: Big Data The problem is that no one can really define “big data.” Job descriptions for data positions are all over the board, there’s not a lot of guided coursework or certifications, and what is out there right now won’t make any sense in a...
TypeScript and the Future of JavaScript

TypeScript and the Future of JavaScript

I’m not bashful about my enthusiasm for JavaScript (can enthusiasm be bashful?).  But as many others have pointed out, JavaScript kinda sucks.  And even though ES6 (the next version of JavaScript) has features to help resolve a lot of the pain, developers can’t really use ES6 on public websites for another three to six years.  Remember, up until very recently, web developers were expected to make websites compatible with Internet Explorer 6 (Hello 2001!). ES6 is the future, and it’s here right now, but we can’t use it yet.  So what can we do as JavaScript developers to make our lives better? There are two answers emerging.  One is to write in ES6 and run it through a compiler that “transforms” it into ES5, the current version of JavaScript.  The other is to write in different language entirely, such as Dart or CoffeeScript (get the pun?), which can be compiled into ES5.  Either way, you can write run-anywhere code, but work in a language with fewer pitfalls. But not so fast!  Remember, learning a language takes time, and mastering it takes even more time.  And writing in a language that writes a language ( Dart-> JavaScript)?  That means you need to know both languages, despite any claims to the contrary. I have a pet peeve with code that writes code.  Unless it’s a commercial product, or a popular open source tool, I avoid it because it’s just too easy to write buggy code, which in turn generates more buggy code.  I write all my bugs by hand, thank you very much. Kidding aside, I recommend getting good at JavaScript before learning a language that writes...

Why Tech Projects Fail

Tech projects are hard.  If you work in the tech industry, or have worked on a tech project in some capacity, you already know this.  They are hard to get right, hard to get done, and hard to even get started.  68% of tech projects fail in some way.  Only 2% of companies regularly achieve software project success. Now that all that gloom-and-doom is out of the way, let’s take a look at why they fail, and how you can minimize your risks. Our People Matter Companies are made of people.  Even programmers are people, albeit strange ones at times.  And people are all different.  Put the right ones in key positions; play to their strengths, their ambitions, even to their egos.  But the wrong person in the wrong role can disrupt everyone else. Look in the Mirror Once you know your people, know yourself.  Take an honest moment of reflection.  The biggest marker of an organization’s software success is its business analysis capabilities.  Do you and your team have the chops?  It’s ok to say no.  That’s why there are consultants; you can “rent” their insight and competence to help you through a project.  Remember, paying for success is much cheaper than paying for failure. We Didn’t Define the Problem Technology is only valuable if it does something better than the old way.  Rewriting a 17-step manual process from MS-DOS so it’s a 17-step manual process on an Ipad isn’t solving the problem.  Now it’s a problem that employees can experience on the go! Some problems show themselves pretty plainly; things that cost money (and shouldn’t) or upset employees, things...

Angular 2 in Developer Preview

It was announced today that Angular version 2 has moved out of “Alpha” release phase and into Developer Preview.  For geeks like me, this is big news. Here at work, Angular.js has become a favorite tool.  I totally geek out about model binding, Bootstrap UI, and declarative HTML.  But I’ve been hesitant to start any new projects in Angular.js v 1.x because version 2 is so close. Angular 2 is going to solve a lot of problems for Angular developers: it will be easier to write directives/components, there will be a “right” way to write services, and even the markup attributes help clean things up.  The reason all this matters is that developers can write cleaner, more bug-free code, faster and with less hassle.  Considering the gift that was Angular 1.x, that’s saying something. My favorite things I’ve seen so far, in no particular order: ES6 (The newest version of JavaScript) support, out of the box. Tight integration with TypeScript to simplify writing compilable code. Differentiation in the markup: Square brackets [] signify expressions or properties. Parenthesis () signify event listeners. The pound/number/hash symbol is used as a reference- particularly handy for iteration. Asterisk can be used for flow-control directives like “for.”  Combined with the # sign, it would look like: *for=”#name in names” Scope isolation! Transclusion is being retired. Shadow DOM and performance improvements. Data-binding can be once, one-way, or two way; this can contribute to performance and clarity of code. Of course it’s not all clear sailing.  There are still a lot of questions, clarifications, and complaints.   The Angular team is taking a big leap with this new...
The Big Day

The Big Day

Today is the big day.  Not daylight savings, or tax day, or even my birthday (send presents, because you just missed it).  No, today is the day Google is making their big algorithm change to favor “mobile friendly” websites. If you’ve been paying attention, you might be ready and it’s an exciting step forward.  If this is news to you, don’t panic.  We’re here to help. What it Means “Mobile friendly” is a pretty broad term, but Google are focusing on usability.  From their post last November: A page is eligible for the “mobile-friendly” label if it meets the following criteria as detected by Googlebot: Avoids software that is not common on mobile devices, like Flash Uses text that is readable without zooming Sizes content to the screen so users don’t have to scroll horizontally or zoom Places links far enough apart so that the correct one can be easily tapped A follow up in February says: Starting April 21, we will be expanding our use of mobile-friendliness as a ranking signal. This change will affect mobile searches in all languages worldwide and will have a significant impact in our search results. Consequently, users will find it easier to get relevant, high quality search results that are optimized for their devices. Reading between the lines, it means that your traffic will be impacted one way or the other. Who Needs to Change Google has released a mobile-friendly test tool to help you analyze your home page.  It only analyzes one page at a time, so it can’t analyze  your entire site in one pass.  What it’s good for is getting...
Non-Violent User Experience

Non-Violent User Experience

I recently had solar panels installed on my roof.  I could write a lot about the experience and what I learned, but one thing in particular stuck out: the folks who built the computer that controls my solar array have a totally different understanding of user interactions than I do. In my work life, I am in a world of web browsers and mobile devices: there are clicks and swipes, navigations and refreshes, logins and authorizations.  If you think about it, there’s a lot of imaginary stuff going on in the world of web and app development.  We expect that the user is going to interact with subtle and controlled gestures, and the computer or smart phone will respond with a something that “feels” like a real world reaction.  Try rotating your phone while browsing, or even just scrolling on it: the page moves as if there’s inertia.  Someone did a lot of math to get that imaginary inertia to appear natural. So imagine my surprise when I learned that the way to wake up the computer on my solar array is to hit it.  The conversation with the installation tech went something like this: “If the screen is blank, just hit it.” “You mean, like a button or something?” “No, there’s a symbol down there that shows you what to do.”  He pointed at an icon of a fist with an arrow pointed toward a box. I examined the icon, pushed it with my finger tip, and he interrupted, “No, like this,” and punched the screen with his fist.  It lit up merrily and provided a read-out of system...