Dustin Ewers

Ignore the Grifters - AI Isn't Going to Kill the Software Industry

Mon, 13 Jan 2025 08:00:00 GMT

I feel like half of my social media feed is composed of AI grifters saying software developers are not going to make it. Combine that sentiment with some economic headwinds and it's easy to feel like we're all screwed. I think that's bullshit. The best days of our industry lie ahead.

It's highly unlikely that software developers are going away any time soon. The job is definitely going to change, but I think there are going to be even more opportunities for software developers to make a comfortable living making cool stuff.

Here's your white pill. It's all going to be okay.

Economics

The field of economics has a lot to say about automation, productivity gains, and how they effect the economy. There's no shortage of people saying "this time it's different", but those people have been around for every other major technological advance and they have yet to be correct. I wouldn't bet on the doomers.

Jevons Paradox

AI tools create a significant productivity boost for developers. Different folks report different gains, but most people who try AI code generation recognize its ability to increase velocity. Many people think that means we're going to need fewer developers, and our industry is going to slowly circle the drain.

This view is based on a misunderstanding of why people pay for software. A business creates software because they think that it will give them some sort of economic advantage. The investment needs to pay for itself with interest. There are many software projects that would help a business, but businesses aren't going to do them because the return on investment doesn't make sense.

When software development becomes more efficient, the ROI of any given software project increases, which unlocks more projects. That legacy modernization project that no one wants to tackle because it's super costly. Now you can make AI do most of the work. That project now makes sense. That cool new software product idea that might be awesome but might also crash and burn. AI can make it cheaper for a business to roll the dice. Cheaper software means people are going to want more of it. More software means more jobs for increasingly efficient software developers.

Economists call this Jevons Paradox.

Comparative Advantage

When we think of future AI, we imagine a system that can do everything better than a human being. The all-knowing AI is better at programming, art, diagnosing diseases, and coming up with new ways to make toast. How can any human compete with that?

Turns out, it doesn't really matter. There are already lots of situations where people who aren't the best at something still find work.

Imagine a small business owner who is absolutely the best at everything in their business. They know every aspect of their business and can do any job in it better than anyone they can hire. Regardless of their genius, they only have 24 hours in a day. If they want to scale, they will need to hire people so they can focus on their most important work. For example, the business owner may be a better bookkeeper than their accountant, but the opportunity cost of not working on other things justifies hiring someone to keep the books.

This is an example of comparative advantage. Comparative advantage is when a country, company, or person can produce something at a lower opportunity cost than others. Even if that entity is not the most efficient producer, they'll still be able to sell their product as long as someone else has more important things to do.

While AI is powerful, it's also computationally expensive. Unless someone decides to rewrite the laws of physics, there will always be a limit on how much artificial intelligence humanity can bring to bear. This means that we'll eventually allocate our scarce AI resources towards the things they are best at, which leaves plenty of things for humans to do.

Solow Model of Growth

The Solow model shows that economic growth is a product of capital (factories, data centers, corporate relationships, land, etc...), labor, and technological progress. In the long run, the only reliable driver of economic growth is technological progress. Our society gets richer by learning new ways to deploy scarce capital.

Another way to think about this on a micro level is that you can't sustainably make more money than the economic value you create. A person who digs a hole with a shovel is not going to be able to make as much money as someone driving a bulldozer.

Widespread adoption of artificial intelligence will greatly accelerate technological progress. This acceleration will create a massive increase in economic growth. This rising tide will create more resources for everyone. If you've spent any time following the e/acc community on Twitter, this is what they're banking on.

The Solow Model is more of a macro level concept and doesn't specifically apply to software development as an industry. While I don't think software development as a career is going away any time soon, if it does, we'll still probably be better off. It's better to be a barista in Star Trek than a noble in Game of Thrones.

Widespread AI

While increased societal wealth is nice, what happens if all of that wealth is controlled by a handful of large companies run by a small cadre of tech elites that hoard all of the AI compute?

This is unlikely for a lot of reasons, but one of the big reasons is that AI innovators are committed to making AI accessible. While there are plenty of folks that offer access to AI-based tools, you can also DIY your own AI.

On the model side, many producers of models release them for free. While the top tier Open AI models are locked behind their walled garden, you can fire up Ollama or CivitaI and download lots of very capable models.

On the hardware side, Nvidia is also pushing local model execution via things like their Jetson Nano products and Digits mini computer. This doesn't even include things like consumer video cards, or the M4 Mac Mini, which people have been using to make their own AI clusters. AMD is also working hard to make it easy to run local models.

There's a huge incentive to make AI resources accessible to most people. If we amplify everyone by making it easy to access their own small army of personal assistants, innovation skyrockets. AI has the potential to enable millions of small creators to build sustainable businesses.

The Job of Software Developers

Now that we've covered a few macro reasons why we aren't screwed, let's look at some more down to earth reasons why we're still going to need software developers in the age of AI.

The 70% Problem

AI models are fantastic at producing a wide variety of things. Sometimes the results are good and sometimes they're weird. AI generated code is no different. I have yet to prompt an AI generated function that's 100% correct. Gen AI is great for getting started, but it won't write your whole app for you. This is occasionally referred as the "70% problem", where AI can get you most of the way there, but it falls down at the end.

A lot of folks who don't know how to write software and think they can prompt their way to success will get stuck in a loop where each prompt fixes one issue and causes two more. This is the 70% problem in action. You can generate code all day, but there's no guarantee it's going to be the right code.

Even if you get the AI to generate all of your code for you, it still needs to be tested, monitored, deployed, and maintained. Even if you get AI to write most of your code, there's still plenty to do.

AI code gen also tends to fall down in complex enterprise systems. You can crank out cute demo apps all day long, but most systems don't resemble cute demo apps. This isn't much different than the Ruby on Rails 15 minute blog app scaffolding demos from back in the day. They looked cool, but it was only the first step.

Much of our job isn't writing code anyway

The folks who think AI is going to wipe out the software industry don't fully understand what software engineers do day to day. After 20 years, coding is honestly one of the easiest parts of the job for me. There's lots of time spent talking with other engineers, understanding the business domain, figuring out the best approach, weighing options, and designing systems. Even if AI generates most of our code, we'll still need to tell the thing what to write and that's going to require software developers.

We have so much software left to build

The biggest assumption of the doomer crowd we're close to having "enough" software and increased efficiency is going to quickly exhaust the project queue. I have yet to work for a company that doesn't have a near infinite backlog of things they want to do. If software development moves faster, we're just going to build more software.

What do I need to do?

Some developers think AI isn't going to change much of anything and we should just sit tight and wait for it all to blow over. That view is just as short sided as the doomer side of the equation. Software development has always been a career where you are either learning new things or stagnating. AI doesn't change the need to keep learning and evolving.

The best thing you can do is learn how the current stack of AI tools work. If you can use Copilot at work, go for it. Otherwise, spin up your free Copilot trial and build something. Beyond that, take some time to learn how AI works and think about other ways it can improve your workflow. Maybe get it to crank out some of that documentation you don't want to write anyway.

Beyond that, keep learning about what it takes to build good software. Work on your architecture & design skills. Consider branching out into other areas in the stack like product development. While the value of raw coding skills might go down, the value of everything else around them is going to continue to rise.

The software developer job is going to change a lot in the next five years. The AI revolution is similar to the introduction of compilers. If you keep up and learn the new paradigms, then you're going to be okay. Otherwise, you might find yourself in a bad place.

Things are probably going to get a little weird, but it's not like you signed up to be a developer because it was the same thing every day. Crack the books, fire up your copilot enhanced editor, and make cool stuff.

Links

If you want a longer description of this topic, check out this article from an actual economist:<br/> Plentiful, high-paying jobs in the age of AI

A good video series on the Solow Model:<br/> Intro to the Solow Model of Economic Growth

The Tech Lead's Schedule Kinda Sucks

Wed, 24 Jul 2024 23:00:00 GMT

When working on a new team, I often share the essay "Makers Schedule, Manager Schedule" by Paul Graham. You should read it, but I'll give you the tl;dr; in case you don't.

Makers vs. Managers

Makers and managers have different scheduling preferences. Makers (i.e., developers and designers) need long stretches of time so they can concentrate. A 30-minute meeting in the middle of the afternoon costs you way more than 30 minutes.

Meanwhile, managers schedule meetings for most of their day, so a 30-minute afternoon meeting isn't any different than any other time slot.

The primary lesson is to schedule your maker attended meetings in clusters (like a sprint review/planning day) or stick meetings to the start of the day or after lunch. This maximizes time blocks, which keeps the makers making things.

But what if you're in the middle?

This strategy is great until you become a technical leader (lead dev, architect, staff engineer or principal engineer). Leads have a significant meeting load and are also expected to contribute code and/or designs.

While being a lead can be rough, here are three strategies to adapt.

Delegate

If your team has one or more senior engineers, make it a habit to delegate challenging technical implementation to them. It's hard to let go sometimes, but you don't have to do every complicated thing in the system. Most developers like a challenge, so you might even be doing them a favor. Let smart people be smart.

Eliminate

Ditch any meetings that don't serve a purpose. In most corporate projects, you accumulate meeting invites. Some of these meetings outlive their original purpose and are no longer valuable. Other meetings are useful, but you don't add anything.

If a meeting is no longer useful, see if you can cancel it for everyone. If you don't add value to a meeting, see if you can get removed from the invite list. Make it a regular habit to audit your calendar and look for things to eliminate.

Schedule

Put blocks of concentration time on your calendar. If you need the time, then schedule the time. Otherwise, people will schedule the time for you.

A less fun version of this is scheduling a work session later at night when no one is around. I know several technical leaders who will hop after the kids have gone to bed to get some work done. I personally avoid late night work sessions, but it works for some folks.

Figure it Out

The leads schedule is one of the more stressful parts of being a technical leader. Even if you delegate, eliminate, and schedule like a champion, you'll still need to deal with context switching and demands on your attention. The juggling act is real.

The mix of meetings and deep work can be fun if you like variety, but there's a reason some leads return to senior engineer roles. If you want to be a leader, you'll need to figure it out.

Generate a Password in One Line using Bash or Powershell

Sun, 07 Jul 2024 00:00:00 GMT

Sometimes you need a quick way to generate a random password for a development environment. There's a lot of ways to do this, but here are a few one liners to use if you need something quick.

Disclaimer: These methods do not generate cryptographically secure passwords and may need adjustment to meet specific password requirements.

Bash

This one-liner redirects random noise from /dev/urandom to the tr (translate) command, which then filters it (using -dc) using a character set. Then it pipes the output to the head command, which retries a specific number of characters and echos it to the shell. Modify the character set to fit your particular password commands. Here's a couple of examples:

tr -dc 'A-Za-z0-9!"#$%&'\''()*+,-./:;<=>?@[\]^_{|}~' </dev/urandom | head -c 20; echo

tr -dc 'A-Za-z0-9!@#$%' </dev/urandom | head -c 20; echo

Windows Powershell

[Reflection.Assembly]::LoadWithPartialName("System.Web") [System.Web.Security.Membership]::GeneratePassword(15, 2)

To be fair, this is a two liner, but it's easy enough to understand. This loads the C# System.Web library and uses it to make a password. This generally won't work on Powershell Core (ie. v7+).

Powershell (Core or Windows)

This command takes an array of allowed characters and randomly selects them. These characters are defined using their ASCII codes.

-join ((65..90) + (97..122) + (48..57) + 33, 64, 35, 36, 37 | ForEach-Object {[char]$_}| Get-Random -Count 20)

A less picky variant.

-join ((33..122) | ForEach-Object {[char]$_})

You can define the specific characters, which is longer, but easier to understand. -join ("ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789!@#$%".ToCharArray() | Get-Random -Count 20)

This one uses character ranges, but character ranges only work on PowerShell Core (v7+) -join ('a'..'z' + 'A'..'Z' + '0'..'9' + "!@#$%".ToCharArray() | Get-Random -Count 20)

Real Complexity vs. Fake Complexity

Sun, 14 Jan 2024 00:00:00 GMT

One of the hills that I’ll die on as a software developer is keeping any solution I make as simple as humanly possible.

While it may seem obvious that simple is better, developers get bored easily. They solve this boredom by adding layers of bullshit to their apps. New libraries, fancy patterns, bonus layers of abstraction, and whatever else can spice up building yet another line of business app. This extra cruft can be fun to implement, and it’ll make you feel smarter, but it slows down the team. It takes away from the work that helps the business and keeps your checks signed.

The thing is that most projects have real complexity that needs to be conquered. Real complexity can take many forms. Sometimes it’s a complex business process that has a million rules and exceptions. Sometimes it’s a tricky bit of UI that’s going to make the user’s lives easier. Maybe you actually need massive scale to meet a business requirement. A lot of the time it’s getting a bunch of disparate people on the same page. The difference between these situations and adding the latest random NPM libraries to your code is that this complexity benefits the users of your applications. You can still flex your big brain muscles while doing good.

Look out for extraneous complexity on your projects. Remove components you don’t need. Minimize your library footprint. Suggest simpler ways to do things to bring the same value to the table. Always be on the lookout for unnecessary complexity, because otherwise, it’ll creep into your codebase and distract you from your real problems.

Why You Should Treat Yourself to a Mechanical Keyboard

Wed, 03 Jan 2024 00:00:00 GMT

With the holidays finished, it's time to get something for yourself. As developers, we spend most of our time sitting in a chair, typing at a keyboard. The pain of sitting in a lousy chair is immediately apparent to anyone over 25. What's less obvious is the pain of a mediocre keyboard. Over the past couple of years, I've gradually descended into the second nerdiest hobby (LARPing is #1), customizing mechanical keyboards, and it's been fantastic. While you don't have to go down the nerd rabbit hole, you should upgrade your setup.

In the three decades I've been using computers. I've used everything from old-timey IBMs to dirt-cheap membrane keyboards to fancy mechanical keyboards. Using a mechanical keyboard provides me with a few advantages.

The biggest advantage is that I don't get wrist pain when I use a mechanical keyboard. Mechanical keyboards generally require a lighter keypress. This both increases typing speed and reduces wrist stress. Using a membrane keyboard feels like typing through mush. Eww...

Mechanical keyboards sound better. I enjoy the pleasant thock of a quality keyboard. I've even modified keyboards to improve the acoustics. If you aren't into the noise, you can also buy silent switches. There's a switch for nearly every tactile and sonic preference.

Finally, it feels good to use quality tools in your daily work. It's aesthetic, but a nicely setup desk space adds a layer of enjoyment to the workday.

What I recommend

Switches

I prefer tactile switches that have less than 50gf of activation force. Tactile switches have a little bump when the key is activated. It helps prevent you from bottoming out your keystroke and allows for lighter typing. Tactile switches include Cherry MX Browns and Gateron Browns.

Many people, especially keyboard enthusiasts, prefer linear switches like Cherry MX Reds. Reds are also quieter, which is helpful for working in an office environment.

I dislike heavier switches like Cherry MX Clears or K Pro Bananas. They make my wrists hurt. If you want to assault your keyboard, they might be worth trying.

If you want to try a bunch of switches, you can purchase a switch tester or pop down to your local tech store and test drive.

Customization

QMK/VIA are keyboard standards that allow you to customize each key without installing special software on your machine. This is fantastic for use on corporate laptops and Linux machines. This is a relatively new standard, but an increasing number of keyboard manufacturers support it.

Models

I prefer keyboards with a metal body that has some weight to it. If I can't beat an intruder with it, then I don't want it on my desk. My daily driver is a Keychron Q3 with a Keychron Q0 macro pad. I did a few mods to improve the sound quality, and it's been a great addition to my workflow.

I also liked the higher-end Logitech keyboards, though they don't support QMK/VIA. I also tried the Code Keyboard. It's not bad, but it feels like a toy vs. the Keycron and Logitech boards.

If you don't want to spend $200 bucks, plenty of budget options are available for less. The main thing to look for is that the manufacturer isn't using mainstream switches. You can also buy a cheap keyboard and mod it. There are a ton of videos on YouTube that'll teach you how to mod keyboards. I recommend Hipyo Tech and Switch and Click.

Treat Yourself! You spend 8+ hours a day at a keyboard. It's worth spending the money. Your keyboard is your lightsaber. Spend time figuring out what you like and get yourself something nice.

An Evening Building an ROI Calculator using Blazor and GitHub CoPilot

Sun, 10 Dec 2023 00:00:00 GMT

If you read the news, it sounds like the AIs are coming for our jobs. While I don’t buy that for a second, we’re undergoing a significant shakeup in developer tools. We’re moving from digital picks and shovels to digital bulldozers and jackhammers. It’s essential to learn how to use these tools.

With that in mind, I’m building a series of increasingly complex projects while trying to leverage various generative AI tools. I’ve already kicked the tires on ChatGPT by using it to build PowerShell and Terraform scripts. I had mixed results. ChatGPT is a champ at cranking out boilerplate code, but it’s not 100%.

More recently, I turned my attention towards GitHub Copilot. Unlike ChatGPT, GitHub Copilot integrates into most IDEs, including Visual Studio and Visual Studio Code. Pay your fee, install a couple of plugins, and your dev tools receive an upgrade. While you code, GitHub Copilot will suggest improvements and act as a suped-up autocomplete. Most suggestions are good, but the more code you generate, the less accurate Copilot tends to be. Copilot Chat gives you the ability to ask questions from within your IDE and skip shelling out to your web browser.

Time for a project

I've been doing a lot of client-side work in TypeScript lately, and after my latest fiasco with NPM package management, I'm looking for something a little less annoying. Enter Blazor. Blazor is a Web Assembly + Server Side framework that lets you write web browser code using C# and Razor. It's been on my list for a long time, but until recently, it seemed underdeveloped compared to traditional JavaScript-based frameworks.

Given the average C# enterprise developer's dislike of JavaScript, I'm surprised I haven't seen more Blazor adoption. I'm not a JavaScript hater, but I'm all for skipping the bloated build chains and unnecessary complexity you see in large JavaScript / TypeScript projects.

Inspired by xkcd: Is It Worth the Time?, I decided to create an Automation ROI calculator. The goal is to determine whether or not it's worth automating a task. To keep things interesting, I also added a bunch of variables to test different scenarios, like building an automation script for a group of people.

I spun up a default web assembly template using standard dotnet new tooling to kick things off. Seeing Bootstrap feels like a blast from the past. I'm surprised people still use Bootstrap when so many other UI frameworks have much less bloat.

After building the initial project, I used Copilot Chat to scaffold as much of the project as possible. If you give the tool precise lists of fields, it'll do an okay job sketching out a class or form.

Code completions were okay most of the time. Copilot feels like a suped-up version of ReSharper. It will predict what you are doing and then let you tab complete through it. It's fantastic when you have to make the same change in a bunch of places.

I also tried using Copilot to make unit tests for my calculation class. Copilot made tests but also made tests for private methods, which is not ideal. The tests also needed to be fixed. Again, it was good for getting you past blank page syndrome, but I still did most of the work.

After fiddling with Bootstrap styles, I deployed the app to an Azure Static Web App. It's been a while since I've messed around with Static Apps, but the experience has dramatically improved. Azure's experience is similar to Netlify, my current go-to for static sites.

If you want to calculate some ROIs, you can check out the project here: Should I Automate That

Impressions

Some studies show GitHub Copilot makes developers 40% more efficient. For me, I'd estimate it closer to 10%-20%. That sounds like a slight improvement, but it's 100% worth the $10-$20/month price tag. My efficiency will likely improve as I use the tool more and Github continues to enhance its product. If you want to be more efficient, I'd recommend getting a subscription to Copilot. Copilot and tools like it will be the future of our industry, so you should jump on board now.

Links

Should I Automate That

Blazor | Build client web apps with C# | .NET (microsoft.com)

GitHub Copilot · Your AI pair programmer

Should I Automate That: Repo

Acing the AI-900 Exam - Entering the World of Artificial Intelligence

Sun, 22 Oct 2023 00:00:00 GMT

The Azure AI-900 is the first step in mastering AI Engineering on the Microsoft stack. It's an introduction-level exam, so there's no expectation of previous experience with AI or ML. I recently passed my Microsoft AI-900 exam, and here’s how I did it.

Main Topics of Study

Exam Details

The AI-900 exam is mainly a test of basic AI/ML concepts and the Azure services you can use to use those concepts. For example, if you want to read the text of a stack of paper documents, you would use Optical Character Recognition (OCR). In Azure, you can use the Vision service to perform an OCR workload. Most of the questions are multiple-choice, and you won't have to write code or read case studies. There are many questions where you match a particular workload to the correct machine learning technique or Azure Service. If you understand the various types of machine learning and AI workloads and how to run them on Azure, you will be golden.

