On work, burnout, and recovery

A while back, I was asked what I would change about my job. My answer was that I would like to have more vacation time.

In other words…what I would like to have for my job…is less of it.

The funny thing is, I like my job. It’s consistently challenging. I have to do and learn new things all the time. The hours are semi-flexible, the dress code is practically non-existent, and the cafeteria is a major perk.

All that – and it’s still easy to get burned out. I’ve been in the same job for seven years, now. There have been a few title changes – software developer to software developer II to senior software developer – the people are different, the languages are mostly different..but I’m still programming. Now, I like programming – I like technology in general – but I’ve never done the same thing for so long. I get bored and want to move on to something else.

So why not move on from programming? A big part of it is the money, of course – being a software developer pays really well. I’m getting older and I have a family to support, which makes jumping around harder. On top of that, this is something that I CAN do long-term – there are new challenging all the time, which is what makes it interesting. And yet – I get burned out.

There are different ways of fighting it. Sometimes I go to programming conferences, which helps me get excited about coding again. Sometimes I work on my book – I love teaching, and my book (which I’ve been writing sporadically for a few years now) is one way to do that. But sometimes I feel like I just need a break. In 2016 my wife and I spent two weeks in Europe, and it was amazing; for two weeks I completely cut myself off from work, blocked email from my phone, and just relaxed. I needed that.

Little bits of vacation – a day here, a day there? It’s not enough. I end up answering work emails and don’t clear my mind. I need a real break, one where I focus on something that’s not work related. A week at BGGCon, focused on playing board games with my friends. A few weeks in Europe, focused on traveling with my family.

I like my job. Time away from it helps me to be better.

Improving query performance in SQL Server with recompile

This week I ran across a new-to-me option in some T-SQL code I was reviewing: OPTION (RECOMPILE). It turns out that this option improves performance by forcing SQL Server to recompile the query rather than using the plan it already generated.

Wait, what? Don’t we save time by saving a query plan and reusing it?

Generally, yes. When you first run a stored procedure, the SQL engine will figure out a plan for that procedure and cache the plan for reuse, thus saving the time of recomputing the it each time the procedure is run. The problem comes in when a plan is generated that makes sense for the current database state and parameters, but doesn’t make sense when those change. For example, suppose you have a table with ten million rows; different approaches are required if you want to retrieve ten of those rows vs seven million of them.

Generating the query plan

When the stored procedure is executed, SQL Server looks at the distribution statistics it has about the data in the tables the procedure references and uses this data to guess at the best way to run the query. Assuming that the statistics are up to date, it can generally make a fairly good guess; for example, it may choose an index seek if it expects to return a small number of rows, but a table scan if it expects that a significant percentage of the table will be returned.

Parameter sniffing
Sometimes, the output of the procedure depends heavily on the value of a parameter; one value might result in returning one row, while another returns a million rows. When you run the procedure, SQL Server sniffs the parameters and uses whose to choose the query plan. If a query is called with literal values, you get one plan for each call, but if it is parameterized, the same plan is used the next time the procedure is called even if the value of the parameter is very different. If the procedure behaves similarly as the parameter varies, this works fine, and you save the cost of creating a new plan each time. If it doesn’t, however, you can end up with a plan that is orders of magnitude slower than optimal.

Telling SQL Server to recompile forces it to create a new query plan rather than reusing the old one. When the old plan was “good enough”, this is a bad thing – generating the plan is expensive. In some cases, though, the performance improvement from using a better plan easily overwhelms the cost of recomputing that plan.

One way to do this is to alter the stored procedure to include the WITH COMPILE option; this tells SQL Server not to cache a plan, so the query plan is regenerated each time. Alternatively, we can add OPTION (RECOMPILE) at the statement level, in which case only the plans for that particular statement, rather than the entire procedure, will be regenerated.

Being bossy with SQL Server
Forcing a recompile isn’t the only way to take control away from SQL Server. Another option is to use the OPTIMIZE FOR hint, when you know that the plan for a particular value will work well for a wide range of possible parameter values; in this case, you use domain knowledge to improve on what SQL Server could manage with statistics alone. You can also use OPTIMIZE FOR UNKNOWN to keep SQL Server from optimizing based on the particular value that was passed in.

Remember the disadvantages of taking control away: you lose the performance benefits of reusing a query plan, and if you make a bad choice as to what value to optimize for (or the data changes to make it a poor choice), you could see much worse performance than if you just leave SQL Server alone to do its own thing. As usual, you want to tell SQL Server how you want it to process something (rather than just what you want it to do) only when you have a good reason for doing so.

