I’m taking a break from the Alexa tutorial this week. I wanted to talk a little bit about software development careers. As I mature, I find that I am less drawn to the idea of being a technical expert. There can be a lot more to a fulfilling software career than being the expert in Java or C or the technical aspects of the job. Just solving a problem or fixing a bug was a good day. But now, working with others to create a productive team and having a satisfying experience at work are much more important than they used to be for me. I still enjoy the technical things immensely, but I also like helping a teammate figure something out or helping another finish a task. One thing I really started enjoying is helping a younger developer see things in a new light.

Most young developers I talk to enjoy the technical stuff and problem solving, ut they forget that there is more to life than the job. I don’t mean that they don’t have outside lives, I mean they don’t have any real balance or boundaries. It’s like they are the job. Everything takes a back seat to the job. They willing drop what they are doing to handle a work issue. Please young developers, don’t do this. This may sound like an old developer who no longer wants to sacrifice having a life, and yes, I don’t want to sacrifice my life, but I want young developers it’s wrong for the employer to be that demanding of your time.

You are not the owner of the company, to expect that you should throw away portions of your life for the sake of a company that you don’t own (.00001% of stock ownership doesn’t make you a company owner). Yes, you won’t climb the ladder as quickly, but don’t succumb to the pressure of doing everything the boss wants you to at any hour of the day. Do your best to resist the 10 minute weekend task. I know I still do it, but I’m sure there are tasks that take 10 minutes during your personal time that you will do as a “favor” to your boss. Try to do them as little as possible and make sure that your boss appreciates that you are doing a favor. That this is not normally something you would do. Couch it with something like you are out and that when you are able you will do your best if you have time. You don’t have to go too deep, but just let the boss know that you have a life and that you are living it and that this favor is intruding on it.

You then have to do work at work. You know all this personal time stuff the job allows you to do at work. It’s a trap! They want you to blur the boundaries. They want you to not know when to shut it off. If you can’t shut it off then you can’t refuse when they come knocking during your personal time. Hey, you used company time to do personal stuff of course we can intrude on your personal time to do company work. See that trap. Just do work at work. If you have to break up your work day to do a personal task, go ahead I don’t see a problem with that. Just make sure you have a defined split. If it mixes, there’s no defense against them taking your time. You know all those “perks” at work? Where are they? At work. Wait now, when am I doing work stuff? When am I doing personal stuff? Oh I better do work stuff at home since I did home stuff at work. What?!?!? Hours don’t matter it’s what you accomplish they say. Well that sounds good until you ask how many hours it takes to produce what is expected of you. Have the conversation with your boss. Know what’s expected. If you don’t have the conversation you could work and work for hours and not know if you are under or over delivering. Just find out.

Finally, don’t regularly check email during non-work hours. You know all the things about email killing productivity. Well, it will kill your personal life as well. What are you doing with work email on your personal device? What is that? I get mad when I see that. Unless that’s in the job description, stop! If your job is to be on call or on “pager duty” than sure. But if you have a regular feature development software development job I see no reason to regularly check your work email outside of work. If your bosses want something done they should be asking for it during business hours. Their whim or fancy at 10:30PM on Saturday should have no bearing on you until monday morning when you start your day. What can you do if this is expected behavior? Well, first don’t do it just because everyone else is. That’s bad culture. Just like the time boundaries, have the conversation with your boss about communication boundaries.

Why am I writing this. My impression of Silicon Valley is that this has somehow become the norm. It seems like every big company doesn’t know what boundaries are. I think their customers have come to expect blurred boundaries. I mean every SaaS customer expects 24/7 service. So every company seems to expect 24/7 employees. I don’t think the culture has had an actual conversation about this. Bosses just saw that they needed employees to support the product at any hour so the expect employees to do their job. Well I’m guessing in most cases it was never negotiated that this was part of the job. Really what I’m asking for is a conversation. Employees, please have these conversations with your managers. Ask about expectations for off hours work. And clarify how you will be compensated for work outside the norm. If you are up late working on a presentation, is the presentation your job and it was your fault that your up so late? Or is it something that got thrown at you last minute and now you have to go above and beyond because of mismanagement?

The code for the Skill is written in JavaScript and uses npm to manage package dependencies. The ask-sdk-core and ask-sdk-model packages are included when we ran ask new.

lambda/custom/index.js

I’m going to break up the explanation of the code so I can explain it in a digestable fashion.

Let’s start slow. First, I import the ask-sdk-core.