Exam Objectives

Describe Artificial Intelligence workloads and considerations

This objective covers the different types of AI services on Azure and how to use them. You need to know the difference between Azure AI Services (aka. Cognitive Services), Azure Machine Learning, and Azure Bot Services.

Describe fundamental principles of machine learning on Azure

This objective covers general machine learning techniques. To succeed here, you must understand the basic classes of machine learning algorithms and when to use them. This includes topics like regression, clustering, and classification. You also need a high-level understanding of Azure Machine Learning Studio.

Describe features of computer vision workloads on Azure

This objective covers the variety of services under the computer vision umbrella. This includes services like Computer Vision, Face, and Form Recognizer. You'll also need to understand the basic concepts of Computer Vision, like image classification, OCR, and object detection.

Describe features of Natural Language Processing (NLP) workloads on Azure

You'll need to understand the various NLP features on the Azure Stack, primarily focused on the Language service. You must understand the various features of translation, sentiment analysis, and text analytics. You'll also need to understand the concepts of NLP, like tokenization, lemmatization, vectorization, and stemming.

How to Prepare for the AI-900

The AI-900 exam page has a collection of self-paced MS Learn training to prepare for the exam. This is your primary resource for the test. Don’t bother with buying a book or hunting around for a course. Just do the free training.

After completing the training, do the free practice exam. If you can consistently score over 80%, you're ready to take the exam. If not, you'll get a custom list of MS Learn Modules to complete, and then you can try again. The practice exams are free, so keep taking them. After completing the course, I took the exam every day until the test day.

I'd also recommend looking over the product descriptions in the Azure Docs. You don't need to memorize them, but you should know what each service does. This will help you fill in any knowledge gaps from the MS Learn training.

Finally, I recommend watching this exam overview video on your test day or before doing the coursework. It's a solid review of what the test is about. <br> https://www.youtube.com/watch?v=E9aarWMLJw0&t=1311s

Overall, this is not a challenging exam. I'm relatively new to the AI space, and it took me a couple of weeks to plow through the MS Learns and pass the exam. You also don’t need to pony up any dollars for training. The freely available training is more than adequate to ace this exam.

Should You Take It

I'm on the fence about developers taking certification exams. They don't often translate to career capital, but the certification process helps measure mastery of a new topic area. Certifications give you an idea of what skills people think are valuable within a specific area. They’re worth the energy if you’re branching out into something new and want to ramp up your skills.

If you're already an AI Expert or have no interest in Azure AI Services, I'd skip this one and spend time elsewhere. If you want to explore AI and ML and learn the Microsoft stack, hit the books, study, and add this credential to your resume.

<p><small><a href="https://www.pexels.com/photo/elderly-man-thinking-while-looking-at-a-chessboard-8438918/" target="_blank">Cover Photo by Pavel Danilyuk from Pexels</a></small></p>

Building an Effective LLM Learning Environment with Jupyter, VS Code, and the OpenAI API

Thu, 24 Aug 2023 00:01:01 GMT

Let's say you want to board the LLM hype train but don't want to shell out $20 a month for the fancy version of ChatGPT. You can learn more and save a few bucks by setting up your notebook environment using the Open AI API and VS Code.

In this post, we're going to use several different technologies.

Visual Studio Code

I use VS Code for nearly everything. For me, VS Code is usually more efficient than the full Visual Studio. It's a great way to get started with notebooks.

Jupyter Notebooks

Jupyter Notebooks are a standard tool for data analysis. It's like combining a note-taking app with a code execution environment. Jupyter Notebooks are also integrated into various data science and analysis tools. We're going to run our notebooks in VS Code.

Python

I don't spend much time in Python, but it's a common language for data analysis. Sometimes, it's easier to learn a new language to do something than to try and shoehorn your favorite language into a new application. If you're not into Python, the Open AI API is a Rest API, and you're welcome to use Polyglot Notebooks with C# instead.

Open AI API

Instead of ChatGPT, you can use the Open AI API to generate text. This gives you more control over your prompts, allows you to customize system messages, and gives you control over how imaginative the AI is when generating text. It's also much cheaper than ChatGPT because the API is consumption-based. Each call is a fraction of a penny, and you can pick which model you want to use. This is the cheapest way to interact with GPT v4.

Setup Your LLM Notebook Environment

Step 0: Install VS Code

We will assume you already have VS Code installed, but if you don't, head over to the VS Code Website and install it.

Step 1: Install Anaconda

Anaconda is a Python distribution that includes many of the tools you'll need to get started with data analysis. It's the easiest way to get Python and Jupyter Notebooks on your machine. You can download it from the Anaconda Website.

Once you have Anaconda installed, open up the Anaconda Navigator. This will let you customize your installation and add packages.

Step 2: Install Anaconda Packages

You'll also need to install two additional packages. Go to the Environments tab from the navigator, click base(root), and search for the openai and python-dotenv packages. Install both of these using the navigator. You may need to update your indexes before you can find the packages.

The OpenAI package is a library to interact with the Open AI API. The python-dotenv package is a library to read environment variables from a file. We're going to use this to store our API key.

Step 3: Install VS Code Extensions

Next, install the Python and Jupyter extensions in VS Code. You can do this by clicking on the extensions tab in VS Code and searching for Python and Jupyter.

Jupyter Extension