Goals for 2018

I’ve never been a believer in New Year’s resolutions; there’s a reason it’s a cliche to start a new exercise program in January and abandon it by February. Resolutions tend to be things that people would like to do…and by the end of the year, they become things that people would have liked to have done.

At the same time, goals can be worthwhile – especially if they’re SMART goals. A SMART goal is one that is specific, measurable, actionable, realistic, and time-bound.

Specific: It is clear exactly what the goal is.
Measurable: It is clear whether the goal has been achieved.
Actionable: It’s clear what actions need to be taken to achieve the goal. “I will be a millionaire in a year” isn’t actionable; “I will spend at least two hours per week writing” is.
Realistic: The goal is something you can realistically achieve within the given time bound.
Time-bound: There is a deadline for when the goal will be accomplished.

For 2018, I’ve decided to set New Year’s commitments. Why commitments instead of resolutions or goals? Because I’m committing that these are things I will get done this year (and I’ve actually set up a penalty for if I fail to accomplish any of them). In 2018, I am committing that:

  • I will publish at least one book – this will probably be either my computer science textbook or my first novel.
  • I will apply to speak at [at least] two conferences – probably the two I spoke at in 2017 and any others that look good.
  • I will update my blog at least once per month.

None of these goals are based on things outside of my control; I’m not resolving to make six figures from my book (although it would be nice!), have my talks accepted, or write an outstandingly brilliant post; I’m simply committing to doing the work, and posting a public record of that commitment. When I’m running on way too little sleep because the baby was screaming all night long, I won’t have the option to say “oh, I guess I have a good excuse for not meeting my goals this month” – I have this commitment to hold myself accountable.

Are you setting goals for 2018?

That Conference Follow-Up

We’ve finished another That Conference! This was my third year attending, but my first time as a speaker.

As much as I love the name (I’m going to That Conference next week. Which conference? That conference!) and the location (who doesn’t want to spend the better part of a week at a water park?), as much as I love the opportunity to spend three days focused on learning…I think what I get most out of That Conference is an opportunity to recharge. To recover from burnout. To get excited about programming again.

One thing I’ve struggled with is the “hallway track”; I know that many people go to conferences specifically to talk to other developers (often at the cost of even going to the talks!) – That Conference even schedules a half hour break after each session to allow for this – but as someone with a severe hearing loss (and an introvert) I have a very difficult time inserting myself into conversations. This year was easier for two reasons: I met an online friend in person for the first time, and giving a talk provided a ready conversation topic, so I was able to have much more in the way of meaningful interactions than I have in years past.

I’ve uploaded the slides for my accessibility talk; there are a lot of extra details in the presenter notes that I included for reference but didn’t have time to actually work into an hour-long talk. Accessibility is an issue that a lot of people are talking about these days, but that many companies still aren’t taking as seriously as they should; often it’s still an afterthought (or a no-thought). That Conference has been trying to encourage the voices of underrepresented groups (their current goal is to have half of the speakers be women), so I’m hopeful that we’ll also continue to see more work on reaching out to people with disabilities. Last year a number of speakers (including at least one of the keynotes) showed videos without captions, and I wasn’t seeing that this year – I don’t know if that’s just coincidence or if people are keeping accessibility in mind.

I’ll be speaking at MKE.NET in a few weeks, on sorting algorithms, and I definitely plan to be back at That Conference next year.

Accessibility and HTML5: Semantic Elements and More

A div for everything and everything is in its div…

If you’ve been working on websites for a while, you’ve no doubt had a few that seem to be just div after div, where the div explosion serves to place or style each part of the page as needed. The problem is, a div by itself doesn’t tell the user (or, more to the point, the user agent) anything about what the div contains, and the styling is likely to be lost on someone using a screen reader.

In HTML5, we have the semantic elements, which generally act like divs – they’re block elements that contain other elements – but also provide meaning; each tag describes what it contains, which allows a user agent (such as a screen reader) to handle it appropriately. We still use divs, when no semantic element is appropriate, but they should no longer be the first choice. The semantic elements include:

  • <nav> encloses a navigation block; this will often contain a list of links, but not every list of links needs to belong to a nav. Screen readers may be able to go directly to the nav section or skip it if not needed.
  • <main> is for the main content of the document; it should contain only content that is unique to that document, not content repeated across multiple pages. User agents will often be able to navigate directly to the main content block, bypassing navigation links. At most one main element should exist in a given document, and it cannot descend from an article, aside, header, footer, or nav element.
  • <article> describes a self-contained block; it could be moved to another page and still make sense on its own. A page that consists of one self-contained block of content will simply hold it inside a <main> element, but multiple blocks that do not depend on each other will be <article>s instead. An <article> can contain other <article>s that are related to it, such as comments on a story.
  •  <aside> contains information which is tangentially related to the primary content, but isn’t required to understand it; this content is likely to be visually represented as a sidebar or pull quote.
  • <figure> encloses some self-contained content, which may be (but is not required to be) graphical in nature. Each <figure> may contain one <figcaption>, which provides a caption for everything contained in the figure; this groups all of the contents and provides a way to refer to them even if the page layout changes.
  • <section> is a…er…section of the document; it groups together part of the document, such as a chapter. Sections generally come with headers and should contain content that logically belongs together.