const Alexa = require('ask-sdk-core');

I use the ask-sdk-core when I register the intent handlers (described below). The skillbuild.addRequestHandlers() registers handlers for launch, help, cancel and stop, session end, and the non-built-in Hello intent.

const skillBuilder = Alexa.SkillBuilders.custom();

exports.handler = skillBuilder
  .addRequestHandlers(
    LaunchRequestHandler,
    HelpIntentHandler,
    CancelAndStopIntentHandler,
    SessionEndedRequestHandler,
    HelloIntentHandler
  )
  .addErrorHandlers(ErrorHandler)
  .lambda();

Anatomy of an Intent Handler

The intent handler requires two functions canHandle(handlerInput) and handle(handlerInput)

const LaunchRequestHandler = {
  canHandle(handlerInput) {
    return handlerInput.requestEnvelope.request.type === 'LaunchRequest';
  },
  handle(handlerInput) {
    const speechText = 'Welcome to the Alexa skill for Shepherd of the Valley Lutheran Church.';
    const repromptText = "Say hello."

    return handlerInput.responseBuilder
      .speak(speechText)
      .reprompt(repromptText)
      .withSimpleCard('Hello', speechText)
      .getResponse();
  },
};

The canHandle(handlerInput) function returns true for all the request types it handles. In the case of the LaunchRequestHandler it supports the LaunchRequest request type. The handle(handlerInput) function is the actual response to the intent. The function shows how the handlerInput.responseBuilder function is used to build the response. speak takes a string that is the text of the response. reprompt takes a string that will be used to further the conversation if there hasn’t been any interaction after 8 seconds.

There are two other types of requests I’ll be handling in this tutorial and they are IntentRequest and SessionEndedRequest. SessionEndedRequest is used to cleanup any state we need for the session. I’m not sure there will be much to it as I don’t know if I will need any state for this Skill. I will explore IntentRequest in the next post. It will be used for some default intents, but it is also the mechanism used to do the interesting, custom parts of the skill.

Please send me (brian@yamabe.net) any comments or corrections.

This is the first of a series posts in which I will be building an Alexa Skill. I haven’t pre-written this series, so I don’t know where it’s going to end up, or even the exact steps that will occur along the way. What it will be is something closer to how development would occur in the real world as opposed to a sanitized tutorial.

The skill I’ll be building is one for my church. It will let users ask for the time of the next service or event. You can also ask it for the church address and phone number. And we’ll see what other interesting things we can add. If you dislike church’s for some reason, feel free to substitute your favorite civic organization :wink:.

Getting Started

Here are the prerequisites for the tutorial:

  1. An AWS developer account.
  2. You know or can follow along when explaining code in JavaScript.
  3. You have Node.js installed. Let’s go!
  4. If you would like a tutorial for configuring the environment from scratch, let me know. I’ve found this information easily enough with Google that I didn’t think I needed it here. When I write a complete book, I should probably include it (right?).

Install the Alexa Skill Kit Command Line Interface (ask-cli)

npm install -g ask-cli

Initialize the ask-cli

ask init

Create a new skill with the ask-cli

ask new -n sotv

skill.json

At the top level of the project, a file called skill.json is created. This file contains the skill manifest (Skill Manifest API) and is the JSON representation of the skill.

{
  "manifest": {
    "publishingInformation": {
      ...
    },
    "apis": {
      ...
    },
    "manifestVersion": "1.0"
  }
}

The publishingInformation object describes how the skill is presented to end users in the skill store or Alexa app. The supported locales, description, category (list of categories), and other information is contained as shown below.

...
"publishingInformation": {
      "locales": {
        "en-US": {
          "summary": "Sample Short Description",
          "examplePhrases": [
            "Alexa open hello world",
            "Alexa tell hello world hello",
            "Alexa ask hello world say hello"
          ],
          "name": "base",
          "description": "Sample Full Description"
        }
      },
      "isAvailableWorldwide": true,
      "testingInstructions": "Sample Testing Instructions.",
      "category": "EDUCATION_AND_REFERENCE",
      "distributionCountries": []
    },
.//

The apis object describes the HTTP endpoint that processes the intents that the skill supports. The apis object shown below configures the endpoint to be an AWS Lambda function that is defined in the lambda/custom directory of this project.

...
    "apis": {
      "custom": {
        "endpoint": {
          "sourceDir": "lambda/custom"
        }
      }
    },
...