Python Extension ](assets You can also run Jupyter directly from Anaconda Navigator if you don't want to mess around with VS Code.

Step 4: Hello Python

Create a new notebook in VS Code. You can do this by opening the command palette (ctrl+shift+p) and searching for Jupyter: Create New Blank Notebook. After that, enter print("Hello World") into the first cell and run it. You will be prompted to select a Python interpreter. Select the one that you installed with Anaconda.

You should see the output in the cell below.

At this point, you're ready to start using the Open AI API.

Step 5: Get an Open AI API Key

You'll need an Open AI API key to use the API. If you don't already have an Open AI account, you can use your Microsoft login to authenticate. Once you have an account set up, head to the API page to get your key.

OpenAI API API Keys

You will only see it once, so copy it somewhere safe, like a password manager.

You'll need to set up a payment plan. Go to the billing page and buy some credits. You can also set up usage limits to ensure you don't exceed your budget. Five to ten dollars should be enough to get started.

Open AI Billing

Step 6: Add Your API key to an environment file

You don't want to store your API key in your notebook. Instead, you can store it in a .env file. The python-dotenv you installed in step 2 allow this.

Step 7: Authenticate to the Open AI API

In the notebook you created in Step 3 replace the first cell with the following code

import os
import openai

from dotenv import load_dotenv, find_dotenv
_ = load_dotenv(find_dotenv())

openai.api_key  = os.getenv('OPENAI_API_KEY')

This code imports the libraries we need, loads the environment file, and sets the API key.

Step 8: Create a function that calls the Open AI API

Create a new cell and add the following code.

def get_completion(prompt, system="You are a helpful assistant", temperature=0, model="gpt-3.5-turbo"):
    messages = [{"role": "user", "content": prompt}, {"role": "system", "content": system}]
    response = openai.ChatCompletion.create(
        model=model,
        messages=messages,
        temperature=temperature, # this is the degree of randomness of the model's output
    )
    return response.choices[0].message["content"]

This function takes a few parameters and calls the Open AI Chat Completion endpoint. This will give us an easy way to call the API from our notebook.

When working with the Open AI API, you can set a few important parameters.

messages

When calling the Open AI API, there are several types of messages you can send in. The primary prompt type is the user prompt {"role": "user", "content": prompt}. This is the main request you are sending to the LLM.

You can also add additional prompts to help the LLM give you the correct tone. A useful prompt is the system message {"role": "system", "content": system}. This is a prompt that you can use to set the tone of the response.

temperature

The temperature parameter controls how random the response is. A temperature of 0 will give you the most predictable response. A temperature of 1 will provide you with the most random response.

If you want Open AI to generate a contract, then go for a low temperature. If you want Open AI to generate a poem about wombats, then go for a high temperature.

model

Different model families have different capabilities, response times, and costs. The gpt-3.5-turbo model is a good default model. The gpt-4 model is also available but is slower and more expensive. You can mix and match your models in your applications depending on your needs.

You can find more information about the different models on the Open AI API Reference.

Step 9: Start Prompting

This is what we've been waiting for; let's start prompting the LLM. Create a new cell and add the following code.

text= f"""Wombats eating ice cream in a bathtub.
"""
prompt= f"""Please write a poem about the text delimited by triple backticks below. \
```{text}```"""

system="You are an award winning poet known for your funny children's poems."

response = get_completion(prompt, system, 0.8, "gpt-4")
print(response)

This code defines a prompt and adds some text to it. When building prompts, you generally put the user input into a delimited text block. This makes it easier to instruct the LLM and prevent prompt injection.

We also include a system message, set the temperature fairly high, and use the gpt-4 model for maximum quality.

Go ahead and run your cells. If you have set everything up correctly, you should see a poem about wombats eating ice cream in a bathtub.

Experiment and Have Fun

You can experiment with different prompts and models now that you have your own LLM notebook environment. Whether you want to generate a contract, write a poem, or draft the next great American Novel, you have the tools to get started.

A Quick Review of Investments Unlimited

Tue, 22 Aug 2023 08:00:00 GMT

The DevOps movement has been trucking along for over half a decade. We are breaking down silos, automating toil, and making life better for the people who create and operate software. As we continue to "shift left," compliance and security don't always get invited to the party. This is a problem.

IT Revolution, the folks behind The Phoenix Project and The Unicorn Project, has a new book called Investments Unlimited. Investments Unlimited brings security and compliance into the conversation about DevOps by telling a business fable about a financial company that gets slapped with an MRIA (Matter Requiring Immediate Attention) from government regulators. The book follows the struggle to build new systems that automate compliance and save the company from regulatory doom.

Investments Unlimited is a bit light compared to its predecessors. However, it's still an important read because it sheds light on how we can bring security into the fold and automate compliance to make the right way the easy way. The book is chock full of valuable concepts, but in their attempt to avoid recommending specific tools, it came up short on implementation details. The book's main plot revolves around writing a tool that copies the functionality found in many commercially available DevOps tools, which is the real mark of a fable (or at least a "not invented here" culture).

Here are a few essential concepts mentioned in the book:

DevSecOps

DevSecOps adds security to the group of folks called in to shift left. While I'm not too fond of the term creep, I'm 150% in favor of bringing security folks into the early development process, defining security requirements, and then automating compliance via policies and pipeline design.

Golden Path

One of the problems around automating processes in a mature organization is that you always end up with outlying legacy applications that can't fit into your framework. On the other side is the need to adopt new technologies that might not have widespread adoption in the company yet. Instead of automating all edge cases, focus your efforts on a "golden path" of widely used platforms. If someone needs to go off the golden path, they are in charge of implementing the compliance controls themselves.

The beauty of this approach is that it rewards building on a common platform while not punishing or restricting the ability to innovate. If a team thinks they can do better work with a different stack, they are welcome to try it. Similarly, if an older system is printing money for the organization, it might not be worth re-platforming it.

Software Composition Analysis / Software Bill of Materials

Most modern software is an amalgamation of components. Any given solution can include hundreds of packages (if you doubt this, look at any node_modules folder). These packages can be open source, written by the company, or commercially purchased. A vulnerability in these upstream packages can trickle down to your systems. Tracking these components and ensuring they are secure is a huge task, but several tools can automate the process.

Error / Risk Budgets

Error and risk budgeting is a concept from the SRE community. Instead of defining success as perfection, determine an amount of risk or quality deficit tolerable for your particular application. If your app exceeds its budget (i.e., There are too many risks or quality-related defects), drop everything to remediate the risks and get the application back under the budget. This approach works because it allows you to make appropriate tradeoffs while making plans to improve quality over time.

Should I Read It?

Investments Unlimited is worth a read if you're interested in a story about how to bring security into the software development conversation. This is an excellent book to listen to while driving to work or mowing the lawn. It's also a fabulous book to hand out to non-technical folks trying to understand why we care so much about automating everything.

If you're already doing DevSecOps work, Investments Unlimited is probably going to be too light on details for you. Hopefully, they'll include more actionable tips in the next version of the DevOps Handbook.

Heroism is an Anti-Pattern

Sat, 22 Jan 2022 00:00:00 GMT

I'm generally not a fan of all the criticisms of "hustle culture," but my developer Spider-sense is triggered whenever I see a company complimenting heroic actions on project teams. Any time I hear phrases like: "The team really had to put in the nights and weekends," "_________ worked all weekend," or anything referencing burning midnight oil, I cringe a little.

I'm not against hard work. I understand that sometimes you need to throw down a few extra hours to get something through the gate. What I'm against is seeing that as a good thing. Heroics are not a cause to celebrate; they are a red flag.

Why not encourage heroic behavior?

Burnout and Turnover

Consistent long workweeks contribute to high turnover and burnout. Finding and onboarding new team members is expensive. This is especially important when a single team member performs the heroics to keep the project moving. When that person leaves, you're in a considerable amount of trouble.

Diversity

If you want a dynamic organization of people from various backgrounds, pay attention to work-life balance. Not everyone on your team can work tons of hours. Many people have family responsibilities, and encouraging heroics pushes those people out of your organization. If your goal is to employ a crew of single 20-somethings that all resemble each other, then you don't need to worry about this one.

Lack of Productivity

Extra hours bring diminishing returns in productivity, eventually reducing overall productivity. Those late-night code changes are probably not going to be the best work. As those poorly implemented changes add up, your codebase becomes less maintainable, further slowing down development.

Shoddy Products

High-pressure situations where people are constantly tired and burnt-out lead to low-quality products. It's hard to care about your customers when tired.

What should we do instead?

One of the critical tenants of agility is creating a sustainable workflow system. You build an engine of work; you continuously enhance it through automation, team cohesion, and refinement. Over time, the 1% improvements add up to a high level of productivity. Everyone wins.

Heroics throw a wrench in that system. It's an indicator that something needs to change. Here are a few places you might want to look if you're trying to increase your workflow:

Set More Realistic Commitments.

When using sprint-based frameworks like Scrum, it's easy to underestimate work and overcommit in a sprint. Misestimation is especially easy if the development team isn't estimating or setting their sprint commitment. Also, realize that getting a consistent velocity will take a few sprints when projects start.

Automate Processes

Use automation to reduce the number of interrupts in your day. If you must do it consistently, write a script to automate it. Even small tasks can break you out of the flow.

Get Clarity

Lack of clarity is a giant productivity killer. It's much harder to do a nebulous task than a well-defined one. It's much harder to test a sizeable nebulous task than a well-defined one. This lack of shared understanding causes work to bounce around the team as everyone figures out a shared definition of the work. Spend time refining work to small achievable chunks.

Document Standards

Rehashing discussions is a productivity killer. Spend a little extra time to document some standard practices for your team. Create checklists or refine your Definition of Done. Documentation also helps you with onboarding since you can point new folks on your team to the docs.

Eliminate Tribal Knowledge

If you rely on a single person to do specific tasks on your team, that person will constantly be bottlenecking your team. Spread that knowledge around through documentation or pairing. Similarly, work to find and eliminate gatekeepers.

Your team should be able to complete work without relying on other teams. If another team regularly blocks your progress, spend some time with them to automate that process or eliminate it. It isn't easy, but it usually pays off.

Work Hard, but Not Too Hard

Heroism may make for exciting stories, but exciting stories don't create excellent software. Hard work is essential, but if your project relies on heroics, it's time to make changes. Look at your processes, find bottlenecks, and work to reduce or eliminate them.

The Most Important Developer Skill

Mon, 03 Jan 2022 00:01:01 GMT

One thing that drives me crazy in this field is how some folks think it's a weakness to look something up. While you should spend time deepening your knowledge of your chosen tech stack, you aren't going to be able to learn everything. Even if you do, it's going to change. The last time I checked, software development was about solving problems, not feeling smart. Therefore, my "must-have" developer skill is resourcefulness.

When I say "resourcefulness," I mean the ability to find solutions to the problems you run into in your day-to-day work. Resourcefulness is different from learning new technology. You aren't going to watch a Pluralsight video to remember the LINQ GroupBy syntax, but you might if you're learning LINQ for the first time. Both skills are valuable, but there's a difference.

It's essential that you know when to hit the proverbial books. You'll learn three tips to become a more resourceful developer in this post.

Read the Docs

The first thing many developers do when they don't know something is to hit up their favorite search engine and go to town. While there's no shame in searching the web, it should be a last resort.

When I started developing web applications, web searching was the main way to find solutions. There weren't many well-written docs sites. Then Stack Overflow came along and made web searching much more productive. Stack Overflow was the defacto documentation for many technologies. Now, my first move when I need to figure something out is to hit up the docs.

We are so lucky nowadays to have top-tier developer resources. We live in a golden age of free knowledge. Companies like Microsoft, Amazon, and Google have whole teams dedicated to creating and maintaining their docs. It's fantastic, and I don't know why more people don't use it.

To illustrate why web searching is not ideal, let's search for JavaScript array methods. I generally use DuckDuckGo. The first result is a link to www.w3schools.com. w3schools is not a good resource, but somehow, they top many web searches.

A far better resource for anything related to the base web platform (JavaScript, HTML, and CSS) is the Mozilla Developer Network (https://developer.mozilla.org/en-US/) aka MDN. Their descriptions are more detailed and accurate than anything you'll find on w3schools. Instead of random searching, I'd start there. Even if I do a web search, I'll often add "mdn" (or a "site:developer.mozilla.org" if you like typing) to my search query, so the MDN comes up first.

Here are some other excellent docs sites you should have bookmarked if you work with these platforms. It's not an all-inclusive list, so you might have to do some digging for your preferred tech stack.

JavaScript/CSS/HTML - https://developer.mozilla.org/en-US/

Angular - https://angular.io/docs

React - https://reactjs.org/docs/getting-started.html

Typescript - https://www.typescriptlang.org/docs/

Anything Microsoft - https://docs.microsoft.com/en-us/

--> Azure -- https://docs.microsoft.com/en-us/azure

--> ARM/Bicep - https://docs.microsoft.com/en-us/azure/templates/

--> ASP.NET Core - https://docs.microsoft.com/en-us/aspnet/core

--> Entity Framework Core - https://docs.microsoft.com/en-us/ef/core/

Read the Source

Most of the tools, libraries and frameworks we use to make software are open source. Sometimes it's easier to dig past the docs and look directly at the code. If you can't find what you need in the docs, head over to the relevant Github repo. There's a good chance that you can dig into the code and find what you need (or a bug you can fix). Look for examples, wiki docs, and unit tests. You can learn a lot about a framework by looking through its unit tests.

Sometimes, you can also find repos of examples. When building ARM or Bicep templates, it's a good idea to start from an existing template. Microsoft has a whole repository of starter templates: https://github.com/Azure/azure-quickstart-templates/

Related to looking at Github repos, you can also rely on the super hacking technique of viewing the website's source. When I learned the Azure DevOps API, I found it easier to F12 and watch the API calls from the Azure DevOps website than fish through the documentation to find the call I needed.

It's also an excellent way to find bugs. I ran into a showstopper Azure DevOps bug. I put in a report, and they couldn't find the issue. I opened dev tools and found the exact line of code that blew up. I added that information to my bug report, and the Azure DevOps team fixed it in a week.

Build Something Small First

If you're having trouble getting something to work, build a scaled-down version to prove the concept. Trying to get the whole machine to work can bog you down. Scale down, make it work, and integrate it back into your primary codebase.

Additionally, if you're making something complicated, start with something simple first. I see too many developers try to do everything at once and run into roadblocks (especially on front-end projects). Scale back your solution, build something simple that works, and then evolve it to something complex. If you trip up along the way, you can at least fall back to something that functions.

Conclusion

Too many developers are scared to admit they look things up. It's like some pointless badge of honor not to use resources. Resourcefulness is a real developer superpower. I'll take a junior dev who knows how to figure it out over a senior developer who's too proud to look it up every day of the week. I'd rather spend 5 minutes looking something up than 2 hours trying to remember it, and so should you.

Code First Microservices With a Single Database in Entity Framework Core

Tue, 21 Dec 2021 00:01:01 GMT

All of your microservices would have their own database in the ideal universe. Unfortunately, enterprise development is not in the ideal universe. When provisioning databases is complicated, you often get stuck with a single database per environment. If you want to work around this constraint and maintain some semblance of data separation, you can use schemas to separate your services. In this post, you'll learn how to use a single database to support multiple instances of EF Core.

Here's how to do it.

First, override OnModelCreating and add a call to HasDefaultSchema() in your DbContext setup. This code sets all of the tables for your database to your chosen schema.

public const string  SCHEMA = "character";

protected override void OnModelCreating(ModelBuilder modelBuilder)
{
    modelBuilder.HasDefaultSchema(SCHEMA);
}

Then, in your DbContext setup in Program.cs (or Startup.cs), add a call to MigrationsHistoryTable() in your services setup. This code will set the migration table to the one you specify, including the schema.

builder.Services.AddDbContext<AppDbContext>(options =>
  options.UseSqlServer(builder.Configuration.GetConnectionString("db"), 
                       x=> x.MigrationsHistoryTable("__EfMigrations", AppDbContext.SCHEMA)));

From here, you can continue to use Entity Framework Core as you usually would. Everything should appear in your chosen schema. Rinse and repeat for each of your services.

You can customize your migrations with EF Core, so each service has its own migration table. While this isn't ideal, it'll tide you over until you can move to the cloud or get more databases.

Five Tips To Pick Better Developer Tools For Your Projects

Mon, 07 Dec 2020 00:22:16 GMT

Have you suffered on a project due to lousy tool choices? ("Tool" can mean many things, but in this context, we're talking about developer tools: utilities, test runners, DevOps tools, libraries, and frameworks.)

Did the previous architect on your project evangelize some hipster JavaScript library with no documentation, and now no one cares about it because all the hipsters are using NewThing.js?

Is some far-off silo team trying to force some enterprise-grade hot garbage on your crew because the sales rep takes them out for sushi?

Is it finally your turn to make some choices, and you don't want to screw it up?

As someone who's been building software for well over a decade, I've spent a lot of time in discussions about picking tools and suffering from the consequences of those discussions. This post will equip you with some tips to help you avoid shooting yourself in the foot.

1. People and Processes Beat Tools

Tools exist to support people and processes. For example, you should adopt a CI/CD tool to support your agile process. However, tools don't create quality processes. People do that. If you adopt a CI/CD tool, like GitLab or Azure Dev Ops, there's no guarantee that you'll improve your DevOps practices. Adopting Azure DevOps isn't going to fix heavyweight change approvals. If you release every six months, the automation isn't going to help you. Tooling makes it easier to make those changes, but it's on you to do the heavy lifting.

I've seen too many organizations bring on a tool and claim victory without changing the underlying processes. If you have a legacy DevOps tool but commit to the cultural changes required, you'll crush an organization with fancy tools paired with flawed processes. Good tooling choices can help you support a good culture, but the culture needs to come first.

2. Pick Tools You Can Integrate

You should strongly prefer code and command-line based tools. You can easily integrate command-line based tools into automation scripts, batch processes, and DevOps tools. I've seen many complex enterprise tools that have cutesy GUIs, but you can't run them from the command line. You can't automate a cutesy GUI.

Code-based tools are also more useful than their GUI only counterparts. If you can represent your configuration as code, you can store that code in source control and get access to all the edits made to it. It's also a lot easier to share a code file than a sequence of 47 mouse clicks in a GUI.

You don't have to use command-line only tools. For example, Postman is GUI-based, but its configuration can be saved to a .json file and run from a command line. I'm all for making things usable, but usability includes the ability to run the tool from the command line.

3. If You Are Choosing a Tool For Another Team, Keep It Simple

Have you ever had to adopt an annoying enterprise tool that was chosen by a committee based on the number of feature checkboxes on their website, even though the thing is so complicated it requires a Ph.D. to operate and no screen takes less than five seconds to load?

As a rule, I think individual teams should choose their toolchain. The further away you get from the people using the tools, the harder it is to make good choices. However, in enterprise contexts, that's not always politically or economically feasible. For example, you aren't going to let each team pick their own API gateway.

Teams that get to pick a tool for everyone can fall for "checkbox syndrome," where choices are made based on the checkboxes on the vendor's website and not real-world use. When you don't have the context gained from day-to-day use, it's easy to pick whatever tool has the most features. Most teams would prefer something simple.

Additionally, having a single team in charge of maintaining a tool incentivizes ease of management over ease of use. This is a classic case of optimizing a single group at the expense of every other group. As a centralized team, you should take on the complexity to make it easier for the other teams. There are two ways you can take on complexity for other teams.

First, support multiple tooling options. Support a range of tools to cover the levels of different complexity teams need. Keep simple tools for teams that need them and complex tools for the teams that need the extra features.

Second, find a way to abstract the complexity away. Support a facade that covers the everyday use cases or build an outward-facing product that uses the complex tool as a base. For example, if your team wants everyone to use Kubernetes for app hosting, abstract away some of the complexity with scripts. If that's not feasible, build templates and starter kits to speed things up.

4. Avoiding Bad is More Important Than Finding the Best

Software developers tend to be optimizers. We have an innate drive to find a better way to do something, to refactor code for an extra ten percent performance, or to learn new keyboard shortcuts to be a little faster.

This constant drive for improvement is built into our development methodologies as well. Most flavors of agile have the concept of a retrospective and encourage continuous improvement. The DevOps movement is all about getting better and faster with each iteration.

Typically, this is a good thing. We should strive to get better. However, there's one place where this drive towards maximization doesn't always pay off. That place is tool selection. If you want to suffer less in your software career, I'd suggest a new strategy. Instead of picking tools based on being "the best," find tools that work well enough and move on.

A tool that isn't perfect, but is usable and fast, will beat a purpose-built "perfect" tool most of the time. Pick tools that are simple and easy to change. That way, when you make a terrible choice, you can reverse course. A collection of simple tools will generally beat a bloated "enterprise" solution.

5. Keep it Mainstream

As a developer, I love trying out new things and finding new ways to do my work. Learning about and adopting new technologies is one of the great things about being a developer.

However, when picking a tool stack for your new project, stick to a mainstream option. The biggest culprit for hipster tooling is in front-end development. For a while, a new JavaScript framework or CSS pre-processing tool came out every ten minutes. Most of those new libraries burned out in a few months as the hipsters moved onto something new. Just use React (or Angular or Vue) and be happy. Keep your hipster inklings to craft beer and vinyl records.

Be Pragmatic

Picking tools doesn't have to be a painful process. Look for simple tools that are easy to integrate with your existing pipelines and code bases. Avoid bloated enterprise solutions and bleeding-edge hipster tools. Focus on people. With a little pragmatism and forethought, you can find what you need to get the job done and get back to crushing bits.

Why You Should Be Skeptical of Developer Career Advice

Thu, 18 Jun 2020 00:22:16 GMT

I was recently at a (socially distanced) high school graduation party. Like most graduation parties, the older adults doled out a big helping of partially solicited career advice. We mostly encouraged the poor graduate to enter our fields, which included software development, accounting, science, engineering, and skilled trades. Given all the conflicting advice, she's probably going to end up as a Star Wars themed life coach. The contradictory information made me think about some of the career advice that folks in the developer community dispense and why we should be skeptical about it.

For example, one of the perennial debates in the developer sphere is whether to be a generalist or a specialist. Most of the developer career gurus recommend specializing. The common refrain is "the riches are in the niches." Ideally, the tiniest niche you can get away with.

Specializing is excellent for getting people to pay attention to you, but does it make you a more productive developer? Would you rather have someone on your team who is the master of one tiny domain, or would you rather have a resourceful generalist who is good at "just in time" learning? Unless my team lacked knowledge of that one specialty, I'd go with the generalist.

Additionally, technology changes constantly. While a narrow specialization might be awesome during the time a technology is widespread, most technologies fall out of favor within five years. A robust general base of skills allows you to jump on whatever the next train is without much fuss. Resourcefulness is the ultimate developer skill, and it's a lot easier to cultivate as a generalist.

Regardless of your stance on the topic, the reality is that specialist vs. generalist is a false dichotomy. You have a portfolio of skills, and you need to manage them. You also have a personal marketing strategy (even if it's non-intentional). These two things overlap but are different. Use a specialization to break through the noise, but generalize to be effective.

We could spend considerable time on this topic, but let's look at a more interesting question: Why do people recommend specialization?

Reasons to Specialize

Marketing

Having a narrow specialty is better for personal marketing. It's a lot easier to break through the noise if you're a big fish in a small pond. Most specialization advocates will admit that general skills are essential but downplay it because it's easier to signal boost specialization.

Effectiveness

Depending on how you define "generalist," having a specialization makes sense. While knowing how to contribute to the whole stack of an application is useful, spending three months learning the basics of every backend language isn't. It's crucial to collect skills that mesh well with each other. Another common career advice trope is to learn a new programming language every year. While this is a good career strategy in the first few years, it's a career strategy with diminishing returns. Once you learn a couple of languages from each paradigm, you can usually pick up a new language with little effort.

Ease of Delivery

Most people on the Internet tend to take extreme stances on things. It's a lot easier to grab attention by staking out a radical claim than saying the truth, which is generally some flavor of "it depends."

Digging Deeper

That's not an exhaustive list of reasons, but I'd like to point out a few things about the list. First, there are some situations when you need to specialize more and other situations where it might be better to generalize. The truth is complicated and different based on your career goals. You could draft some general principles, but it'd make for a lame soundbite.

Second, part of the reason people recommend specialization is that it's easy to make that recommendation. The Internet is a noisy place. It's harder to enumerate criteria and use cases. Simple messages are more comfortable to digest, even if they aren't 100% accurate.

Finally, the people who recommend deep specialization don't follow their advice. Most public-facing developers have a ton of non-development and general software skills. Even if they pitch a specialty for marketing, that specialty is based on a ton of general software development and technical skills.

While most career advice is well-meaning, we need to remain skeptical. Don't reject everything you read, but here's a few questions to ask yourself to think deeper:

Is this viewpoint oversimplified?
Does this person follow their advice, if not, why?
What are the bounds of this position? Most positions on the Internet are the extreme version of whatever the author is pitching.
When does this advice apply? No advice applies to everyone in every situation.

Conclusion

It's great that many developers want to share advice with people who are entering the field. The fact that the Internet makes this easier is fantastic. However, you need to be careful. Think about what's being presented, who's giving the advice, and why. Internet culture encourages simplifications, and those simplifications can distort the truth.

The next time you read some career advice, dig a little deeper, and figure out the details. A little skepticism will vastly improve the quality of the information you hear from others.

The Case for DevOps: A Summary of Accelerate

Fri, 22 Feb 2019 08:00:00 GMT

During my travels as a developer, I find myself having the following conversations far too often. Have you seen any of these?

Timid Developer: "I’d like to do unit tests on my project, but my boss won’t let me. He said we don’t have enough time to do them."

Me: "You shouldn’t be asking your boss to do unit tests, just do them."

Beleaguered Developer: "I’d like to adopt modern development practices at my organization, but we’re not a software company, so we can’t adopt the latest practices."

Me: "Every company is a software company, especially the insurance company you’re at now."

Obstinate Developer: "Why should we adopt <insert modern development practice>? Why can’t we just do it the old way?"

Me: "<facepalm>"

I wish there were a book that I could throw at people that would use science to show the value of modern development practices. It turns out, this book exists, and it’s called Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations.

The authors, Jez Humble and Gene Kim, are behind other great DevOps books like The Phoenix Project and the DevOps Handbook. Their previous books focused on how to do DevOps, but they wondered how much these practices helped organizations.

To do this, they turned to organizational scientist Nicole Forsgren, Ph.D. She applied academic research methods to determine which development practices make things better. Accelerate comes from their research from 2014 to 2017. Between the three of them, they make a strong case for modern DevOps practices.

Methodology

The results from this book come from studying over 2,000 organizations over four years. A whole section is devoted to the various research methods they used and why they work. For our purposes, I want to focus on the metrics they used to evaluate performance.

Measuring software delivery is difficult. Some measures of delivery, like lines of code, have obvious problems. Using lines of code as your engineering performance metric is like using airplane weight. More is not necessarily better.

Other measures have less apparent problems. In many organizations, you have two different areas in IT, software development and operations. Managers often measure the departments in different ways. They evaluate developers by the features they deliver. Operations folks are assessed by how stable they make the environment. These different goals create a perverse incentive structure where software developers throw difficult to deploy code over a wall and ops slows them down with a maze-like change management process.

To effectively measure performance, you need metrics for the whole process, not just specific teams. Use global metrics to get everyone on the same page. In Accelerate, they settled on four primary metrics.

Deployment frequency<br> Small batches delivered often are ideal.

Delivery Lead Time<br> Overall lead time can be difficult to measure due to the "fuzzy front end" (ideation, requirements gathering, etc...). Delivery lead time measures the time from commit to deploy.

Mean recovery Time<br> Bad things happen. How long does it take to fix them?

Change Failure Rate<br> How many changes fail? Smaller changes generally mean fewer of them fail.

Practices

When evaluating the performance of an organization, people often use maturity models. Each aspect of software delivery is assessed based on a target. Once you hit that target, your organization is "mature" in that category. Unfortunately, that thinking doesn’t work. We build software and the landscape we’re in changes constantly. There’s no such thing as "maturity" when tools shift every 5-10 years.

Instead of looking at maturity, evaluate capabilities. In Accelerate, they identified several organizational capabilities that lead to increased business performance.

Capabilities for Improvement

Version Control
Trunk Based Development
Test Automation
Shifting Left on Security
Continuous Delivery
Loosely Coupled Architectures
Empowered Teams
Seeking Customer Feedback
Working in small batches
Team Experimentation
Lightweight Change Approval Processes
Monitoring / Proactive Notification
WIP Limits
Visualizing Work
Westrum Organizational Model
Supporting Learning

Your organization is probably using many of these practices today, but most organizations have not mastered them all. You can continue to improve in all these realms. The research in Accelerate showed that the top organizations were continuing to grow. They didn’t hit "maturity" and stop. They continually develop to get even better at software delivery.

Stats

Accelerate is chock full of statistics, but here are a few of the most impactful ones. The company divided companies into three categories (high, medium, low) based on their performance. They then measured some of the differences between the groups.

High performers vs. Low Performers: Software Delivery<br> 46 times as many code deployments<br> 440 times as fast commit to deployment time<br> 170 times faster mean time to recover<br> 5 times lower change failure rate

High performers vs. Low Performers: Org Performance<br> 2x as likely to exceed organizational objectives: profitability, productivity, market share<br> 2x as likely to exceed noncommercial goals like customer satisfaction<br> 50% higher growth over three years<br> Employees are 2.2 more likely to recommend their organization as a great place to work

Surprises

While most of this book confirmed things I already knew about, there were a few surprises. The biggest surprise for me was that organizations that were in the middle frequently had high error rates than either lower performing or high performing organizations. They refer to it in the book as the "j-curve". It makes sense that there are some growing pains associated with adopting new practices, and it indicates promoters of dev ops practices need to communicate that gap when trying to move their organizations forward. Wary organizations might backslide if they perceive the changes are having an adverse effect.

The reality is that speed and quality positively correlate. Software development is about tradeoffs, but this isn’t one you have to make. You can have a screaming fast release process and have a lower change failure rate. A big part of the magic here is working in small batches. Small batches are easier to understand, which makes it easier to develop and test.

Another big surprise was the emphasis on trunk-based development over other branching workflows. More involved styles like git-flow are suitable for large open source projects, but for most folks, it pays to keep it simple.

We all know that automated testing is essential, but it turns out that those automated tests have a far greater value when they are written and maintained by the developers. This doesn’t mean that we need to get rid of QA folks. They perform valuable and important work. What doesn’t work is throwing your code over the wall to a testing department that may or may not have automated regression testing. You need to build your tests on a cross-functional team where the developers and QA folks can work together to create automated tests. These tests need to be useable by everyone, including by developers on their machines.

There’s this idea in software development that to use the latest processes, you need to have access to the latest tools. People who aren’t using the latest and greatest technologies need not apply. The authors of Accelerate didn’t just focus on cutting edge organizations; they looked at all sorts of organizations using all sorts of processesThis including companies running on mainframes and companies still using waterfall-style processes. They found that all companies benefit from DevOps practices, even ones running on older technologies. While using newer technologies can help, there are no excuses for not moving forward.

Who Should Read This Book?

This book is excellent for anyone who needs a persuasive argument for adopting DevOps practicesThis including managers, consultants, and coaches. Additionally, developers and other delivery folks may find this interesting. If you're looking for more of a how-to than a why-to, then skip this book and get yourself a copy of the Dev Ops Handbook.

A Case for Modern Delivery Practices

As we continue to evolve the way we build software, it’s important to understand why these changes matter. Accelerate shows us, scientifically, why modern practices matter and how they can create better-performing organizations with happier employees.

Do Your Apps Spark Joy?

Tue, 22 Jan 2019 23:00:00 GMT

<small>Image from Web Summit via Wikimedia Commons</small>

What can this tiny Japanese lady teach you about technology?

This is Marie Kondo. She’s become a cultural phenomenon with her book The Life-Changing Magic of Tidying Up and her Netflix show Tidying Up. She created the KonMari method, which is a decluttering strategy where you get rid of anything that doesn’t "spark joy". You go through each of your belongings and see if it gives you a visceral spark of happiness. If there’s no spark of joy, you thank the item and toss it into the donation bin. The upshot is that you evaluate everything in your life based on whether it makes you happy and helps you achieve your goals. Instead being a slave to your possessions, you have the things you need to live the life you want.

As software continues to eat the world, there’s been a backlash against technology, especially social networks and mobile apps. The common narrative is that nefarious app developers are using advanced machine learning techniques to turn us all into mindless phone zombies.

I find this thinking unsophisticated. I acknowledge there are issues surrounding phone addiction, filter bubbles, censorship, and the toxicity of social media. Social media can cause anxiety and depression, but there’s nothing special about the apps on your phone. It’s no different than TV or any other media. This story is as old as history. Whenever a new form of media comes on the scene, there’s a bunch of people who complain about it. It happened with writing, books, radio, TV, and now it’s happening with the Internet and social media.

Technology is a tool and tools must be used properly. If you cut off your finger with a table saw, it’s not the table saw’s fault. It’s your fault for not using the tool properly. Instead of falling for the hyperbole, make the technology in your life work for you. Apply the KonMari method to your technology life. Go through your devices, apps, and settings and figure out what sparks joy. Instead of being a slave to your technology, make your technology work for you.

I routinely go through my apps, frequently visited sites, and social networks and get rid of the things that don’t work for me. You should also regularly declutter your technology life. The process is simple, first categorize your technology life. I use categories like social media, infinity pools (ie. YouTube), and communication apps. For each category, work through each app or site in your list.

Ask yourself the following questions:

Does it make me happy?
Does it help me achieve my goals?
Can I modify this technology to make me happier or better achieve my goals?

From there, either keep it, delete it, or modify it to better fit your goals. When you’re done, you’ll have a more functional tech life. Here’s some of the choices I’ve made. You’re obviously going to have different needs (and therefore make different choices), but you'll get an idea of what to do.

Social Media

There are lot of people who think you should immediately nuke any and all social media from your life. At its worst, social media can be a misery inducing time suck. It’s easy to lose hours scrolling on Facebook or Instagram. Not only that, but people tend to post their best moments on social media. They craft posts that portray their life as an amazing fun fest. Your life can’t match up to that hype. If that wasn’t enough, some people use platforms like Facebook and Twitter as emotional dumping grounds. Spewing outrage and vitriol. There’s always some new thing to be angry about. It’s almost never anything important, but the constant cycle of outrage is mentally exhausting.

However, social media isn’t always a dumpster fire. It’s a great way to keep track of your friends, especially ones that don’t live near you. If your core group of friends are on Facebook, you can also use it to plan events. Another advantage of social media is that you can often have conversations with people you otherwise wouldn’t be able to get access to.

Go through each of your social networks and evaluate if being on that network helps you. If you’re not getting any value from the network, nuke your profile. If you get value out of the network, but it's taking too much of your time, consider removing the app from your phone or turning off its notifications. Most social networks have a web interface that works as well as the app and doesn’t hit you with constant notifications.

Here’s what I found when I evaluated each of the social media networks I was on.

Facebook

Facebook was a huge time suck for me. I started my account in 2006 back when Facebook was only for college students and would check it several times a day.However, I find it delivering less and less value as time goes on. Several of my friends have left the platform and 95% of what I see doesn’t help me in any way. I recently deactivated my Facebook profile. I may reactivate, but even if I do, I’m still going to go on regular Facebook breaks. At this point, it’s mostly a waste of time, so it gets the boot.

Twitter

I find Twitter both fascinating and irrepressibly toxic. The toxicity keeps me from spending too much time on the platform, which is almost a feature. I keep my Twitter account because it’s professionally useful to me. I find conferences to speak at and have interesting conversations with other tech people. I make use of blocking and muting to filter out as much outrage as I can, but you can’t get it all. Twitter gets to stay, but I don’t let it notify me and filter a lot.

I use LinkedIn professionally. I check their website occasionally, but it's not something I use very often. It does what it’s supposed to do, and it doesn’t trigger addictive behavior like other networks.

Instagram

I tried out Instagram a while ago. The platform is more positive than Facebook or Twitter, but it doesn’t help me in any way. I deactivated my Insta account. It was never a big draw for me, so I’m not really going to miss this one.

I use Pintrest for finding home decorating ideas and woodworking projects. I don’t use it every day, but it’s a good choice for some project inspiration.

MySpace

Yeah no, just kidding…

Infinity Pools

Infinity pools are websites that have infinite content. You can spend endless hours reading, watching, or listening. Infinity pools come in two flavors. The first are media apps like Netflix, YouTube, or Spotify. Out of those three, the big time-suck for me is YouTube. Instead of deleting the app, I put it far away from my main apps in a folder. I also trained the YouTube algorithm to filter out entertaining but useless videos. In your main YouTube feed, you can click "Not Interested". Do this enough times and YouTube will stop showing you useless videos. After doing this, my YouTube feed is mostly educational videos relating to my career and hobbies, which is exactly what I want.

The other type of infinity pool is news. There’s an infinite stream of news articles on the Internet. I spend a lot of my time reading, but I curate my feed for the best news. I don’t visit time suck sites like Cracked, Buzzfeed, or Mental Floss. I also use RSS feeds to get most of my news. That way, I’m not stuck on someone’s website getting inundated with links. People say RSS is dead, but it’s one of the best ways to get quality news content delivered to you. Another good way to get your news is through newsletters. There are tons of great newsletters that will kindly filter out all the crap, giving you the most important news.

When dealing with news, it’s important to remember that most news is entertainment, not information. How much of the "news" is just reporters reacting to some nonsense they saw on social media? Spend some time filtering out the trash and you’ll be much happier.

Communication Apps

I use email and a bunch of chat apps on my phone. Instead of social media, I talk to my friends directly. I turn down the notifications on most of these apps, especially email. No one needs a response to an email immediately. Go through each of your communication apps and think about whether they need to be on your phone and if you need their notifications. Delete what you don’t need and turn down the rest. Chat apps are asynchronous, take advantage of that fact.

Things to Add

After deleting the apps and accounts that don’t improve your life, consider adding in some apps that will. There are hundreds of apps that can support your goals. Find them and use them. Give helpful apps a prominent place on your home screen. Here’s a few apps that I use to help foster healthy habits and enjoyment.

Strong – Strong is a workout tracker for weightlifters. You can enter your routine and it’ll help you keep track of your weight lifting goals. There are equivalent apps for runners, but I don’t run, so you’ll have to find those yourself.

Zero – Zero is an intermittent fasting tracker. It’s easy to use and free.

Oak – Oak is a free app that has breathing exercises and guided meditations. My kid is a big fan of the "box breathing" exercise.

Done – Done is a habit tracking app that helps foster healthy habits.

Audible and Overcast – I listen to audio books and podcasts all the time. It’s an easy way to get more "reading" and learn while doing mundane activities like housework or commuting.

Trello and OneNote – I use Trello and OneNote to organize thoughts, projects, and to-do lists. Both of these apps are fantastic and I use them all the time.

It's Time to Declutter Your Tech Life

It’s time to take a flamethrower to your digital clutter. Go through your digital life and evaluate the apps, social networks, and sites you use. Think about which ones help your life and which ones don’t. You are not a slave to your technology. Your technology works for you. If that app or service doesn’t "spark joy", then either modify it so it does or send it to the bit bucket.

Get The Boring Stuff Right: Talk Resources

Fri, 01 Jun 2018 22:12:00 GMT

If you attended my Get The Boring Stuff Right tech talk, you'll know that I mentioned a ton of different resources to update your skills. Here's a list of those resources. This is some my favorite sites and books that you can use to level up.

Go forth and conquer!

I did a post about the content of this talk on the That Conference Blog.

Get The Boring Stuff Right

Slides

Mindset

Carol Dweck is the main researcher behind the growth mindset. She has both a book and a TED talk. (Along with lots of other research)

Mindset Carol Dweck TED Talk

Design and UX Books

There's tons of great resources to build up your design and UX skills. These are some of my favorites.

Design for Hackers Don't Make Me Think Design of Everyday Things

Smashing Magazine and A List Apart are two of my favorite sites for UX related stuff.

Writing and Communication

Writing and communication skills are extremely important. The best book I've read on the topic is On Writing Well. In addition to reading books on writing, make a regular habit of writing by keeping a journal or blog.

Conflict Resolution

The two best resources that I've encountered on the topic of conflict resolution are Nonviolent Communication and Crucial Conversations. More people should read both of these books.

Persuasion

The best book on general persuasion that I've read is Influence. As an added bonus, you'll be better prepared to deal with the various compliance tactics employed by sales and marketing professionals.

Critical Thinking

Critical thinking is a broad subject, but one of my favorite resources related to critical thinking skills is the Farnam Street blog. The Wikipedia articles on Cognitive Biases are also good. For a general overview of the different mental systems of the brain, check out Thinking Fast and Slow.

Stress / Ego Management

There's no shortage of resources on this topic, but here's a few I found useful:

Ego is The Enemy A Guide to the Good Life: The Ancient Art of Stoic Joy [Grit](https://amzn.to/2JkG35M

Adventures in Learning Azure

Tue, 06 Mar 2018 22:39:54 GMT

<span style="font-weight: 400;">Being a developer is committing to a lifetime of learning new skills. Over the past few weeks, I’ve been working on grokking cloud architecture on Azure. Like many devs on the Microsoft stack, I’ve played around with Azure. I built a few resources and watched some demos, but until recently, I hadn’t taken the time to really invest in the skill set. I never felt like I had a good understanding of Azure as a whole. In this post, I’m going to talk about my experiences learning about Azure over the past few weeks.</span>

<span style="font-weight: 400;">The toughest part of learning Azure is that it’s huge. “The cloud” is nebulous by definition, and Azure doesn’t disappoint. Azure isn’t a single thing, but collection of many different products and services. This abundance makes it tough to get started.</span>

<span style="font-weight: 400;">When thinking about Azure, you can divide the services into a few large buckets. Here’s a high level overview of what’s in Azure:</span> <h3><span style="font-weight: 400;">Virtual infrastructure (aka Infrastructure as a Service or IaaS)</span></h3> <span style="font-weight: 400;">In Azure, you can build virtual machines, virtual networks, load balancers, and other virtual appliances. If it exists in a data center, you can probably make one in Azure.</span> <h3><span style="font-weight: 400;">App Services (aka Platform as a Service or PaaS)</span></h3> <span style="font-weight: 400;">App services host specific kinds of applications without the need to configure servers. You usually run these on top of VMs, but you don’t need to configure them. You just pay for the compute resources. Azure has app services for web applications, apis, mobile apps, and functions.</span> <h3><span style="font-weight: 400;">Identity, Secrets, and Security</span></h3> <span style="font-weight: 400;">Azure has several services that support security and identity. This includes several flavors of Active Directory and Key Vault, which stores application secrets. Azure also has several different mechanisms to scan for security issues.</span> <h3><span style="font-weight: 400;">Data Storage</span></h3> <span style="font-weight: 400;">If you have data, Azure can store in a ton of different ways. You have your basic storage accounts, which can hold blobs, queues, files, and json objects. You also have Azure SQL Server and several other hosted SQL databases (including Postgres and MySql). If you need worldwide scale, you can use Cosmos DB. Azure also has a pile of big data tools like HDInsight and Stream Analytics.</span> <h3><span style="font-weight: 400;">APIs</span></h3> <span style="font-weight: 400;">Azure has a lot of APIs you can take advantage of in your applications. This includes things like Cognitive Services, Notification Hubs, and Multifactor Authentication. You can leverage these tools to shortcut things you used to have to do yourself.</span>

<span style="font-weight: 400;">This is by no means an exhaustive list. Azure updates constantly and new offerings are added all the time.</span> <h2><span style="font-weight: 400;">Finding a Roadmap</span></h2> <span style="font-weight: 400;">To help navigate this landscape, I chose to base my studying on the Microsoft Azure certifications. While I still haven’t convinced myself to take the actual exams, the exam outline is a useful map for learning. I’ve always been on the fence about the actual value of developer certifications. Much of what’s covered is stuff that’s easy to look up in the docs and developer certs lack the clout of networking certifications. Software also changes so fast that certs tend to either rapidly expire or are out of date. Azure certifications update every three months, which makes it hard to find solid resources. Regardless of the value of the certifications, the outlines are useful.</span>

<span style="font-weight: 400;">Here’s the two certs I looked at <a href="https://www.microsoft.com/en-us/learning/exam-70-532.aspx" target="_blank" rel="noopener">https://www.microsoft.com/en-us/learning/exam-70-532.aspx </a></span><a href="https://www.microsoft.com/en-us/learning/exam-70-535.aspx" target="_blank" rel="noopener"><span style="font-weight: 400;">https://www.microsoft.com/en-us/learning/exam-70-535.aspx</span></a> <h2><span style="font-weight: 400;">Udemy</span></h2> <span style="font-weight: 400;">I began by working my way through a 70-532 course on Udemy. I watched all the videos and built plenty of demos while going along with the course. The course claims to prepare you for the exam, but it doesn’t some close to the level of detail you’d need. It’s an OK overview, but the more I learned about Azure, the more I felt like this course was a waste of my time.</span>

<span style="font-weight: 400;">After reviewing some other courses from Udemy, I found the platform to be hit-and-miss. Udemy also has a pretty serious piracy problem where pirates will steal courses from other people and host them on Udemy. While the Azure course I saw was decent, I can’t recommend using Udemy as a first rate source for developer content.</span>

<span style="font-weight: 400;">Here’s the course I used <a href="https://www.udemy.com/70532-azure/learn/v4/overview" target="_blank" rel="noopener">https://www.udemy.com/70532-azure/learn/v4/overview</a> </span> <h2><span style="font-weight: 400;">Pluralsight</span></h2> <span style="font-weight: 400;">After working my way through that course, I searched for other resources. Microsoft offers free Azure training through Pluralsight. It’s been a while since I’ve checked out Pluralsight and they’ve done a lot to improve the platform. The last time I used it, Pluralsight had cranked up their video acquisitions. This was good for variety, but choice overload made it nearly impossible to figure out what course to take. Nothing sucks quite like ten courses that look identical. Fortunately, Pluralsight introduced learning paths. Now, instead of sorting through hundreds of courses, you can sort through a few dozen learning paths. Each path has a handful of courses that go from beginner to advanced. You can also use their handy Pluralsight IQ function to gauge your skill level. It’s like a mini certification test. They’re also free, so check them out if you’re up for a challenge.</span>

Azure Learning Paths <a href="https://azure.microsoft.com/en-us/training/learning-paths/" target="_blank" rel="noopener">https://azure.microsoft.com/en-us/training/learning-paths/</a>

<span style="font-weight: 400;">I split my time between several of the Azure related learning paths. They have a 70-532 related path, but they also had paths geared towards solutions architecture and developers. As mentioned before, I’m more interested in gaining useful skills than becoming certified. I don’t feel any obligation to stick to the certification content.</span>

<span style="font-weight: 400;">Here’s a few of the courses I looked at:</span>

<span style="font-weight: 400;">The 70-532 path has an excellent set of courses by Mike Pfeiffer. <a href="https://app.pluralsight.com/paths/certificate/developing-microsoft-azure-solutions-70-532" target="_blank" rel="noopener">https://app.pluralsight.com/paths/certificate/developing-microsoft-azure-solutions-70-532</a> </span>

<span style="font-weight: 400;">This path dealt with Azure at the architecture level. Simon Allardice’s course gave a nice conceptual framework to hang some of the more detailed concepts on. Simon’s course directed me to Scott Allen course for a more detailed view. <a href="https://app.pluralsight.com/paths/skill/microsoft-azure-solutions-architect" target="_blank" rel="noopener">https://app.pluralsight.com/paths/skill/microsoft-azure-solutions-architect</a> </span>

<span style="font-weight: 400;">Scott Allen is an excellent presenter and his advanced course in the .NET developer path does not disappoint. <a href="https://app.pluralsight.com/paths/skill/net-developer-on-microsoft-azure" target="_blank" rel="noopener">https://app.pluralsight.com/paths/skill/net-developer-on-microsoft-azure</a> </span>

<span style="font-weight: 400;">Pluralsight has some great resources and a lot of the Azure content is free, so I recommend you check it out.</span> <h2><span style="font-weight: 400;">Get Your Hands Dirty</span></h2> <span style="font-weight: 400;">Besides watching courses, I built a ton of small demo projects. Like anything else, you can’t just watch a video and expect to know how to do something. You need to get your hands dirty. While watching the videos, I’d follow along with the course by building along. Additionally, I worked my way through the various exam objectives make small demo projects.</span>

When doing demo projects, I recommend you build small. Building small helps you focus on the topic at hand while avoiding getting sunk in non-relevant details. It also gives you references you can go back to later. <h2><span style="font-weight: 400;">RTFM (It’s actually pretty good)</span></h2> <span style="font-weight: 400;">Another excellent resource is Microsoft’s own Azure documentation. Our friends at Microsoft poured a lot of love into their documentation and it shows. The Azure docs have lots of reference information combined with specific tutorials. It’s worth having a tab with the Azure docs open at all times. </span>

<span style="font-weight: 400;">Azure Docs <a href="https://docs.microsoft.com/en-us/azure/" target="_blank" rel="noopener">https://docs.microsoft.com/en-us/azure/</a> </span> <h2><span style="font-weight: 400;">Next Steps</span></h2> <span style="font-weight: 400;">While I’ve worked diligently these past few weeks, I don’t feel like an Azure ninja yet. I’m going to continue to build my skills and improve. To do that, I’m going to do a few things. </span>

<span style="font-weight: 400;">Keep building demos. Practice makes perfect. </span>

<span style="font-weight: 400;">Finish the Pluralsight 70-532 course and watch some of the other advanced Azure courses. </span>

<span style="font-weight: 400;">Explore some of the services I didn’t get a chance to play with yet. I still haven’t spent much time working with Azure’s data analytics offerings yet. </span>

<span style="font-weight: 400;">Continue to subscribe to various Azure resources like <a href="https://buildazure.com/" target="_blank" rel="noopener">BuildAzure.com</a> and the Azure Weekly newsletter. It’s easier to keep up when the information comes to you.</span>

<span style="font-weight: 400;">Seek opportunities to get real life experience with Azure. There’s a big difference between an easy looking demo and actually using something in production.</span> <h2><span style="font-weight: 400;">If I Had to Do It Again</span></h2> <span style="font-weight: 400;">If I had to start over again, I’d do things a little differently. First, I’d start with the Pluralsight learning paths. The Pluralsight content is free and higher quality than the Udemy content. It’s hard to argue with cheaper AND better. Other than that, I’d have spent more time building things in PowerShell and the C# API instead of using the portal. While most demos occur in the Azure portal, you’re missing out on a big part of what makes Azure cool. Azure makes it easy to represent your infrastructure as code. </span>

<span style="font-weight: 400;">My current learning process is a cycle between watching videos, building demos, answering questions, and reading docs. When I learn new things, I alternate consumption, recall, and creation. It’s not fancy, but it works. </span>

<span style="font-weight: 400;">If you’re interested in learning more about Azure and cloud technologies, head out to the </span><a href="https://docs.microsoft.com/en-us/azure/"><span style="font-weight: 400;">Azure Docs</span></a><span style="font-weight: 400;"> and check out some of the free </span><a href="https://azure.microsoft.com/en-us/training/"><span style="font-weight: 400;">Azure training</span></a><span style="font-weight: 400;">. It’s amazing what we can do with a few credits and some knowledge. </span>

Grouping Events by Date Ranges In SQL Server

Fri, 09 Feb 2018 18:22:46 GMT

Let's say you have a table of events. Each event has a beginning and an ending date. How would you get a list of the events that happened within each quarter?

Example: A event that begins on 2-1-2017 and ends on 8-1-2017 would have an entries for Q1 2017, Q2 2017, and Q3 2017.

If you're dealing with a single value, you can just use DATEPART(quarter, [DateValue]), but if you're looking to figure out if an event occurs in a range, it's a little more complicated. Here's how to do it. <h3>Getting Date Ranges</h3> The first step to getting this data is to get a list of quarters with their respective date ranges. One way to do this is to use a <a href="https://technet.microsoft.com/en-us/library/ms186243(v=sql.105).aspx" target="_blank" rel="noopener">recursive common table expression</a>. CTE's are snippets of SQL that you can put above your main query to create tables to join against. A recursive CTE creates values by calling itself. Here's a CTE that'll give us a list of quarters from the start date to the current date. When using recursive CTEs, make sure you have a termination condition or you'll have a nice infinite loop on your hands.


DECLARE @start Date = '01-01-2010';
DECLARE @End Date = GETDATE();

WITH Quarters_CTE
AS
(
SELECT @start as [Start], DateAdd(quarter, 1, @start) AS [End], DATEPART(quarter, @start) AS [Quarter], DATEPART(year, @start) AS [Year]
UNION ALL
SELECT DateAdd(quarter, 1, [Start]), DateAdd(quarter, 1, [End]), DATEPART(quarter, DateAdd(quarter, 1, [Start])), DATEPART(year, DateAdd(quarter, 1, [Start]))
FROM Quarters_CTE
WHERE [End] &lt; @end
)
SELECT * FROM Quarters_CTE Q

<h3>Matching Quarters To Events</h3> The next step is compare our events with the quarters. We want a different entry for each quarter the event occurs in. To do this you can join up with the table. You can use non-equality based comparison operators in join queries, so we filter by date range. Here's the complete query:


DECLARE @start Date = '01-01-2010';
DECLARE @End Date = GETDATE();

WITH Quarters_CTE
AS
(
SELECT @start as [Start], DateAdd(quarter, 1, @start) AS [End], DATEPART(quarter, @start) AS [Quarter], DATEPART(year, @start) AS [Year]
UNION ALL
SELECT DateAdd(quarter, 1, [Start]), DateAdd(quarter, 1, [End]), DATEPART(quarter, DateAdd(quarter, 1, [Start])), DATEPART(year, DateAdd(quarter, 1, [Start]))
FROM Quarters_CTE
WHERE [End] &lt; @end
)
SELECT * FROM Quarters_CTE Q
JOIN [Events] E ON e.StartDate &lt; q.[End] AND (e.EndDate is null OR e.EndDate &gt; q.[Start])

From there you can aggregate your data as needed.

Cmder is the Cadillac of Windows Consoles

Wed, 06 Sep 2017 19:48:52 GMT

Like fashion, computing works in cycles. Things that were once looked at as passe come back with retro vengeance. For .NET development, the console is back. Consoles combined with lightweight editors like Visual Studio Code are becoming increasingly popular. Call me a hipster, but I'm all for this change. I hate waiting around for my editor and I never have to do that in a console or Visual Studio Code.

Unfortunately, if you're living in the world of Windows, the default command line options are lacking. Not only are CMD and Powershell ugly, they lack basic usability features found in Linux and OSX. There is a better way. Cmder is a Windows console emulator that bundles several command line tools together into one fantastic package. It's the Cadillac of Windows consoles.

Here's what it looks like:

Cmder has a nice tabbed interface. You can run multiple consoles without having to deal with a bunch of windows. It also supports several different types of consoles including: CMD (enhanced with <a href="https://mridgers.github.io/clink/" target="_blank" rel="noopener">Clink</a>), Powershell, and Bash.

You also get full control of the appearance of the shells including the font, color, etc... Cmder has many themes, but the default Monokai theme is good enough for me.

More importantly, you can create custom tasks. A custom task is a specific command window that you can define. You can specify the shell, what parameters it's called with, and what directory is opened. You can have a command line setup for each application you work on. You no longer need to open a command line and manually navigate to your app folder each time you open up the console.

<strong>To make a custom task, do the following:</strong>

From Cmder, type Win + Alt + T. This takes you the tasks windows. You can also click the arrow next to the plus sign and click "Setup Tasks".

This window allows you to reorder and reorganize the different defaults in Cmder. Hit the plus sign to add your own.

In this case, this is a console task that opens a specific project I'm working on.

After you setup your new task, click "Save Settings". You should see your new shell in the list of available presets. Then you can open that exact shell whenever you want.

If you want to supercharge your Windows console, <a href="http://cmder.net/">check out Cmder</a>.

4 Tips For Blazing Fast ASP.NET Core Applications

Tue, 08 Aug 2017 15:29:52 GMT

I'm a huge fan of ASP.NET Core. It's a great iteration on the ASP.NET platform and it should be your default choice for any new web development. I'm also a big fan of apps that don't take a week to load. Fortunately, ASP.NET Core doesn't skimp in the speed department. The framework has some great features for building fast applications. Some things that used to be hard are now easy.

In this post, I'm going to go over a few tips for building blazing fast ASP.NET applications. <h3>Async Everything</h3> <img class="alignnone size-medium wp-image-386" src="/assets/images/wp-content/uploads/2017/08/async-all-the-things-300x225.jpg" alt="" width="300" height="225" />

One important way to help your application scale is to use asynchronous methods. The async and await keywords make building asynchronous code as easy as building synchronous code. Using async and await frees up your threads while waiting for calls to return. Because you are using up fewer threads, more people can use your application at the same time.

Async is usually a good default practice. But, it's especially important when calling slower processes, like database calls and service requests. You don't want to hog up a thread waiting around for database results to come back. When building your application favor async versions when they are available. Entity Framework has async versions of most data access methods, so make use of them.

One thing to keep in mind is that using async and await will help you scale, but it won't run your requests in parallel. If you have several slow requests, consider running them in parallel using the <a href="https://docs.microsoft.com/en-us/dotnet/standard/parallel-programming/task-based-asynchronous-programming" target="_blank" rel="noopener">Task Parallel Library</a>. That will compress your wait time to the longest running call, as opposed to waiting for each one to return sequentially. <h3>Cache Rules Everything Around Me</h3> Getting data out of a database is the largest performance bottleneck in most applications. One way to reduce that cost is to cache things that are slow to retrieve or slow to change. ASP.NET Core has a few built in cache mechanisms.

The easiest cache to use is the built in <a href="https://docs.microsoft.com/en-us/aspnet/core/performance/caching/memory" target="_blank" rel="noopener">memory cache</a>. This cache stores items in the memory of your applications server. While this is easy to use, there are two downsides. The first downside is your cache goes away if your server goes down. Often, this is a non-issue, but if your application caches things are costly to calculate, this can be a real downer. The second problem is that if you want to scale your application to more than one server, your're out of luck.

The solution to this problem is to use a <a href="https://docs.microsoft.com/en-us/aspnet/core/performance/caching/distributed" target="_blank" rel="noopener">distributed cache</a>. This cache uses either a REDIS instance or a SQL Server table to hold your cached data. I've used both flavors and they both work great. One thing I liked about using the SQL Server cache is that I could add fields to the table to enable more detailed caching logic.

Regardless of which caching mechanism you use, you should hide it behind your own cache abstraction. (I call mine ICacheProvider) By using your own cache abstraction, you can easily swap out one caching mechanism for another. Most people start off with the memory caching, but eventually outgrow it. If you put your caching behind an abstraction, you can swap it out for a distributed cache without having to change a bunch of places in your app. <h3>Crush Those JSON Responses With Middleware</h3> By default, ASP.NET only compresses a few types of requests by default. These include the content of Razor pages, but not the results of api calls (JSON is not compressed by default). This means that if you have an api request heavy application (ie. a SPA), you can save some serious bandwidth by compressing those responses. This is especially important if you are serving mobile customers, who may have a low bandwidth signal.

Unlike the previous version of ASP.NET, Core has a handy <a href="https://docs.microsoft.com/en-us/aspnet/core/performance/response-compression" target="_blank" rel="noopener">built in middleware</a> that you can add to your app. You can specify the type of compression and what mime types to compress. I've tested this in my application and the compression saves a noticeable amount of bandwidth. <h3>Bundle Those Client Side Assets</h3> Modern applications tend to use lots of JavaScript libraries, images, and fonts. Getting those assets to the client efficiently is important. Especially if those clients are on a low bandwidth connection. We rely on two strategies to minimize what we send to the client. The first strategy is bundling. This is where you take several assets and send them down in one request. This saves you bandwidth because you have less headers sent over the wire. The other strategy is minification. This is where you run JavaScript through a process that strips out any extraneous code, shrinking down the file size.

In the ASP.NET world, there are two paths to do this. If you are building a JavaScript heavy application, like a SPA application, use a JavaScript build tool. Webpack is my preferred JavaScript build tool. It can iterate through your dependencies and then bundle them into files. If you're using Angular (2+), you should use the Angular CLI. It uses Webpack under the hood, but hides away it's complexity.

The second way to do bundle and minify assets is to use the <a href="https://docs.microsoft.com/en-us/aspnet/core/client-side/bundling-and-minification" target="_blank" rel="noopener">Bundler and Minifier</a> Visual Studio extension. This extension compiles your client side assets on build. It is easier to use than JavaScript build tools like Webpack. If you're using Razor views with a little bit of client side code, this is the way to go.

<h3><strong>How about you?</strong></h3> If you have a good performance tip, feel free to leave it in the comments.

Book Review: Crucial Conversations

Sat, 11 Mar 2017 12:55:51 GMT

Ever find yourself in high stakes situations where even the slightest miscommunication can bring everything crashing into the ground? If so, <a href="http://amzn.to/2naMNsb" target="_blank">Crucial Conversations</a> has you covered. Crucial Conversations is a book about how to better navigate high stakes conversations. Unlike most business books, <a href="http://amzn.to/2naMNsb" target="_blank">Crucial Conversations</a> is packed with actionable information. <h2>Why bother?</h2> Why is this an important skill for developers? People think software development as a process where people in a windowless basement turn pizza and caffeine into software. The reality is that software development is more about communication than technology. We build software in teams. We build software for people. We need to figure out what those people want. We need to be able to have honest conversations when things don't go as planned (which is always). Creating a free flowing dialog is absolutely essential to creating valuable software.

Beyond building software. Developers who want a lucrative career find themselves in high stakes negotiations. These include, project scope discussions, salary negotiations, and job role discussions. Learning how navigate these situations can add thousands of dollars to your lifetime earnings. Not bad for a $10 book and a few hours of reading time. <h2>Main Ideas</h2> Everyone has high stakes conversations. These include high pressure negotiations, impassioned arguments, and delicate interventions. Crucial conversations come in many different flavors. What links them together is that the results of these sorts of conversations have an out-sized impact on your life. Screw up one of these and you could be feeling the pain for years to come.

The key to navigating crucial conversations is to keep a free flowing dialog between the participants. To create free flowing dialog, maintain psychological safety. The primary goal of someone in a crucial conversation is to create and maintain a psychological safe space where both parties can express themselves without fear of anger or retribution. If everyone can get everything onto the table, you can usually figure out the correct path.

To cultivate psychological safety, you need to control your own emotions. Many people cast their own stories into "victim and villain" narratives. Playing the victim causes other people to get defensive. This defensiveness erodes psychological safety. Without psychological safety, people retreat to "silence or violence". They either shut down or defend themselves with hostility. Usually emotional and verbal hostility, but sometimes physical hostility. Responding to a conversation with silence or aggression is "the fool's choice". Avoid the fool's choice at all costs.

The book describes many techniques to maintain dialog. I'm not going to list them all out here, but a few include:

<strong>Shared Purpose</strong> People generally have some shared goal in the conversation. Reminding people of that goal can inspire mutual cooperation.

<strong>Contrast and Clarification</strong> Use contrast to clarify what you want. Prevent misinterpretation. Everyone has a plethora of cognitive biases. It's easy to misinterpret wants and needs in high pressure situations. Contrast what you actually want with what people think you want.

<strong>"Start with Heart"</strong> Figure out what you actually want from a situation and take your ego out of the equation. <h2>Related Concepts</h2> <strong>Radical Candor</strong> Radical candor is where you are willing to challenge people directly, but with a high degree of empathy. It's the useful alternative to being a wimp or an asshole.

Find out more about it here: <a href="https://www.radicalcandor.com/about-radical-candor/" target="_blank">https://www.radicalcandor.com/about-radical-candor/</a>

<strong>Cognitive Distortions</strong> People have a variety of intellectual distortions. These are also referred to as cognitive biases. Watch out for cognitive distortions in yourself or others. There are dozens of these, but Psychology Tools has put together handy chart detailing some of the major ones:

Web site - <a href="http://psychologytools.com/unhelpful-thinking-styles.html" target="_blank">http://psychologytools.com/unhelpful-thinking-styles.html</a> PDF - <a href="http://media.psychologytools.com/worksheets/english_us/unhelpful_thinking_styles_en-us.pdf" target="_blank">http://media.psychologytools.com/worksheets/english_us/unhelpful_thinking_styles_en-us.pdf</a>

<strong>Ego is the Enemy</strong> A big part of being a better negotiation is learning how to disarm your ego. Lots of people forget their mutual goal and try to "win" an argument. This is usually waste of time. Focus more on your goal and less on yourself. Ryan Holiday has a fantastic book about this.

<a href="http://amzn.to/2nqCrAC" target="_blank">Ego is the Enemy</a> (Amazon) <h2>Conclusion</h2> Being able to successfully navigate tough conversations is an essential developer skill. Crucial Conversations has a variety of techniques to better navigate high stakes conversations. For the sake of yourself and everyone who has to work with you, work on your communication skills.

<a href="http://amzn.to/2mxEcyl" target="_blank">Crucial Conversations (Amazon)</a>

How To Deal With Tech Overload: Focus on Value

Wed, 25 Jan 2017 23:56:39 GMT

<img class="size-full" src=" /assets/images/wp-content/uploads/2017/01/1024px-Golden_gavel_1.jpg" alt="Golden Hammer" width="1024" height="922" /> Image By walknboston (Flickr: Gavel) [CC BY 2.0 (http://creativecommons.org/licenses/by/2.0)], via Wikimedia Commons

The technology landscape is exploding with new things to learn. From virtual reality to app enabled refrigerators to the JavaScript flavor of the week, we are drowning in new technologies. Unfortunately, none of these new things are cybernetic brain enhancement. We can only learn so much. What criteria can we use to winnow down the technology avalanche and focus on what is important?

<strong>Usefulness should be your primary criteria.</strong>

Let's unpack that a bit.

Software is a tool. We use it to build things of value for people. Either our customers, our users, or ourselves. We build to provide valuable software for people. A lot of developers lose sight of this when they look into new technologies. They fall in love with a technology because it's shiny, or interesting, or scratches an intellectual itch. It's the old "golden hammer" antipattern. Find something shiny and use it to build everything, even if it's not the best tool for the job or doesn't really improve upon existing technologies. We can do better. By focusing on what's useful, we can skip the majority of new technologies and keep our sanity.

To figure out what's useful, we need to ask a few questions. Write down your own answers as you read through this exercise. <h2>Who is your audience?</h2> As developers, we serve one or more audiences. Each of these audiences has different needs. It's your job to figure out which audiences you serve (or want to serve) and what they need. Perhaps you are spending most of your time in a full-time job, but want to start your own business. Perhaps you just work for the man. Figure out which audiences you serve and their relative priority. If you want to serve a new audience, think about what you will need to learn for them as well. Additionally, look for synergies. If you have more than one audience, find overlapping technologies.For example, if you want to build your own business on the side, use a similar tech stack to the one you use at your job.

Here's a few audiences you can serve:

<strong>Employer </strong> <div class="" data-block="true" data-editor="3q40c" data-offset-key="b0qin-0-0"> <div class="public-DraftStyleDefault-block public-DraftStyleDefault-ltr" data-offset-key="b0qin-0-0"><span data-offset-key="b0qin-0-0">Your employer usually works with a specific tech stack in a certain industry. </span><span class="veryhardreadability"><span data-offset-key="b0qin-1-0">Focus your efforts on their current tech stack, new versions of that stack, and new technologies that would fit well within their current environment</span></span><span data-offset-key="b0qin-2-0">. If you work at a .NET shop, don't waste your time on Java. If you work on a native iOS or Android team, learning Ionic is a bad plan. Find technologies that help business units create more value. If you don't know how your business operates, add that to your "to learn" list.</span></div> </div> <div class="" data-block="true" data-editor="3q40c" data-offset-key="fj2rl-0-0"> <div class="public-DraftStyleDefault-block public-DraftStyleDefault-ltr" data-offset-key="fj2rl-0-0"><span data-offset-key="fj2rl-0-0"> </span></div> </div> <div class="" data-block="true" data-editor="3q40c" data-offset-key="da6ds-0-0"> <div class="public-DraftStyleDefault-block public-DraftStyleDefault-ltr" data-offset-key="da6ds-0-0"><span data-offset-key="da6ds-0-0">A good example of a useful technology would be Docker. </span><span class="hardreadability"><span data-offset-key="da6ds-1-0">Docker allows for faster and more consistent deployments, which helps improve time to market</span></span><span data-offset-key="da6ds-2-0">. This can give a business a real competitive advantage. Another good example would be mastering performance tuning in your particular stack. Lot's of case studies show performance adds to the bottom line.</span></div> <div class="public-DraftStyleDefault-block public-DraftStyleDefault-ltr" data-offset-key="da6ds-0-0"></div> </div> <strong>Public Code / OSS</strong>

Open source projects have different goals than enterprise shops. There's some overlap, but OSS is built differently. If you do OSS, figure out which projects you want to contribute to and focus on their tech stacks. Also think about what value you can bring to the developer community.

<strong>Small Business</strong>

If you run an app business or an ISV (independent software vendor), focus on technologies that create customer value. For example, while functional programming is cool, you're better off mastering digital marketing or product design instead. Focus on technologies that help you get products in front of customers quickly. This doesn't always mean new technology. There are a lot of Rails 2, jQuery, and ASP.NET Webforms apps out there still generating significant value for their customers.

It's OK to learn something just for fun. Lots of people write code as a hobby, but make sure you understand that the time you spend building robots or smartwatch apps is hobby time, not professional development time.

<hr />

<span data-offset-key="f510e-0-0">I have three audiences. I work on a team that builds data driven applications using .NET Core, Angular, TypeScript, and Spark. I also serve the broader technical community by speaking at conferences and blogging. </span><span class="adverb"><span data-offset-key="f510e-1-0">Eventually</span></span><span data-offset-key="f510e-2-0">, I want to build a small software product and sell it. </span><span class="veryhardreadability"><span data-offset-key="f510e-3-0">I achieve synergy by focusing my community efforts on things that I either use in my day-to-day work (like Angular) or things that will serve me in business (innovation)</span></span><span data-offset-key="f510e-4-0">.</span> <h2>What makes you special?</h2> <div class="" data-block="true" data-editor="3q40c" data-offset-key="6t7ec-0-0"> <div class="public-DraftStyleDefault-block public-DraftStyleDefault-ltr" data-offset-key="6t7ec-0-0"><span data-offset-key="6t7ec-0-0">What special qualities do you bring to the table? Are you an amazing debugger? Are you a UX genius? Are you good at cutting to the core of team issues? Do you have an underrepresented perspective? Everyone has specific skills that are both unusual and valuable. Focus your development efforts on expanding and complementing what makes you special. For example, if you're a talented at building user interfaces, spend the time to skill up on Angular or React. If you're the performance expert, check out that shiny new profiling tool. It's often better to expand a strength than moderate a weakness. </span></div> </div> <div class="" data-block="true" data-editor="3q40c" data-offset-key="1vah-0-0"> <div class="public-DraftStyleDefault-block public-DraftStyleDefault-ltr" data-offset-key="1vah-0-0"><span data-offset-key="1vah-0-0"> </span></div> </div> <div class="" data-block="true" data-editor="3q40c" data-offset-key="2n2le-0-0"> <div class="public-DraftStyleDefault-block public-DraftStyleDefault-ltr" data-offset-key="2n2le-0-0"><span data-offset-key="2n2le-0-0">------</span></div> </div> <div class="" data-block="true" data-editor="3q40c" data-offset-key="7h360-0-0"> <div class="public-DraftStyleDefault-block public-DraftStyleDefault-ltr" data-offset-key="7h360-0-0"><span data-offset-key="7h360-0-0"> </span></div> </div> <div class="" data-block="true" data-editor="3q40c" data-offset-key="3et32-0-0"> <div class="public-DraftStyleDefault-block public-DraftStyleDefault-ltr" data-offset-key="3et32-0-0"><span data-offset-key="3et32-0-0">I know more about UX and front end development than most of the .NET developers I work with. I'm also good at keeping my cool when things get crazy. People have called me "Spock" before, which I take as a compliment. </span><span class="hardreadability"><span data-offset-key="3et32-1-0">I also have a variety of non-developer skills, like public speaking and psychology, that allow me to think </span></span><span class="adverb"><span data-offset-key="3et32-2-0">differently</span></span><span data-offset-key="3et32-3-0">.</span></div> </div> <h2>What do you already know?</h2> <div class="" data-block="true" data-editor="3q40c" data-offset-key="9h4hd-0-0"> <div class="public-DraftStyleDefault-block public-DraftStyleDefault-ltr" data-offset-key="9h4hd-0-0"><span data-offset-key="9h4hd-0-0">Take inventory of your current skills. Focus your efforts on technologies that expand what you can do with your current skills. </span><span class="hardreadability"><span data-offset-key="9h4hd-1-0">For example, if you know Ember and Angular, investing effort in learning React is going to net you diminishing returns</span></span><span data-offset-key="9h4hd-2-0">. </span><span class="complexword"><span data-offset-key="9h4hd-3-0">However</span></span><span class="hardreadability"><span data-offset-key="9h4hd-4-0">, investing in Web API, Electron, or Ionic will add new capabilities to your skillset</span></span><span data-offset-key="9h4hd-5-0">. </span><span class="hardreadability"><span data-offset-key="9h4hd-6-0">Realize that specific technologies fade with time, but investing in fundamentals is always a good bet</span></span><span data-offset-key="9h4hd-7-0">. </span><span class="veryhardreadability"><span data-offset-key="9h4hd-8-0">Who knows what the JavaScript ecosystem is going to look like next year, but knowing the fundamentals of JavaScript, performance optimization, and UX will still be valuable</span></span><span data-offset-key="9h4hd-9-0">.</span></div> </div> <div class="" data-block="true" data-editor="3q40c" data-offset-key="1gl3v-0-0"> <div class="public-DraftStyleDefault-block public-DraftStyleDefault-ltr" data-offset-key="1gl3v-0-0"><span data-offset-key="1gl3v-0-0"> </span></div> </div> <div class="" data-block="true" data-editor="3q40c" data-offset-key="7cnkd-0-0"> <div class="public-DraftStyleDefault-block public-DraftStyleDefault-ltr" data-offset-key="7cnkd-0-0"><span data-offset-key="7cnkd-0-0">------</span></div> </div> <div class="" data-block="true" data-editor="3q40c" data-offset-key="8j611-0-0"> <div class="public-DraftStyleDefault-block public-DraftStyleDefault-ltr" data-offset-key="8j611-0-0"><span data-offset-key="8j611-0-0"> </span></div> </div> <div class="" data-block="true" data-editor="3q40c" data-offset-key="c3ucu-0-0"> <div class="public-DraftStyleDefault-block public-DraftStyleDefault-ltr" data-offset-key="c3ucu-0-0"><span data-offset-key="c3ucu-0-0">My current skill set revolves around Angular, TypeScript, SQL Server, and ASP.NET MVC. I want to learn more about data tools, especially the ones in Visual Studio. </span><span class="hardreadability"><span data-offset-key="c3ucu-1-0">The Microsoft ecosystem is gaining some interesting data capabilities that can add a lot of value</span></span><span data-offset-key="c3ucu-2-0">. I may also do an exploration of Ionic 2 and progressive web applications. Both of those are good ways to use existing skills in a new way. I'm also working on my public speaking and written communication. Communications skills never become obsolete. </span></div> </div> <h2>Practical Application</h2> Now that you know what's useful for your situation, let's use that knowledge to make your life easier. You likely have a list of technologies that you're interested in or feel obligated to keep up with. <a href="https://dustinewers.com/building-tech-radars-for-fun-and-profit/" target="_blank" rel="noopener">I have a whole radar of them.</a> <span data-offset-key="2910k-2-0">Take that list and run it through the criteria you figured out. If the technology doesn't help you add value to one of your audiences, cross it off the list. Rank everything else based on its relative value. </span><span class="hardreadability"><span data-offset-key="2910k-3-0"> Use your criteria to combat "shiny object" syndrome when you encounter a new technology</span></span><span data-offset-key="2910k-4-0">. You'll likely still have more things on your list than you can learn, but your list should be manageable.</span> <div class="" data-block="true" data-editor="3q40c" data-offset-key="fj2fn-0-0"> <div class="public-DraftStyleDefault-block public-DraftStyleDefault-ltr" data-offset-key="fj2fn-0-0"><span class="veryhardreadability"><span data-offset-key="fj2fn-0-0">If you want to survive the constant stream of new technologies with your sanity intact, make your primary technology criteria value</span></span><span data-offset-key="fj2fn-1-0">.</span></div> </div>

Building Tech Radars for Fun and Profit

Thu, 22 Dec 2016 23:36:42 GMT

The technology landscape is exploding. New technologies, platforms, and tools are being creating at an ever-increasing rate. VR, AR, and wearables give us new app stores to target and new experiences to create. Conversational UI (Alexa, Bots, Cortana API) is a totally new way to interact with users, and another dozen different platforms you can target. Even the web space is exploding. It feels like there's a new JavaScript framework roughly every ten minutes.

All of the new stuff is amazing, but also exhausting. There's so many new things out there. Finding your focus is hard.

Keeping track of all this new stuff is tough, but we have tools to help us. One of those tools is tech radar. A technology radar is a collection of new technologies and how important they are to you or your organization. You enumerate new technologies and assign them a value somewhere between "run away screaming" and "let's use this for EVERYTHING".

The tech radar was created by Thoughtworks. They publish their radar a couple of times a year. It's a great snapshot of what technologies they are using in their organization. I recommend you check it out.

<a href="https://www.thoughtworks.com/radar" target="_blank">Thoughtworks Tech Radar</a>

While the Thoughtworks tech radar is great, it's more fun (and useful) to do it yourself. Neil Ford has a fantastic talk about building your own tech radar. Check it out here:

https://www.youtube.com/watch?v=ZhKthgQ5uLk

<span style="font-size: 1rem;">In his talk, Neil mentions two tech radars. One for your company and one for yourself. After viewing this talk, I was hooked by the idea and decided to give it a try. I've worked on both styles of tech radar and learned a few things along the way. </span>

<h2>Organizational Tech Radars</h2>

An organizational tech radar is a picture of the technologies used in your company along with recommendations for new things you should keep an eye on. Your team sorts technologies into one of four categories.

<strong>Adopt</strong> - Use when appropriate. This is a default best practice. <strong>Trial</strong> - Use on non-critical projects. Good, but not 100% there yet. <strong>Assess</strong> - Keep an eye on this. Use it for POCs and Demos. <strong>Hold</strong> - Avoid using this on new projects.

To conduct a tech radar, get representatives of the different teams in your organization together and have them discuss some of the new technologies they are using or interested in using. Assign each technology to the proper category and record the highlights of each conversation.

Shoot for fewer than 30 people per discussion session. Try to get a diverse slice of your organization's tech users. If your organization has teams outside of generic enterprise app dev, make sure they get a seat at the table. (examples: designers, SharePoint Devs, Salesforce Devs, DBAs, DevOps, mobile devs, etc... )

I'm involved in two different organizational tech radars. One as the primary organizer and another as an observer. It's been an educational and useful experience. I've gained insight into some of the dynamics behind how technology is used in these two organizations.

One of the major benefits of doing a tech radar is that you deepen your understanding of how technology is used in your organization. You also gain insight into what different people are thinking. It can highlight blind spots in your own thinking and surface interesting technologies to check out. Another benefit is that it can make your organization more proactive about technology adoption. By knowing what's available, you can begin to plan earlier. You also gain consensus about which technologies to adopt. It's a lot easier than trying to campaign for new technologies on your own.

It's not all rainbows and puppy dogs though. I ran into several challenges while coordinating my organization's tech radar. First, I had to make a special effort to represent all the developer communities in my organization. We have a lot of practices and not all of them came to the discussion meetings. Next time, I may hold special meetings for each group.

The second hurdle I ran into was that everyone was very focused on things to adopt now, as opposed to future technologies. This issue was relatively easy to solve. We created a new category for "obvious best practices" and focused more on the "trial" and "assess" categories. Don't be afraid to make tech radar your own. You don't have to copy Thoughtworks verbatim. I found that making a category for things that aren't new, but part of your default tech stack, cleared up the "adopt" list and kept the radar future forward. It also provides you with a handy list of architectural recommendations for new projects.

The final challenge was dealing with all the conversations. It was easy to go off on tangents or get caught up in how you feel about a particular technology. It's tough to keep on track. One way we addressed the issue was by splitting up the meetings into small chunks. It's easier to schedule and no one gets burned out from a 4 hour meeting from hell.

Overall, I found this exercise highly beneficial. I learned a lot and picked up a few technologies for my tech radar.

<h2>Personal Tech Radars</h2>

If you're like me, you have "the list". Sometimes referred to as "the guilt list", because I never finish it. It's the pile of technologies you intend to research. If that sounds vague, that's because it is. "to research" doesn't really give you a finishing point. I built a personal tech radar to help clear up that ambiguity.

For me, a personal tech radar is a much less formal affair than the organization radar. It's also, by necessity, a smaller one. I changed the definition of the categories. Instead of focusing on adoption, my categories focused on how much effort I want to put into learning the technology. Here are my categories and a few examples for each one.

<strong>Adopt</strong> Agitate for use and learn deeply. This is for your core skills. Examples: .NET Core, Angular 2, TypeScript, Azure

<strong>Trial</strong> Seek functional knowledge on. Build a demo apps or POCs. Examples: Python, Spark, R, Progressive Web Apps

<strong>Assess</strong> Keep an eye on it, but don't worry about getting deep knowledge. Examples: Hololens, Unity, Xamarin, Chatbots

<strong>Hold </strong>Avoid using when possible. Don't waste a lot of time learning new things about this tech. Examples: Old ASP.NET, Angular 1

I only had one challenge with my personal tech radar. I'm interested in everything, so I had a lot of trouble keeping my categories small enough to be doable. I consider this a feature, not a bug. Doing this exercise forced me to take a holistic view about what I'm interested in and edit accordingly. I also did some journaling about where I wanted to go in my career, which helped clarify my thinking. For example, I realized that learning data analysis is a better use of my energy than learning native mobile development. I'm still keeping an eye on mobile, but it's not a top priority for me. Overall, it narrowed my scope and helped me focus.

<h2>Conclusion</h2>

If you want to better deal with the ever-growing deluge of new technologies, consider doing a tech radar. Both the organizational and personal flavors offer insights that you can use in your daily developer practice. It's a great way to end the year.

PS - For some reason, I think of this song every time I bring up Tech Radar.

https://www.youtube.com/watch?v=Zf53Pg2AkdY

Great Reads for Innovators

Wed, 14 Dec 2016 23:08:51 GMT

As technologists, we are the vanguard of innovation. We're at the forefront of technological innovation. Even if you're slagging COBOL in the basement of some bank, you're still dragging your organization into the future. Ever wonder how that process actually happens? What can you do to be more creative?

I'm fascinated by this topic, so I put together a talk about it. (<a href="http://dustinewers.com/speaking/">abstract</a> / <a href="https://goo.gl/7MrmLM">slides</a>) It distills what I've learned from reading dozens of books on innovation and the history of technology. To save you some time, I put together a list of my favorite innovation related reads. If you're curious about this topic, these books are a good place to start.

<h2>Books for Innovators</h2>

<h3><a href="http://amzn.to/2hHsoIB">Sapiens</a></h3>

Sapiens is a highly entertaining, unorthodox view of human history. Not only is it informative, it challenges basic assumptions about ideas that most people don't realize they're making. It's a great description of early human history and how we got to the modern age. It'll really open up your mind.

<h3><a href="http://amzn.to/2gNgY4v">Geography of Genius</a></h3>

Innovation is not evenly distributed. There are certain times and places throughout history that have "golden ages" of innovation. Geography of Genius explores a few of these places and tries to find what ties them all together. This book is very interesting and you'll learn about some places that you don't see much of in the classroom.

<h3><a href="http://amzn.to/2hHmLu2">Evolution of Everything</a></h3>

Unlike what the history books tell us, innovation is more bottom up than top down. Matt Ridley does a fantastic job describing how in Evolution of Everything. He covers a several major innovations including religion, money, and government. This book challenges many deeply held beliefs and illustrates how innovation is an evolutionary process.

<h3><a href="http://amzn.to/2gNgviN">Smarter Better Faster</a></h3>

This book offers a more tactical look at creativity. It's also a great guide to improving other aspects of mental performance. Charles Duhigg does a fantastic job mixing science with fascinating stories.

Creativity requires concentration. A commodity in short supply in the modern age. In Deep Work, Cal Newport makes a compelling argument for making "deep work" (focused work) one of your primary priorities. I changed several of my habits after reading this one.

<h3><a href="http://amzn.to/2hHuI2r">Competing Against Luck</a></h3>

While I enjoyed the Lean Startup, I felt like it treated innovation more like a roulette wheel than a process you can influence. "Just pivot until you make it big or run out of money." In Competing Against Luck, Clayton Christensen describes a fantastic intellectual power tool for building new products. The "Jobs to Be Done" theory of innovation. If you want to build a product, I highly recommend this one.

<h3><a href="http://amzn.to/2hQ0nud">The Righteous Mind</a></h3>

One of the most important things you can do to become more innovative is empathize with and learn from people whom you disagree with. We live in a society that's increasingly polarized, but this book the antidote. In the Righteous Mind, Jonathan Haidt explains the moral foundations for different political outlooks and makes a strong case for civility in political discourse. This is a must read if you have trouble dealing with people who don't share your beliefs.

<h2>Bonus Materials:</h2>

Here are a few non-book resources to check out:

<a href="http://kk.org/thetechnium/protopia/">Protopia (Kevin Kelly)</a>

Kevin Kelly's concept of protopia (as opposed to utopia or dystopia) is really enlightening.

In <a href="http://amzn.to/2hyrFX5">How to Fail at Almost Everything and Still Win Big</a>, cartoonist and business author Scott Adams describes his "success formula". Each area you master roughly doubles your odds of great success. This is a great case for diversifying yourself. You can either get his book or read this article:

<a href="http://www.forbes.com/sites/carminegallo/2013/10/23/dilbert-creator-scott-adams-reveals-the-simple-formula-that-will-double-your-odds-of-success/">Dilbert Creator Scott Adams Reveals The Simple Formula That Will Double Your Odds Of Success</a>

If you're looking to diversify yourself, here are two excellent resources:

<a href="https://personalmba.com/best-business-books/">Personal MBA</a>

The Personal MBA is a reading list that's meant to give you the business skills taught by an MBA program. I've read many books on this list and have not been disappointed. It's also got great selections on personal finance and psychology.

<a href="http://www.thegreatcourses.com/">The Great Courses</a> (<a href="http://amzn.to/2hPUltE">Amazon</a>)

The Great Courses are a series of college level lectures that you can listen to in your car. Personally, I'm a big fan of their history selection. They also have courses on psychology, philosophy, and business.

<a href="http://news.mit.edu/2013/why-innovation-thrives-in-cities-0604">Why Innovation Thrives in Cities</a>

Innovation is partly a network effect. This article describes why cities with a higher population density have higher per capita rates of innovation.

Everything is a Remix is a video series about cultural innovation by Kirby Ferguson. I have yet to find a better description of how culture is generated by remixing other cultural elements.

https://www.youtube.com/watch?v=nJPERZDfyWc

This is a TED talk on how Google X (Google's own skunkworks company) takes risks and creates a culture that fosters psychological safety.

https://www.ted.com/talks/astro_teller_the_unexpected_benefit_of_celebrating_failure

<h2>Conclusion</h2>

This list of resources will open your mind and help you become a better innovator. If you think I missed something, feel free to drop it in the comments.

How To Get The Most Out Of Criticism

Fri, 22 May 2015 00:13:38 GMT

Have you ever built something you're proud of, only to have it torn to shreds when you show it your audience? Get burned in a code review? Rejected after a job interview? I know I have. Today, I'm going to write about some strategies to deal with it.

<blockquote>If someone is able to show me that what I think or do is not right, I will happily change, for I seek the truth, by which no one was ever truly harmed. It is the person who continues in his self-deception and ignorance who is harmed. ― Marcus Aurelius, <a href="http://amzn.to/1HlJRY4">Meditations</a></blockquote>

One of the most underestimated soft skills of the modern software developer is the ability to take criticism well. This is an industry where things change so quickly that there’s no way to be perfect. There is always someone who knows more than you and even if they don’t know more than you, you can certainly learn from them.

Besides being bad at taking criticism, most developers are not good at giving good criticism. Anyone can slag another person’s creative output, but how often can someone say something that helps the person they're critiquing? Being able to deliver a useful critique is almost as valuable as taking one. Software development is a complex craft and being able to help others is essential.

<h3 id="ondealingwithcriticism">On Dealing With Criticism</h3>

<blockquote>One particularly powerful sting-elimination strategy is to consider the source of an insult. If I respect the source, if I value his opinions, then his critical remarks shouldn't upset me.

William Irving, <a href="http://amzn.to/1Q0pvbJ">A Guide to the Good Life: The Ancient Art of Stoic Joy</a></blockquote>

I'm going to define criticism broadly. To me, criticism includes any comments you receive on your creative work. It includes well meaning advice, sharp attacks, and trolling. It also includes situations when you don't get picked for the job, get passed over to speak at a conference, or lose a contest. Call it criticism from life. Regardless of the source and intent of the criticism, the following tips apply.

<strong>Don’t take it personally.</strong>

Even if someone meant to harm you, you choose how you respond to criticism. You can choose not to interpret it as insult. At the end of the day, all criticism is information. Treat it like any other data stream. Some data is higher in quality, some data is lower in quality, but it’s all just data.

The reality is the people who sling insults are not doing it because of you, they're doing it because of their own issues. You can't control them, but you can control you.

<strong>Mine for actionable feedback.</strong>

When someone criticizes your work, even if they were trying to hurt you, look for things you can improve on. For example, let’s say your users throw some scathing criticism your way in a product review. While it’s easy to get angry or frustrated, try to figure out the root cause of their pain and use it to improve the product. If you get rejected for a job, try to think of where you went wrong and fix those things in future interviews. Remember, failure is temporary. Learning is everything.

Sometimes, you are going to get comments that have no useful information. Trolls excel at leaving useless criticism. If you can't find actionable advice, then disregard the comment. Remember, people being mean is their fault, not yours.

<strong>Consider the source.</strong>

Like in the quotation above, it’s important to consider who is criticizing you. Do you respect them? Are they considered experts this particular area? Do they adhere to the same philosophy as you? Use these considerations to weigh comments. Do you think that Peter Thiel, Elon Musk, Ray Kurzweil and others like them care one shred about what luddites think about them? I doubt it.

<h3 id="ongivinggoodcriticism">On Giving Good Criticism</h3>

Giving good criticism is almost as important as being able to take criticism. Being able to deliver useful feedback to your peers helps them grow. Being able to do it in a way that doesn't make them hate you is good too. Here are a few tips to help you with that.

<strong>Be mindful of other people’s egos.</strong>

While it’s easy to say that you should make all criticism into dispassionate feedback, actually doing it is hard. I still have a ways to go myself. Because of this, you should make it as easy as possible for the person you are critiquing to turn what you say into useful feedback. An important way to do this is by being mindful of their ego.

Software development is a tough craft. People invest their time and energy to get good at it and a well timed insult and can trigger all kinds of pain. If you want to see how fragile people's egos are, Google "imposter syndrome".

To help preserve ego, start with compliments. For example, I attended a session last year that had some content issues. When asked how it went, I started off with the good things about the session. I complemented the presenter on their topic selection and presentation style, which were both excellent. Then I made a point about how they tried to do too much for their time slot. This gave the person something they could use without hurting their feelings.

Remember that negative feedback has more weight than positive feedback. Start off on a positive note and try to achieve at least a 2:1 ratio of positive to negative comments. (if possible)

<strong>Focus on giving actionable advice.</strong>

Telling someone "that sucks" does nothing useful for either party. You don't get a better product/employee/code and the person being criticized doesn't learn anything. Additionally, you've angered the person you are critiquing, which benefits no one. Instead, focus on making things better. Try saying "This would be better if..." or "These X things would improve your product because of Y reasons". Using direct, but non personal phrases focuses the attention to where it needs to be. Remember, there are no bad people, just bad ideas.

<h3 id="conclusion">Conclusion</h3>

The key lesson for this post is to always look for value in criticism. When someone criticizes you, focus on extracting useful information from the experience. Use it to fuel your abilities to the next level. When critiquing others, try to focus on making it easy for them to find value in your comments. Help them get to the next level. Remember, criticism is just data. You choose how to use it.

Image: Roman Emperor and Stoic, Marcus Aurelius Photograph by <a href="http://en.wikipedia.org/wiki/File:0_Marcus_Aurelius_-Palazzo_Nuovo-Musei_Capitolini(1).JPG">Jean-Pol GRANDMONT</a>

What We Need More of is Hubris: A Review of Zero to One

Wed, 20 May 2015 11:52:22 GMT

We wanted flying cars, instead we got 140 characters.

Peter Thiel</blockquote>

According to Peter Thiel, an amazing future lies ahead. All we have to do is build it. Unfortunately, cultural shifts have steered us away from audacious, grandiose, and truly innovative projects. We need to stop focusing on making slight improvements to existing technology (going from 1 to 1+n) and start making new things (going from 0 to 1). In short, we need more of the hubris that America has had in past decades.

<a href="http://amzn.to/1QZTxi6">Zero to One: Notes on Startups, or How to Build the Future</a> is an excellent book by the self proclaimed contrarian and billionaire Peter Thiel. It’s about building startups and thinking big. <em>Zero to One</em> will inspire you and make you think. It's one of the few business books that can't be re-written in five pages.

<h3 id="contrariantruth">Contrarian Truth</h3>

<em>Zero to One</em> starts off with a big question:

<blockquote>What important truth do very few people agree on?</blockquote>

This is a tough question to answer well. Most people come up with something widely believed, like the healthcare system is broken, or an opinion, like how chocolate ice cream is better than vanilla. The key is to find something that is both true and unpopular.

For example, think about the housing crisis. Right before the crisis, the important truth was "the housing bubble is about to pop". Most people thought the good times were going to last, but some people saw the impending crunch. They used that knowledge to make a lot of money, while the rest of the country lost their shirts.

Finding these contrarian truths gives you an insight into the future. An insight that can you can use to build a business or make an investment. Think of how many truths we take for granted today that were science fiction a few decades ago.

<ul> <li>We can prevent most infectious disease.</li> <li>It is possible for humans to land on the moon.</li> <li>We will have enough food to feed everyone on the planet.</li> <li>The Internet will connect the world with each other</li> </ul>

These things were once considered impossible, but now are obvious.

Here’s a few contrarian truths that I think about on a regular basis:

<ul> <li>The world is a becoming a much better place for all humanity, despite what the news tells you.</li> <li>Deference to authority is not a good tool for solving social problems.</li> <li>The first human to live past 150 years old is probably alive today.</li> <li>Most people won't drive cars in 20 years.</li> </ul>

So when looking for business opportunities, you should ask yourself: <em>What valuable business is nobody building?</em>

<h3 id="zerotoonevstheleanstartup">Zero to One vs. The Lean Startup</h3>

<blockquote>a startup is the largest group of people you can convince of a plan to build a different future.

Peter Thiel</blockquote>

Since the .com bubble popped, the startup community has moved towards the Lean Startup model.

The Lean Startup model goes as follows:

<ol> <li>Target an existing market with competitors or take something that already exists and apply it in a new context. ie. rip, pivot, and jam</li> <li>Build a small version of your product. (a Minimum Viable Product)</li> <li>Release that product and gauge it’s traction</li> <li>Evaluate the tests and either: a. Make small incremental changes to improve the product b. Pivot into a new product</li> <li>Release the new version and test again … repeat 4-5 until out of money or you have a killer business.</li> </ol>

The beauty of this approach is that it’s a scientific way to build a business. No one knows exactly what’s going to work, so you run as many tests as you can to get to a market.

Thiel doesn't agree with this method. He advocates something a little different. His philosophy is that startups should make big plans and carve out their own monopoly. They can do this in one of two ways.

<ol> <li>Make a 10x improvement over an existing product. (Google did this with search)</li> <li>Make a totally new product segment.</li> </ol>

In my experience, I have noticed that most big companies fall into the category of 10x improvements. Even companies that are credited with creating new markets, like Apple, are usually just improving existing technology. MP3 players, smartphones, tablets, and smart watches all existed before Apple took them to the next level. When I think of companies that made something new, I think about <a href="http://en.wikipedia.org/wiki/Pirates_of_Silicon_Valley">Pirates of Silicon Valley</a>

He also mentions that head to head competition always results in a drop in profits. Look at any commodity market and you will notice that profit margins are razor thin. To avoid this, you need to stay so far ahead of the competition that you can charge enough to make a healthy profit. This profit can then be used to build moonshots or attract the best employees by giving them a world class working environment. Google is a great example of this. Thier monopoly status allows them to treat their employees like royalty while trying to tackle large problems.

To build a monopoly, Thiel advocates starting small and dominating a niche market. Be the big fish in the small pond. I think the bootstrapping community has this down on the small scale. They advocate niching down your product so that it serves your target audience perfectly. The primary difference with <em>Zero to One</em> is that once you master that small scale niche, you then expand your reach. Facebook is a great example of this. It started off with just one college and spread like a zombie plague from school to school. I remember the day when Facebook arrived at my school. Nearly everyone on campus was signed up within a week. It was insane.

Honestly, I think Thiel overstates his contrarian-ness here. While his criticisms of the lean model are legitimate, his alternative is very similar. Start small and blow up. I like how he focuses on sales, which is a dirty word to most developers. The importance of selling is often understated in the Valley. Even the best product will fail is no one's heard of it.

<blockquote>Shallow men believe in luck, believe in circumstances… Strong men believe in cause and effect

Ralph Waldo Emerson

Indefinite attitudes about the future explain what's most dysfunctional in our world today. Process trumps substance

Peter Thiel</blockquote>

One of the major themes of <em>Zero to One</em> is the importance of making plans. One of the biggest problems with our society right now is this indefinite attitude towards the future. America used to be a country of big ideas. Even normal people felt they could come up with something big and pitch it to the public. Today, people who think big are often attacked. Ambitious initiatives, like seasteading and life extension, are regularly attacked by lovers of the status quo. If people like Tim Ferriss or Peter Thiel are indicative, having detractors is evidence that you are doing something right. People who change the world are going to make some enemies.

<h3 id="conclusion">Conclusion</h3>

<blockquote>The most contrarian thing of all is not to oppose the crowd but to think for yourself.

Peter Thiel</blockquote>

The best part of <a href="http://amzn.to/1QZTxi6">Zero to One</a> is that it will make you think. Unlike many business books, which can be summarized in a page or two, Zero to One is packed full of interesting and useful information. It’s one of my favorite business books and I think that it's a good book for developers who want to build something great.

Book Review: Essentialism: The Disciplined Pursuit of Less

Tue, 14 Apr 2015 06:39:46 GMT

Being an adult is hard.

People are constantly vying for chunks of your attention. As you become more successful, you have to weigh lots of options. There are dozens of competing commitments and everyone is so busy trying to fit them all in. It’s maddening.

According to Greg McKeown, it doesn’t have to be this way. In his book, <a href="http://www.amazon.com/exec/obidos/ASIN/B00G1J1D28/thweofdujew-20">Essentialism: The Disciplined Pursuit of Less</a>, he lays out a case for eliminating the unimportant things in your life, creating boundaries, and focusing on the important few over the trivial many. I recently listened to this book and found a lot of actionable advice.

This book is especially useful for people in the technology industry. We have to deal with lots of stress and constant change. It can be painful to keep up. This book provides some guidance on how to focus and get better results with less stress.

<h3 id="summary">Summary</h3>

<blockquote>Less, but better.</blockquote>

The main point of the book is that life is a series of trade offs. You can make these trade-offs yourself or you can let other people make them for you. To control your destiny, you need to figure out what’s essential to you. Then, you can focus on these few essentials and eliminate everything else.

The book divides the process of focusing on the essential into three phases:

<h4 id="explore">Explore</h4>

Block off time for exploration and play. Because you're only going to focus on a few important things, it's important to explore what's available. Essentialists spend more time exploring because they don't go "all in" on every task that comes their way. They have more time and incentive to explore.

<h4 id="eliminate">Eliminate</h4>

Come up with a clear purpose for yourself and use that clear purpose to eliminate extraneous things from your life. Use extreme criteria to reduce the number of options available. Set boundaries for yourself and others. Learn to say "no" gracefully.

<h4 id="execute">Execute</h4>

Build systems that reduce the friction of doing essential things. Build smart routines and prepare for setbacks. Focus on small wins to stay motivated.

In addition to the three steps, <em>Essentialism</em> offers specific techniques on how to achieve simplicity in your life. One example is zero based budgeting. Most organizations budget based on last year's numbers. Zero based budgeting starts everything off at zero. Starting from a fresh place may lead to a budget that is more in line with the priorities of the organization.

<h3 id="whyshouldyoureadthisbook">Why should you read this book?</h3>

Technology professionals have to deal with tidal waves of information while balancing competing interests. Becoming an essentialist can make balancing those interests a lot easier. The essentialist philosophy has many practical applications to software professionals.

Here are some examples:

<strong>Requirements</strong> In any given project, people want more features than there's time to build. <em>Essentialism</em> illustrates the necessity of trade-offs and highlights the need to prioritize.

<strong>Career Skills Planning</strong> <em>Essentialism</em> makes a strong case for being a "jack of all trades, master of one" approach to skills training.

<strong>Writing</strong> Both code and prose become better with the elimination of extraneous items.

<strong>Lean Software</strong> The Lean Software movement displays a solid grasp of focusing on the essentials.

<h3 id="conclusion">Conclusion</h3>

<a href="http://www.amazon.com/exec/obidos/ASIN/B00G1J1D28/thweofdujew-20">Essentialism</a> is a great read for any software developer or technology professional. It's made me reevaluate my life and focus more on the essential. I highly recommend it.

How to Find The Best Tech News

Sun, 12 Apr 2015 11:09:44 GMT

Staying well informed is important to every professional, but how do you navigate the sea of infinite content? How can you filter out useful information from political nonsense, irrelevant junk, and clickbait? As someone who tries to focus the essentials, I don’t want to waste time separating the good from the bad. I want useful information that helps me in my life. To address this need, I've created an information funnel. I get news from a variety of sources and filter out the best stuff. In this post, I'm going to describe my information funnel and how you can use a similar process to get your own slice of news.

<h3 id="definegoals">Define Goals</h3>

The most important thing to do when trying to find good information is defining what you are looking for and what you want to avoid. I’m looking for the following things:

<ol> <li>Useful articles on software engineering and ASP.NET</li> <li>Mobile platform how-to articles and major product releases (the Apple Watch, Xamarin Forms)</li> <li>Mobile trends and statistics (smartphone adoption)</li> <li>Bleeding edge future tech (self driving cars, 3D printed organs, etc…)</li> <li>Any new developer trends that I should check out (Ionic, Node.js)</li> </ol>

This list represents a combination of things I need for my job, things I’m interested in, and potential future technical investments. I’m interested in a lot of different things, but the goal of this list is to focus on the technology.

I also want to avoid any unactionable news. If it doesn't help me, then I generally don't care about it. Heres some examples:

<ol> <li>Holy wars. I don’t care about which platform is “better”.</li> <li>Product reviews for things I'm not going to buy.</li> <li>Political drama.</li> <li>Uninformed opinions about the future.</li> </ol>

Additionally, I don’t want to waste a lot of time finding news. Being well informed is a good, but this endeavor has diminishing returns. News is the information equivalent of carbs. You need a few, but not too many, and you want to stick with high quality sources.

<h3 id="sources">Sources</h3>

The next step is to find decent news sources. This is a huge challenge because there are so many news sources. I get my news from a variety of places and have tried various methods of filtration to avoid the junk. I find that a combination of Podcasts, RSS, Twitter, and Prismatic works well for me. I get a variety of sources, which is important to avoid filter bubbles, but I also get some selection, so I'm not buried in junk.

Here's a list of news sources I use now or have tried in the past:

<h5 id="podcasts">Podcasts</h5>

I listen to a variety of podcasts on technology. Podcasts are great for getting in depth information about technical topics. Podcasts are also great because you can listen to them while doing other things, like driving to work. It's a good way to multitask. The only disadvantage is that podcasts can be long. Here’s two of my favorite podcasts:

<a href="http://www.dotnetrocks.com/">http://www.dotnetrocks.com/</a> <a href="http://msdevshow.com/">http://msdevshow.com/</a>

<h5 id="rssfeeds">RSS Feeds</h5>

While other media has chipped away at my RSS feeds, I still subscribe to a few blogs. RSS is good for following specific products or people. The disadvantage is that you can get behind if you subscribe to too many news sources. I subscribe to less than 20 feeds.

<h5 id="twitter">Twitter</h5>

I get a lot of news on Twitter now. There are two things I like about news on Twitter. First, because it’s a social network, the good stuff tends to find it’s way to the top. Second, if I don’t pay attention to it for a while, I don’t have a huge inbox waiting for me when I come back. It’s also great for keeping up with organizations, like PEW or the Visual Studio team. The big disadvantage of Twitter is it can be a cesspool of ignorant political bickering. You can't have a political discussion in 140 characters. The key is following the right people. I tend to unfollow folks who use Twitter for politics or idle chit chat.

Here’s a few accounts I like to follow: <a href="https://twitter.com/pewresearch">https://twitter.com/pewresearch</a> <a href="https://twitter.com/Ionicframework">https://twitter.com/Ionicframework</a> <a href="https://twitter.com/DotNet">https://twitter.com/DotNet</a> <a href="https://twitter.com/singularityhub">https://twitter.com/singularityhub</a>

<h5 id="prismatic">Prismatic</h5>

I’ve recently started using <a href="http://getprismatic.com">Prismatic</a>. It’s a service that delivers content to you based on your interests. It also tries to learn from you and deliver increasing good content (like Pandora for news). I’m still getting the hang of it, but <a href="http://getprismatic.com">Prismatic</a> offers interesting articles. I check it every few days. The key to making <a href="http://getprismatic.com">Prismatic</a> work is only starting with a few interests. I’m interested in a lot of things, so I checked lots of boxes and had to filter out a lot of noise. I ended up removing about 2/3's of the interests I started with.

<a href="https://flipboard.com/">Flipboard</a> also gives you streams of news based on your interests. It’s a beautiful app, but I didn’t like it. I could see why some people would prefer it to <a href="http://getprismatic.com">Prismatic</a> though.

<h5 id="hackernews">Hacker News</h5>

I used to read Hacker News, but it’s become too whiny and political for my tastes. Hacker news still has some good stuff though. I check it once in a while.

<h5 id="google">Google</h5>

Google News is good for getting news for a lot of sources, but it’s not specific enough for me. Google Now, however, has delivered some interesting content to my phone. It’s finds things related to what you’ve searched for or read in the past. My biggest Google Now win is when it delivered the answer to a problem I unsuccessfully searched for the previous day. It’s creepy, but amazing.

<h5 id="reddit">Reddit</h5>

I’ve recently started using <a href="http://www.reddit.com/">Reddit</a>. While I don’t use it for tech news, you could. There’s a subreddit (a topic specific group) for almost every technology. I found that the same thing that applies to Prismatic also applies to <a href="http://www.reddit.com/">Reddit</a>. It became much more useful once I stopped following so many topics.

<h3 id="filtering">Filtering</h3>

I prefer to do my reading in long sessions, so I use a "read it later" app to save links. I check the sources mentioned above when I get bored and save anything interesting to my “read it later” app of choice (Pocket). I ignore the vast majority of what I see, but filtering has gotten easier as I’ve gotten better at selecting news sources.

<h3 id="archiving">Archiving</h3>

If I find something good, I’ll save it to Evernote so I can refer to it later. I only do this for evergreen articles that won't lose their value over time. Usually these are on business development, software best practices, or personal development.

<h3 id="conclusion">Conclusion</h3>

Separating the signal from the noise is tough in the age of infinite content, but we have many tools at our disposal. What do you do to stay well informed?

How the Monty Hall Problem Can Make You a Better Software Developer

Wed, 04 Mar 2015 00:51:11 GMT

<p>Being called the smartest person in the world makes you huge target for trolls. Marilyn vos Savant was listed in the Guinness Book of World Records under "Highest IQ". This propelled her into the national spotlight. She then proved that IQ doesn't mean everything by becoming columnist for Parade. The listing also made her a popular target of criticism, especially by academics. There are whole websites devoted to proving her wrong. This is not one of them. This is a story about how she was right and what we, as software developers, can learn from her experience.</p>

<p>The Monty Hall problem is a famous math problem that's based on an old game show called "Let's Make a Deal". The game begins with three doors. One of the doors has a fabulous prize. You don't know what's behind any of the doors and each door has an equal chance of containing the prize. You are then asked to select a door. After selecting your door, the host of the show reveals one of the other losing doors. You are then given the option to switch.</p>

<p>The question is: </p>

<blockquote> <p>Would switching doors give you a better chance of winning the prize?</p> </blockquote>

<p>The intuitive answer is that switching doors provides no benefit. Remove one door and your 1 in 3 chance becomes a 1 in 2 chance of winning. Since each door has an equal chance of being correct, the remaining door isn't any better than the one you picked. This is the answer most people come up with when they first hear this problem.</p>

<p>This logic, while intuitive, is flat wrong.</p>

<p>The correct answer is that switching gives you a 2/3 chance of winning, as opposed to your 1/3 chance you have sticking with your door. The key to this problem is that revealing one of the incorrect doors doesn't change the initial probability. You already know one of the doors is going to be wrong. What is important is that the host is basically giving you the option to select two doors instead of one.</p>

<p>Here's another way to think about it. Switching and losing means that your initial selection was the right one. Your probability of winning with your initial selection is 1/3. Thus, the probability of you losing when you switch is 1/3, which means your probability of winning is 2/3.</p>

<p>If you still don't believe me, the Khan Academy explains this problem well: <br /> <a href="https://www.khanacademy.org/math/precalculus/prob">https://www.khanacademy.org/math/precalculus/prob</a><em>comb/dependent</em>events_precalc/v/monty-hall-problem</p>

<h3 id="thetimethesmartestpersonintheworldgotflamedbyeveryone">The Time the Smartest Person in the World Got Flamed by Everyone</h3>

<p>Marylin vos Savant answered this same question in her column in 1990. Even though she was correct, the public sent her a truckload of hate mail. Many academics also piled on the criticism. </p>

<p>Here's a sample of the feedback she received (<a href="http://marilynvossavant.com/game-show-problem/">Source</a>):</p>

<blockquote> <p><em>Since you seem to enjoy coming straight to the point, I’ll do the same. You blew it! Let me explain. If one door is shown to be a loser, that information changes the probability of either remaining choice, neither of which has any reason to be more likely, to 1/2. As a professional mathematician, I’m very concerned with the general public’s lack of mathematical skills. Please help by confessing your error and in the future being more careful.</em></p> </blockquote>

<p><strong>Robert Sachs, Ph.D. George Mason University</strong></p>

<blockquote> <p><em>May I suggest that you obtain and refer to a standard textbook on probability before you try to answer a question of this type again?</em></p> </blockquote>

<p><strong>Charles Reid, Ph.D. University of Florida</strong></p>

<p>And my personal favorite:</p>

<blockquote> <p><em>You made a mistake, but look at the positive side. If all those Ph.D.’s were wrong, the country would be in some very serious trouble.</em></p> </blockquote>

<p><strong>Everett Harman, Ph.D. U.S. Army Research Institute</strong></p>

<p>It took Marylin several tries to explain the concept well enough for the majority of her readers to understand it. I found her explanation to be clunky, so I posed the problem to my Facebook friends. What resulted was the longest comment string I've had in a long time. My friends, several of whom have advanced degrees, had a tough time with the problem. The people who knew the correct answer had a tough time explaining it to the doubters. </p>

<h3 id="whatcanthisstoryteachusaboutbuildingbettersoftware">What can this story teach us about building better software?</h3>

<p>There are several lessons this story can teach us about psychology, thinking things through, and humility.</p>

<h4 id="1peoplearebadatestimatingrisk">1. People are bad at estimating risk</h4>

<p>This story illustrates that people are not good at understanding probability. There's a whole slew of cognitive biases (brain fails) related to estimating probability. </p>

<p><a href="http://en.wikipedia.org/wiki/List_of_cognitive_biases#Decision-making.2C_belief.2C_and_behavioral_biases">List of Cognitive Biases</a></p>

<p>This is important to software development because much of what we do is estimate and mitigate risk. For example, mitigating security risks is incredibly important. Due to our inability to measure risk well, we may spend resources fixing low risk problems that were <a href="http://en.wikipedia.org/wiki/Availability_heuristic">recently featured in the news</a> instead of fixing high risk issues. </p>

<p>Risk also factors into software estimation. People are terrible at estimating how long it takes to do anything over a day. This is why agile software projects measure tasks using relative complexity (story points, T-shirt sizes, etc...) instead of hours. Agile projects also break down work into bite sized pieces, which are easier to comprehend. </p>

<h4 id="2watchoutforredherrings">2. Watch out for red herrings</h4>

<p>Another important aspect of software development is filtering out irrelevant information. In the Monty Hall problem, the host opening the losing door doesn't change the probability. You already knew one of the doors was a losing door. I find that it's important to remember this when I'm debugging code. Good testers tend to report more information than you need and it's up to you to figure out what's useful and what's not. </p>

<h4 id="3beskepticalofexperts">3. Be skeptical of "experts"</h4>

<p>Many of Marylin's critics were highly educated. All three of the quotations I mentioned were from PhD's, including one professional mathematician. In our society, we tend to take the opinion of experts at face value. Pew Research recently did a survey on the beliefs of scientists vs the beliefs of the public. (<a href="http://www.pewinternet.org/2015/01/29/public-and-scientists-views-on-science-and-society/">link</a>) This survey was widely reported on. </p>

<p>While the opinion of experts is vital, remember that they specialize in narrow areas. Any opinions they have outside of those areas should be subject to the same scrutiny that you give any smart person. Too often, people who are experts in one area are considered experts in other areas as well. A good example of this is when the media asks famous actors about their opinions on political issues. The tendency to allow irrelevant traits, such as beauty or skill in an unrelated field, to effect our judgement someone's ability is called the <a href="http://en.wikipedia.org/wiki/Halo_effect">halo effect</a>. </p>

<p>You can use the halo effect to your advantage. Dressing sharp and being a good conversationalist can increase your credibility. While it's acceptable to go a tech conference in a t-shirt and jeans, people will think you are more professional if you wear something nice. </p>

<p>The halo effect also applies to software. In the book <a href="http://www.amazon.com/exec/obidos/ASIN/0465051367/thweofdujew-20">Emotional Design</a>, Don Norman explains how people find aesthetically pleasing objects to be more effective. When building your own software applications, pay attention to the design of the interface. Making things look good will make your software appear to be more useful.</p>

<p>When doling out criticism, be nice. It hurts a lot less if you're later proven wrong. This doesn't mean you should sugar coat things, but you can deliver sharp criticism without being mean about it. Many of the people who wrote in nasty comments ended up apologizing for it once they realized their mistake. </p>

<h3 id="conclusion">Conclusion</h3>

<p>The story of Marilin vos Savant and the Monty Hall problem has many lessons for software developers. If you want to learn more about the topics in this post, check out the resources below. </p>

<p><a href="https://www.khanacademy.org/math/precalculus/prob_comb/dependent_events_precalc/v/monty-hall-problem">Khan Adademy: Monty Hall Problem</a> <br /> <a href="http://marilynvossavant.com/game-show-problem/">Maylin vos Savant: Game Show Problem</a> <br /> <a href="http://en.wikipedia.org/wiki/List_of_cognitive_biases#Decision-making.2C_belief.2C_and_behavioral_biases">List of Cognitive Biases</a> <br /> <a href="http://en.wikipedia.org/wiki/Availability_heuristic">The Availability Heuristic</a><br /> <a href="http://en.wikipedia.org/wiki/Halo_effect">The Halo Effect</a> <br /> <a href="http://www.amazon.com/exec/obidos/ASIN/0465051367/thweofdujew-20">Emotional Design (Amazon)</a></p>

Legacy Systems, Legacy Thoughts

Thu, 26 Feb 2015 12:56:46 GMT

There’s nothing like replacing a legacy software system to stoke the fires of self-righteousness. You get to pull some poor users out of the dark ages and save them from a system may have been state of the art last decade, but is junk now. (Ignoring the fact that the old system lasted that long because it did what it what the users wanted it to do.) It’s especially fun when the old system is so laughably bad that it was obsolete the day it was written. Unfortunately, these projects come with a few pitfalls.

The first pitfall is that you can end up building the same legacy system in a new technology. It's hard to transfer old paradigms into new ones and if you're not careful, you can end up repeating old mistakes. I worked at a company that was creating an ASP.NET web app built over an existing database. Many of the tables in this database had no keys or relational data. The original system was built on a mainframe using flat files. When that system was upgraded in the 90’s, the flat files were just copied over. There was no regard to modern relational database structuring. When the ASP.NET version came along, the plan was to just copy over each of the old pages, one by one. Management didn't take modern web and object oriented practices into consideration. Needless to say there was some debate between the developers and management.

The second pitfall can come while gathering requirements. When gathering requirements for the new system, it’s easy (and often correct) to reference the old system. There are two problems using the old system as the primary reference for requirements. First, the system sometimes does things a certain way because of technical constraints. I once worked on replacing a system that had lots of batch processes. Many of those processes were not needed because modern systems were fast enough to process those records on the fly. Second, many times, old systems don’t reflect the business practices of people who use them. There are lots of instances where users have to do something convoluted to get their old system to behave how they need it to. Watch out for these types of scenarios, fixing them is a good way to score brownie points with your customers.

The third pitfall happens when the builders of the new system don’t recognize the advantages of the old system. In the system I mentioned in the first point, the legacy system allowed for rapid keyboard entry. The new system, being a web application, did not optimize for keyboard entry. In the beginning, the developers ignored the users because of the “obvious” superiority of the new way of doing things. Eventually, we realized our error and created a keyboard entry optimized set of web controls. The users were much happier. While it may be fun to mock the old system, you should also pay attention to your users and make sure you aren’t creating a system that’s worse than what they started with. Just because it’s pretty and new doesn’t mean it’s good for the customer.

In summary:

Make sure your new system is using new paradigms. Don’t repeat legacy design.
Be careful when gathering requirements from the old system. Especially when it comes to implementation details.
Don’t make a new system that’s worse than the system you’re replacing.

How I Build Tech Talks: Part 1

Wed, 25 Feb 2015 22:29:22 GMT

Last year, I created my first tech talk and delivered it to several venues. I enjoyed the experience, so I decided to produce a new talk this year. This time though, I want to document the process of building the talk while I'm working on it. I think it's important to see things unfold while they happen. Often, you see a polished talk and you don't see the work that has gone into it. This isn’t meant to be a list of recommendations from on high, but a log of how I like to build talks. Feel free to use what works and forget what doesn’t.

<h3 id="qualifications">Qualifications</h3>

Last year, I gave two versions of my D3.js talk in five different venues. I've also delivered several talks at work. Additionally, I did speech and debate in college for two years. While I'm no Scott Hanselman, I know my way around a lectern.

<h3 id="step1topicselection">Step 1: Topic selection</h3>

Last year, I picked a topic I didn't know much about (D3.js). I picked that topic because I knew building a talk would force me to learn about it. This year, I want to deepen my understanding of a topic I have experience with. I work with ASP.NET MVC in my current job. Additionally, I enjoy building UI components. When I started using ASP.NET MVC a few years ago, I had a hard time finding information. The books on MVC cover the basics well, but the reference material is incomplete. (<a href="https://msdn.microsoft.com/en-us/library/ee703535%28v=vs.118%29.aspx">Example</a>) Doing a talk on building UI in ASP.NET MVC would deepen my own knowledge while helping others.

Building UI in ASP.NET MVC is a broad topic, so I drafted a list of subtopics to help me narrow my scope down.

Here's my, clustered into similar topics:

HTML Helpers Editor and Display Templates Custom Validation

Grunt / JS automation LESS and SASS Bundling and Minification

Web Performance

UI Testing (like Selenium) JavaScript Testing (like QUnit)

That's way too many things for an hour long talk. Each of the above clusters could be it's own talk. To narrow the scope, I'm going to remove anything that doesn't have to do with building UI components. This leaves me with the following list:

HTML Helpers Editor and Display Templates Custom Validation

<h3 id="step2generateatheme">Step 2: Generate a Theme</h3>

Now that I have a topic list, I want to create a theme for the talk. A theme gives structure to the talk and provides a narrative for people to latch on to. I believe that in software development, you should bake good defaults into easy to use components. This lowers the cost of development and increases the quality. Good components allow you to create a great user experience without having to drop a ton of code on each page. My theme for this talk is going to be how to build better software in less time.

Another thing I’m trying to do with this talk is build in more stories. Stories are one of the primary ways people communicate. Studies show that stories engage emotions, which provides a stronger connection than raw data.

<h3 id="step3generateanabstract">Step 3: Generate an Abstract</h3>

The next step is generating an abstract. An abstract is a summary of you talk that you can submit to conferences and user groups. It’s important to have a strong abstract because that’s how your talk is picked by conference organizers.

<h4 id="keystoagoodabstract">Keys to a Good Abstract</h4>

<ol> <li>A catchy title.</li> <li>A clear benefit to the audience.</li> <li>A summary of the topic.</li> </ol>

Here's my abstract:

<strong>ASP.NET MVC UI Recipes: Build Better Interfaces With Less Code</strong>

Who doesn’t want to get more done in less time?

ASP.NET MVC gives us an excellent toolset for building web applications. Unfortunately, due to it's rapid evolution, good documentation is hard to find. However, using some simple techniques, you can build user interface components that can speed up development while maintaining a clear separation of concerns. In this presentation, we’ll learn how to build custom controls, templates, and custom validation. Save time while creating cleaner code.

<h3 id="step4makeanoutline">Step 4: Make An Outline</h3>

The next step is building an outline. I don’t memorize my speeches, so the outline is what I study when I prepare. I use my outline to put my topics and demos into a logical structure. I tend to capture a lot of detail in my outlines and then make a simpler outline for reference. I haven't finished my outline yet, so I'm not going to share it.

<h3 id="conclusion">Conclusion</h3>

This is the first in a series of blog posts documenting my process for building tech talks. As I mentioned before, feel free to use what works and forget what doesn’t.

4 Steps to Better Non-Fiction Reading

Sat, 20 Sep 2014 11:26:30 GMT

I love to read. I've read over 40 non-fiction books in the past year (and all five <a href="http://www.amazon.com/exec/obidos/ASIN/B00957T6X6/thweofdujew-20">Game of Thrones</a> books). One of the problems I ran into is that when you read a lot, it becomes hard to recall what's in specific books. Reading is a waste of time if you can't recall what you've read.

To solve the retention problem, I use a four step process to remember more of what I've read. I base this process on what I've learned from a speed reading class I took in college and reading about the psychology of learning. I find that following this process allows me to read more books and remember what's in them.

This method works best on non-fiction books. Recent examples that I've read include <a href="http://www.amazon.com/exec/obidos/ASIN/1594484805/thweofdujew-20">Drive</a>, <a href="http://www.amazon.com/exec/obidos/ASIN/B0076DDBJ6/thweofdujew-20">So Good They Can't Ignore You</a>, and <a href="http://www.amazon.com/exec/obidos/ASIN/B000QCQ970/thweofdujew-20">The Art of Learning</a>. Most non-fiction books range from 200-500 pages and usually focus around a single primary thesis. Generally, there's about 50-100 pages of valuable content mixed in with a few hundred pages of <del>filler</del> supporting material.

<h3 id="coreprinciples">Core Principles</h3>

This process is based on two core principles from psychology.

<h4 id="1repetition">1. Repetition</h4>

Repetition increases retention. Everyone who's been through school knows this. Often, you get more out of reading something fast several times than one slow reading. Additionally, processing an idea in different ways will help you retain more knowledge. To increase retention, process knowledge in at least two different ways. It's also important to actively process information. It forces you to recall the information and exposes gaps in your knowledge. For example, read something and talk about it with your friends or listen to a podcast and write a one page summary.

<h4 id="2schema">2. Schema</h4>

When we learn things, we organize the knowledge in our heads into an organizational pattern called a schema. I like to think of schema as a tree of knowledge. The basic facts are the trunk, the major functional areas are the branches, and details are the leaves. When learning a new topic, it's important to get a high level view to create a structure on which you can attach details to. Here's an example from: <a href="http://en.wikipedia.org/wiki/Psychologyhttp://en.wikipedia.org/wiki/Psychology">Psychology - Wikipedia</a>. Notice how the whole field of psychology is structured into branches of increasingly grandular detail.

<h3 id="process">Process</h3>

This process focuses on building up a schema while exposing yourself to the ideas of the book several times. While it seems counter intuitive, this process doesn't take any more time than reading books from cover to cover.

<h4 id="1gatherbackgroundinformation">1. Gather Background Information</h4>

Begin by looking at the title, author, summaries, and reviews. I start with Amazon for reviews and Wikipedia for summaries. Google/Bing is your friend. The reason we do this is to get an idea of what the thesis of the book is and to find any useful criticisms of that thesis. This gives you a foundation to hang other facts off of and additionally gives you an idea of the other side of the argument.

For example, I recently began reading the book Grain Brain. Before I began reading, I wanted to get some background information on the book.

I started off with the Amazon page.

Decent summary and reviews: <a href="http://www.amazon.com/exec/obidos/ASIN/031623480X/thweofdujew-20">Grain Brain (Amazon)</a>

Most of the reviews of the book are positive, so lets find some different viewpoints. I did some Googling and found some decent resources:

A news article on the book: <a href="http://www.theatlantic.com/health/archive/2013/12/this-is-your-brain-on-gluten/282550/">http://www.theatlantic.com/health/archive/2013/12/this-is-your-brain-on-gluten/282550/</a>

A low quality criticism of the book (lots of straw men and cherry picking): <a href="http://www.forksoverknives.com/the-smoke-and-mirrors-behind-wheat-belly-and-grain-brain/">http://www.forksoverknives.com/the-smoke-and-mirrors-behind-wheat-belly-and-grain-brain/</a>

A much better critisism of the book: <a href="http://chriskresser.com/do-carbs-kill-your-brain">http://chriskresser.com/do-carbs-kill-your-brain</a>

Based on those resources, the book has useful information. There are some issues surrounding the extremeness of the authors recommendations. Now that I understand the basic premise of the book, I can focus on the details.

Another way to get a book summary is to listen to a podcast about the book. Many authors like to go on podcasts to market their books and talk about their ideas. I've learned about several books by listening to podcasts about them.

<h4 id="2getafeelforthebooksstructure">2. Get a feel for the book's structure</h4>

Next, open up the book and look at the table of contents. This will give you an idea of how the book is structured and may point you to useful resources. For example, I recently finished reading <a href="http://www.amazon.com/exec/obidos/ASIN/1594484805/thweofdujew-20">Drive</a>. When I opened the table of contents, I noticed that the author includes a short summary in the back of the book. I read that part first to get a feel for the book. After examining the table of contents, read the introduction and conclusion of the book. At this point, you should have a good idea of what the book is about and what information the author is going to use to support their thesis.

<h4 id="3readtheactualbook">3. Read the actual book</h4>

By the time you get to this point, you should already have a good idea of what the author is going to say and how the book is structured. The advantage of pre-reading is that you can now focus on the details.

This gives you two options. First, you can read the book quickly, grabbing details that jump out at you. Most non-fiction books contain a lot of filler. It's nice to know you can skip over it without missing anything important. I use this tactic for general business books, like <a href="http://www.amazon.com/exec/obidos/ASIN/0066620996/thweofdujew-20">Good to Great</a>. Most of the time, there's about 50 pages of useful information sandwiched between 300 pages of fluff. Second, you can carefully read the book. Because you've already learned the basics, it's a lot easier to pick up the details. Which path you take is dependent on your interests and the quality of the book.

<h4 id="4commonplaceanddiscussthebook">4. Commonplace and discuss the book</h4>

To further increase retention, you need to process the book in different ways. Preferably active ways that require you to recall the information you've learned. I like to talk about interesting books that I've read with the people around me.

Another way to increase retention is to keep a <a href="http://www.ryanholiday.net/how-and-why-to-keep-a-commonplace-book/">commonplace book</a>. A commonplace is a set of notes and quotations from books that you've read. Many famous historical figures kept these, sometimes copying large swaths of texts into notebooks for future reference. For each book I read, I create a one page summary and file it in OneNote. Forcing yourself to recall and process your book helps to lock in the knowledge.

<h4 id="conclusion">Conclusion</h4>

Follow these four steps to increase your retention and get more value out of the non-fiction books you read. This tactic is a great way to learn new skills and improve your life.

Building My First Tech Talk

Thu, 12 Jun 2014 22:38:31 GMT

Ever want to give a tech talk to your peers? I recently built and delivered my first tech talk and I'd like to share my experience.

<h3 id="motivation">Motivation</h3>

There are several factors that have contributed to my desire to to make a tech talk. The first is that one of my career goals is to become more involved with my local developer community. I am fortunate to live in a city that has a vibrant technical community and I wanted to contribute something to that community.

If you would like to know some of the benefits of becoming involved more in your local tech community, watch this video (It's currently free): <a href="http://pluralsight.com/training/Courses/TableOfContents/get-involved">Get Involved</a>

The second reason is that when I was in college, I participated in forensics (speech and debate) and miss publicly speaking. I've thought about joining Toastmasters or a similar organization, but doing a technical presentation is more accessible and congruent with my career goals.

The final reason is that the best way to learn something is teach it. Teaching a subject requires in depth knowledge and the fear of looking like an idiot encourages you to thoroughly learn your subject material.

<h3 id="process">Process</h3>

The first step in build a talk is picking a subject to talk about. For this talk, I decided to demonstrate <a href="http://d3js.org/">D3.js</a>, a JavaScript data visualization library. After using it at work and seeing how powerful the library is, I really wanted to dig into it more.

I recommend picking something you are personally interested in, and not worry about whether or not you are currently an expert in your topic. Obviously don't pick something you know nothing about, but don't be afraid to branch out. Researching the presentation will help you become an expert.

The second step is to research. For my talk, I read <a href="http://www.amazon.com/exec/obidos/ASIN/B00BSG68UQ/thweofdujew-20">Interactive Data Visualization for the Web</a> by Scott Murray and many online tutorials. I also built lots of small demos.

After some research, start building an outline. This outline will probably change with new information, but it's good to get an idea of what you want to talk about. Having an outline helps focus your research efforts.

While researching, I also built the demonstrations that I used in my presentation. My goal was to show the power of data visualization on the web, so the focus of my presentation was walking through lots of examples.

Tech demos have a tendency to fail, so it's important to keep things simple and minimize dependencies. I made it a point to make sure my demos didn't rely on any outside components. No databases, no web services, just local code. I also put my code on Github, so I could easily setup my project on another computer if I needed to.

After building the demo, and the outline, it's time to put together your talk. If you have slides that you want to use, build those now. I had a few slides, but most of my presentation was examples and code demos.

After that, practice! Try to run through your presentation at least a couple of times. Rehearse in your head and out-loud. Give your talk to the dog or cat. Make sure your timing is good and your transitions are smooth.

Also, don't write out your talk and memorize it. This will stifle your delivery and ability to go with the flow of your audience. Rehearse your key points and don't worry about getting everything word for word. Your audience changes with every performance and it's important to be able to cater to that audience. Memorizing a written speech will prevent that from happening.

<h3 id="lessonslearned">Lessons Learned</h3>

So far, I've given my presentation twice. Once at the local .NET meetup group and once at my current employer. Both situations were different and provided different learning opportunities.

The one thing that surprised me was the awkwardness of transitioning in and out of PowerPoint presenter mode. My presentation initially consisted of an alternation between slides and demos of visualizations on the web. Unfortunately, PowerPoint made those transitions really awkward. To fix this, I ended up pulling those slides and just showing the demos. Less PowerPoint is not a bad thing.

I ran into another issue when I gave my presentation to my current employer. I didn't realize that I was also giving my presentation to the non-technical staff as well as the developers. To adapt, I spent more time talking about general data visualization concepts and less time walking through code. I also told my audience that the second part of the talk was more technical. I can't stress enough about how important it is to cater to your audience.

I was surprised at how well the question and answer portion of the talk went. Studying up for the presentation really paid off.

I also felt like I adapted to changing circumstances well. This is probably because my forensics career in college was spent in limited preparation events, where you need to be able to think on your feet.

I put all of my talk materials on Github, so people could follow along and download the code themselves. I had a number of positive comments about that.

<ol> <li>Adapt to your audience and your situation. Don't regurgitate a canned speech.</li> <li>Publicly share your demo code and slides.</li> <li>Beware of potential technical difficulty. Pre-load any web pages and make sure all of your code functions correctly. Make sure all of of the A/V stuff works (like font sizes and slide transitions).</li> </ol>

<h3 id="conclusion">Conclusion</h3>

I am glad I made this talk and plan to make more in the future. The whole experience was highly educational and it felt good to make something useful for the community. I can't recommend it enough.

I'll be speaking at <a href="https://www.thatconference.com">That Conference</a> in August, so please check out <a href="https://www.thatconference.com/Sessions/Session/82">my talk</a>.

<a href="https://github.com/DustinEwers/D3-DotNetMVC-Demos">Talk Code and Slides</a>

3 Tips To Help You Ace Your Next Technical Interview

Thu, 05 Jun 2014 11:27:13 GMT

I used to be a little nervous about doing technical interviews. Even though I spend much of my free time learning about technology, I'm still afraid that I'll be perceived as an idiot. To combat this feeling, I have developed several practices to improve my interviewing skills.

<h4 id="1reviewyourresume">1. Review Your Resume</h4>

Every interview I've been to asks you for examples from your work history. To prepare for these types of questions, review your resume before each interview. For each job on your resume, think about the challenges you faced, what technologies you used, and what you were proud of. Think about stories you can tell from previous jobs to potential employers. Practice telling those stories in your head or in front of a mirror. This exercise <a href="http://en.wikipedia.org/wiki/Priming_(psychology)">primes</a> your brain. When prompted, you will be ready with a story from your work history.

<h4 id="2practiceansweringstandardtechnicalquestions">2. Practice Answering Standard Technical Questions</h4>

Depending on the technology stack and what job you are interviewing for, most employers ask a list of standard questions. You will get a feel for this list as you do more technical interviews. I'm an ASP.NET Developer, therefore I get questions on the following topics:

<ul> <li>Basic OOP (Encapsulation, Inheritance, Polymorphism)</li> <li>Abstract Base Classes vs Interfaces</li> <li>The ASP.NET Page Lifecycle</li> <li>String Concatenation using StringBuilders</li> <li>Basic Design Patterns</li> <li>Linq</li> <li>Generics</li> <li>Job Specific C# and ASP.NET Trivia</li> <li>Major features in new releases of ASP.NET (async, await, etc...)</li> </ul>

To prepare, you need to research the concept, practice describing the concept, and for more complex questions, come up with relevant examples. For example, when describing OOP concepts, come up with a novel example. Instead of the usual examples of vehicles or animals, try something a little different, like a beer factory or different types of ducks. The key here is to show that you understand the concepts, as opposed to being able to memorize a textbook example.

<h4 id="3practiceyourpublicspeakingskills">3. Practice Your Public Speaking Skills</h4>

I learned my public speaking skills by competing in college forensics (speech and debate). It was a great experience that has helped me in many ways. I highly recommend competitive speaking if you have the opportunity. If you are no longer in school, you can join <a href="http://www.toastmasters.org/">Toastmasters</a> or practice with a group of your peers. Meetups are a good way to find groups of people to practice with. You can also give presentations at user groups and conferences. Practicing your public speaking skills on a regular basis will help you eliminate filler words from your vocabulary and help you learn how to handle fears surrounding public speaking. If you can explain a complex technical concept to a group of thirty people, then you should have no problem with three people in a job interview.