If none of the above signpost elements are appropriate, then we look for a more specific element, such as <address>, <blockquote>, or even <p>. Only if the content doesn’t have any semantics do we use the plain <div>. It’s a bit more work, but it allows the user agent to process each type of content according to its own rules, according to the user’s desires.

Lack of accessibility: my experience

We’ve been talking about guidelines for making websites accessible in general, and how to make them screen reader accessible in particular. Now let’s get away from the how and look at the actual impact of this work. Here are a few times when I’ve been impacted by a lack of accessibility.

  • Some years back, someone lent me an instructional video for West Coast Swing. The instructor was trying to explain how to dance in time with the music, and you were supposed to listen to the beat while he pointed up and down, which would have been great – except he also SAID “up” or “down” each time, so I couldn’t actually hear what he was trying to point out!
  • When Netflix started doing streaming video, there weren’t any captions. Many people complained (including myself) and Netflix told us that they were in the process of adding them. A few years later, they added streaming captions…for the first five seasons of Lost.
  • When listening to podcasts, it’s not unusual to have people sometimes speaking over music, which makes them harder to understand.
  • When I’ve been to conferences, speakers often show video with no captions.

In many cases, these aren’t even difficult things to fix. The dance instructor could have simply pointed rather than speaking, there’s no reason to have music on in the background when recording speech, and of course adding the already-existing captions to more of their streaming videos was well within Netflix’s capabilities if they had prioritized it. For speakers showing video, captioned versions are often available (sometimes the captions just need to be turned on!), and adding captions to original videos is fairly straightforward with modern video editing software. In each case, the problem isn’t technological; the problem is people either not thinking about the needs of viewers with hearing impairments or simply not caring.

Fortunately, things are improving. Netflix was sued under the Americans with Disabilities Act and now captions pretty much everything. Conference organizers are starting to pay more attention to accessibility. I’m in the process of booking a cruise as I write this, and the cruise ship provides assistive listening devices, sign language interpreters, and open captions on some movies. Movie theaters are now required to provide some way (usually Captiview, which is not a great option but is way better than nothing) for deaf patrons to follow what’s being said.

I’m writing this from the perspective of someone with hearing loss, because I’m deaf, but I’m sure people with visual or mobility impairments could provide a similar list of issues. What’s happening lately, partially through awareness and partially through political/legal action, is that more service providers are considering what they need to do in order for their product to be truly usable for everyone.

Testing for accessibility: Web Content Accessibility Guidelines

What makes a website accessible?

The answer, of course, is that a website is accessible if it is usable by all people, regardless of disability. When building a website, however, we need something a little more concrete; we need a way to test whether the website is accessible, without having to have people with a hundred different impairments actually testing it. That’s where the Web Content Accessibility Guidelines (WCAG) from W3C come in. Following the guidelines doesn’t guarantee that your website is usable for everyone, but it’s a good starting point for handling the most common accessibility issues. The guidelines help insure that all users can both access the content and navigate the website.

How important is the WCAG standard?

Many countries require that their government websites follow the WCAG standard (the US uses Section 508 guidelines, which are expected to require AA WSAG compliance, described below). Last month, a federal court ruled that having an inaccessible website is a violation of the Americans with Disabilities Act (ADA), and the Justice Department has successfully sued companies (including Carnival and Wells Fargo) over lack of accessibility (both physical and online). The ADA requires that places of public accommodation be accessible to the disabled, and websites which directly sell goods or services, or connect to physical locations which do, have been ruled to be places of public accommodation and thus subject to the ADA requirements.

How are websites evaluated?