The manifest can also contain (privacyAndCompliance)[https://developer.amazon.com/docs/smapi/skill-manifest.html#privacyandcompliance], (permissions)[https://developer.amazon.com/docs/smapi/skill-manifest.html#permissions], and (events)[https://developer.amazon.com/docs/smapi/skill-manifest.html#events] which you can read about, but aren’t used yet in this project (if we do end up needing any of them I’ll describe them at that time).

models/en-US.json

The models/en-US.json file contains the Interaction Model ((Interaction Model Schema)[https://developer.amazon.com/docs/smapi/interaction-model-schema.html]) of the skill. The languageModel defines the interactions that Skill supports. The invocationName is the set of words that activates your skill. My Skill is for my church, Shepherd of the Valley, so I went with s.o.t.v. which will open my skill when you say something like, “Alexa, open S-O-T-V.”

Under the intents section are the intents your skill will respond to. I didn’t list all the built in ones, but they are AMAZON.CancelIntent, AMAZON.HelpIntent, and AMAZON.StopIntent. The first non-built-in intent my skill will support is the HelloIntent. The samples is an array of phrases also called utterances. These utterances are what will activate the intent for that skill. For example, “Alexa, tell S-O-T-V to say hello.”

{
  "interactionModel": {
    "languageModel": {
      "invocationName": "s.o.t.v.",
      "types": [],
      "intents": [
        {
          "name": "AMAZON.CancelIntent",
          "samples": []
        },
        ...
        {
          "name": "HelloIntent",
          "samples": [
            "hello",
            "say hello"
          ]
        }
      ]
    }
  }
}

That describes the definition of the skill. In the next post, I’ll walk through the supporting code.

I’m still a fan of AWS as I believe it is the best enabler of independent web development. You can complain about lock-in, but developers can create sophisticated applications using just the pay-per-use services and experiment with solutions without much up front cost.

One of the services that has received a lot of attention lately is Amazon Alexa. The voice service allows developers to create “skills” which extend the capabilites of Alexa and what it can respond to.

At the beginning of the summer my youngest daughter wanted to experiment with Alexa. She had the idea that she wanted to be able to ask it for puns and jokes. Of course Alexa already has those built in, but my daughter wanted specific puns and jokes that she likes. Summer came and is almost gone and with vacations, camps, and new jobs we didn’t get a chance to develop anything, but she still has the desire to build something.

As a geek dad I have to help her learn how to build this thing. So my learning and documenting project is to gain a deep enough understanding of Alexa Skill development to be able teach her hopefully during her Christmas break. I also hope to be able to package this into a course or book. To do this I will have to add more value than the typical AWS/Alexa Developer Console point and click tutorial.

I’m hoping to build something that is largely, if not completely, driven through the CLI. I also plan to dive deeply into the schema and interaction models. These are glossed over in all the tutorials I’ve seen, but from what I’ve learned so far, you can’t really understand what’s going on with a Skill unless you understand those things. Finally, I plan to show how to create an AWS CodePipeline that can auto-deploy the skill when changes are made and committed to a CodeCommit repository.

One of my biggest problems when I learn a new AWS service is that the vast majority of the tutorials give you an overview of the service via the AWS Console and leave you struggling as to how you would ever integrate it into an honest to goodness development cycle. As I learn and teach various aspects of AWS this will always be my focus.

The greatest source of satisfaction for me outside of my family is learning new things. This has made my choice to pursue a career in software development fortunate. In fact, a major source of discontent in a job is when I stop learning, but it also leads to the problem of turning a blind eye to organizational problems if I am learning.

I enjoy learning about software development so much that I’ve learned many languages and techniques that I have never and will never use in my job. I read a book on Ada in college and have never executed an actual line of it. I read a bunch of the Dylan documentation and even wrote some code for the simulator if I remember correctly. I’ve read the XP book and plenty of other methodology books and never worked in an organization that should have claimed it did anything but ad hoc software development.

Although the majority of my learning focus is on software development I also do a great deal of study in the area of personal development and one of the ideas I have run across is the difference between data and information. Data is just facts and figures while information is data that has context, meaning, and usefulness. I would consider the languages and methodologies I studied to be data. Since I haven’t actually put them in practice they aren’t any more useful than the dates of random historic events. I want to get in the habit of making what I learn useful; turn the data into information.

What I’m going to do is write (and possibly make videos) about what I’m learning. I’d like to turn this writing into a book or course of some sort. In my mind this would be the perfect combination of turning my love for learning into a source of income.