WCAG includes three levels of compliance: A, AA, and AAA. A is the minimum level of conformance; a website that does not meet the level A requirements is simply not usable by people with certain disabilities. These are things that every accessible website MUST do. AA requirements make the website easier to use; these are things that every accessible website SHOULD do. Finally, AAA requirements are going “above and beyond” to make things easier for people with disabilities; they are things that a website MAY do. In order to claim compliance for a particular WCAG level, every part of the website must meet every WCAG requirement for that level (as well as for the levels underneath it).

What is covered?

The WCAG standard is composed of four basic principles, with a number of guidelines that lay out specific requirements for meeting those principles. The principles are:

  • Perceivable. This is the most straightforward: information must be presentable to the user in a way that he or she can perceive. This includes things like text alternative for non-text content (pictures, recorded audio, recorded video), not communicating information solely by color, allowing the user to resize text, etc.
  • Operable. This means that a user is able to navigate the website. This includes obvious things like being able to navigate using a keyboard alone, without losing focus, but also things like not having anything that flashes more than three times per second, which could trigger a seizure.
  • Understandable. This principle at first seems more subjective; who’s to judge whether the text of a website is understandable or not? Guidelines here include that the browser can determine what language the page is in, explaining abbreviations (such as by putting the first use of the abbreviation immediately after the expanded form, as we did with WCAG and ADA above), and making the website perform in predictable ways (for example, having consistent navigation).
  • Robust. The website can be interpreted reliably by a variety of user agents – this is any piece of software acting on behalf of the user, such as a screen reader. This includes things like closing tags (so that the site can be parsed correctly) and associating labels with their corresponding fields.

Getting started

Because the standards include things like website navigation, the easiest way to meet them is to design in accessibility from the very beginning. Failing that, the guidelines are relatively straightforward to test for, and many of the accommodations, such as providing alt text for images, are fairly trivial to make. Even small changes like this can make a huge difference for someone trying to use your site, and many of them benefit your typically-abled users as well.

When to say “I don’t know”

Many years ago, I taught middle school math. One day a student asked me a (non-math related) question that I didn’t know the answer to, so I told her that I didn’t know. She then got annoyed with me because apparently, teachers are supposed to know everything.

I was reminded of this recently when seeing comments about hiring people because they weren’t afraid to admit in an interview that they didn’t know something. Apparently this is somewhat uncommon, which suggests that an awful lot of people are trying to BS their way through interviews.

Of course, nobody wants to hear “I don’t know” to every question, but assuming that you’re qualified for the job you presumably can answer most of them. This applies to working as well; I’d much rather you tell me that you don’t know how to do the task you’re assigned than pretend you already know and get in over your head.

So, here are some acceptable ways to say “I don’t know”:

  • I’m about 80% confident that this is the answer, but I’d have to double check to be sure.
  • I haven’t worked on that functionality, but Jim would know. Let me conference him in.
  • I can’t give a firm deadline for when the project will be completed because we’re waiting on feedback from QA. I’ll follow up with them and see when they expect to be done testing.

Here are some less acceptable ways to do it:

  • I don’t remember. [And I’m too lazy to look it up]
  • I don’t know. [And I can’t be bothered to find out]
  • It was exactly 1,429.3. [Or some other BS answer]

Simply put, if you don’t know something but can find out the answer or direct me to the person better suited to answer the question, that’s just fine. If you are the person who should know the answer, but for some reason you don’t, then you should be finding out; don’t just shrug it off or (worse) make something up. Nobody (well, except apparently some 7th graders) expects you to know everything, but if you’re being lazy or BSing the answer, people won’t be particularly eager to work with you.

tldr: You don’t have to know or remember everything; just be honest.

Making your site screen reader accessible

One of the things I’ve been working on lately is ensuring that our web apps are accessible, which primarily means that those with visual impairments can use them. Partially that means making sure to use high-contrast colors and large buttons, and partially it means the webpages work well with screen readers.

Screen reader compatibility largely breaks down into the following:

  • Is the entire page keyboard accessible; can the user access all functionality and information without using the mouse?
  • Does the screen reader tell the user everything he needs to know about what’s going on on the page?
  • Does the screen reader avoid throwing gibberish at the user?


Is the page keyboard accessible?

Can all of the page functionality  be used without a mouse? This means more than just being able to tab to all fields (although that’s the obvious first step). Other things to consider:

  • Is there any information that’s only available when hovering over an area of the screen? Unless this is a field that can be tabbed to (in which case a screen reader will read the tooltip), that information may not be available to keyboard users (or mobile users).
  • If there is a popup window, does focus return to the main page when the popup is closed? Similarly, when clicking a button, does focus go away? If focus is lost, a keyboard user is stuck.

Will all visible information actually be read?

  • If the page contains text which isn’t associated with a control that can gain focus, it may be ignored entirely by the screen reader.
  • If taking an action causes a visual change elsewhere in the page – say, making a warning visible – then even if that change is visible to the screen reader, the user is unlikely to know about it immediately and could either miss it entirely or become frustrated when it is encountered and it’s either not clear what caused the warning or it’s difficult to navigate back to the appropriate section.

Will extra information be read?

If you don’t tell them what not to read, screen readers will try to grab everything. Even a well-designed page will throw a lot of information at the user (which is why screen readers talk really fast). If you’re using tables to style your content, the screen reader will read off all the details of the table. When testing, I’ve found that sites like Facebook can completely overwhelm the screen reader. There are various attributes you can add to clean this up (such as role=”presentation”) which may or may not be correctly interpreted, depending on which screen reader you use.


Unsurprisingly, accessibility ends up being something that, while you can follow best practices, you still need to test for. The top screen reader option, JAWS, is horrendously expensive (starting at $900 for a home license), but NVDA is a free, open source alternative that works well for testing. Helpfully, there is a text box option so you can see what it’s saying rather than simply listening at high speed. So far I’ve only used it for work, but while writing this post I tried it out on this site and determined that the site is not actually screen reader friendly, which tells me I need to make some revisions! Hopefully I’ll have an update on that in a future post.

Is it worth it?

Making a website accessible can be a lot (and I mean a lot) of work, for relatively little reward (the number of people using screen reader software is obviously a small percentage of the overall audience, particularly for some specialized sites). However, we still have an obligation (both moral and, in some cases, legal) to make our work usable for as many people as possible. As a bonus, efforts taken to improve usability for people with disabilities often end up being a great help to people we wouldn’t normally think of as disabled, simply impaired – the elderly, for example, who may have weakening vision. In a future post, we’ll talk about accessibility improvements we can make that will help improve usability for all of our users.

The Value of Design

When I first started as a developer, the process was simple. You picked (or were assigned) a bug to fix, you fixed it, and then you sent it off for testing.

…and then, sometimes, your tester (another developer) argued that you’d fixed the bug in entirely the wrong way and should completely redo the fix. Sometimes he also provided information you didn’t know about that proved he was definitely correct.

Then we added a design requirement. Before doing a fix, you had to have another developer sign off on what you were going to do, which meant that many potential problems could be uncovered before putting in too many hours of work.

Of course, it wasn’t always that easy. Sometimes you don’t have any idea how to fix a problem until you’ve spent a while working on it, and sometimes you just have to sit down and code a solution before you know whether it’ll work or not. But overall, adding a design step to the process made it flow a lot more smoothly, even taking the additional design time into account.

No doubt you’ve seen infographics similar to this one:

A bar graph showing the relative costs of fixing defects, according to when in the development process they are uncovered.
Integrating Software Assurance into the Software Development Life Cycle (SDLC) (PDF Download Available). Available from: https://www.researchgate.net/publication/255965523_Integrating_Software_Assurance_into_the_Software_Development_Life_Cycle_SDLC [accessed Jun 21, 2017]

The idea is simple: the earlier a problem is found, the easier it can be fixed. It’s easy to move lines around in a blueprint; it’s much more difficult to move the walls in a finished building. Similarly, it’s best to get input from all the stakeholders as to whether your proposed fix meets their needs before you actually spend a lot of time implementing and testing it, especially if it takes a while for new development to make it through the testing process. We actively solicit feedback from end users before a new feature is complete, because we want to know how it meets their needs while we’re still building, not a year later when we’ve moved on to other things.

Of course, it’s also easy to go too far. A design shouldn’t be a copy of all the code changes you’re making (unless it’s a really simple change); in that case you’re still doing the development first and getting feedback later. At the same time, it should usually be more detailed than “there’s a bug in this part of the code and we’re going to fix it.” At minimum, as a person reading your design, I should understand:

  • What is the problem?
  • How are you doing to fix it?
  • How will I know it’s been fixed?

For example, a design might be something like:

  • When you do X, the software crashes.
  • This happens because we didn’t check for a null property before accessing a subproperty, in this function.

Pretty straightforward, right? But it’s clear what the problem is (the software crashes), what the developer is going to do about it (add a null check), and what the result will be (the software will no longer crash). The technical reviewers understand what the fix will be and can suggest changes (should we be showing an error message if that property is null?). The testers understand the workflow they have to follow to reproduce the crash (or rather, to not reproduce it). And the poor developer doesn’t have to make the fix, test it, send it off for code review, and then be told to do something completely different. Everybody wins!