Forem: Kel

Safety and Confidence

Kel — Wed, 01 Jan 2020 18:00:00 +0000

As employers we want confident employees. We want people who can get things done with as little supervision as possible. We want to give them money and in exchange they give us value from their effort.

And yet, that's not what usually happens. People require a lot of supervision, they aren't motivated. So why not? Why aren't all your employees rock stars?

Fear

It starts with fear. What are your employees afraid of?

Here's an example: Imagine a meeting, someone speaks up and says something ignorant. They don't fully understand the implications of what was going on, say something, and look foolish. At best, people will laugh, shaming them. At worst, someone might yell at them. It could result in them getting a bad review. It could result in them getting fired.

We decide whether risks are "worth it" by weighing the possible rewards against the possible consequences. Your employees are weighing getting the job done against the possibility of getting fired. If they take the "safe" path, and stay quiet, they'll get the job done slower, and run less risk of getting fired. If they're less efficient, they're safer.

Safety

On the Getting Apps Done podcast, we talk about safety in the workplace quite a bit, but it's worth describing again here: "Safety" in this context means that even if you take a risk and it fails, the consequences won't harm you. You will not lose your job, you will not be shamed, you will continue to have food and shelter and people in your life.

Individuals can take actions to increase their safety. The most straight forward is saving money. It's less risky to take chances at work if you can afford to be laid off and find another job.

But there are things we can do as employers too. Talk to your employees about the risks they could take. Discuss the consequences of those risks and see if there are ways to mitigate them.

A complex example might be a customer project where a mistake could throw off the timeline. The further out the timeline is, the more likely something will go wrong. A timeline should have a buffer for failure. The more experienced you get as developers, as managers, as leaders, the closer to that edge you can get. You'll know the most likely risks and how to plan for them and the less buffer will be required.

This is the whole purpose of Agile! It goes on the assumption that you're going to mess up and that iterating the plan will be required. Over time your metrics about work estimates get more accurate and you can plan better. Agile creates a safety net on failure by making sure each piece of work is "bite sized" and requesting regular feedback to verify that the work completed matches what was expected. Maybe you messed up an individual ticket, or maybe a sprint. But it's unlikely the entire project would be considered a failure if you've been getting constant feedback.

We apply this strategy of limiting consequences to timelines, projects, and processes, but it's rare that it's applied directly to people.

In the earlier example of a meeting: Make it clear that ignorance is fine! People are so trained to be afraid of showing their ignorance that they often won't ask questions when they don't understand something. Make it clear that asking questions is a safe thing to do, and even an expected thing to do.

Make it safe for your employees to fail.

Trust, Responsibility, Consent, Confidence

When you discuss risks with your team, ask them questions until you understand their viewpoints, and most importantly, trust what they tell you. They're going to be wrong sometimes and that's OK! In exchange for your trust, they consent to being responsible for what they agreed to.

This is where a lot of organizations break down. Consent to responsibility has to be voluntary, because otherwise it's not consent! If you threaten them you're not trusting them, you're forcing them, you're coercing them.

For many, the idea of being responsible for your own actions is just assumed, but the first example in this article points out that sticking your head out can impact someone's safety and their family's. We can't perfectly predict the future, and being responsible for something's outcome is always a gamble. If taking on that responsibility is required by your team, ask them what it would take for them to agree to it. Support them with safety.

Let's go back to that timeline example. You ask the team how long it will take and they say 10 weeks. You list out the possible failure points, and make plans for the most likely, or the ones with the most impactful consequences. And then you do it. And if it goes great or it bombs, responsibility is what people agreed to. Everyone will make mistakes and instead of trying to bury or hide from them, they'll learn from them.

Learning from your mistakes is the road to confidence. The more you know you can safely handle the more confident you are in your own ability. By creating an environment that's safe, people can learn that confidence by making mistakes over and over again, and if they're responsible for their own actions, then they'll have pressure to avoid that as much as possible. They can make decisions based on actual risk instead of "risk of getting yelled at by the boss".

Do the Impossible

Having a perfectly safe environment is impossible, but what you can do is lower the possibility of dangerous consequences. You can do this by making an environment that's consensual, that's safe, and where people are free to do the work they want to do to the best of their ability.

You can create an environment of trust, where you as an employer trust your employees to succeed and fail. When you let people fail and pull themselves back up again, you teach them confidence in their own abilities.

Help them all be rock stars.

-Kel

Compromise and Test

Kel — Mon, 12 Nov 2018 17:41:03 +0000

Photo by rawpixel on Unsplash

In my previous post I talked about what to do when presented with a question of priorities. I argue that the answer is to do "both". But what about when those two priorities are mutually exclusive? "Do we make the button green or orange?" You can't really do both in this case, right?

When two people disagree on a choice like this, it often means there's a fundamental difference in understanding of the topic itself. Maybe they 'weigh' the priorities differently. In the example of "green" vs. "orange", maybe they're really arguing "positive" vs. "bright".

The first step in any disagreement is to get people talking it through. With luck, they can work it out just by sharing their own understandings of the subject. But fairly often the opinions will be strongly held, and difficult to change. So then what?

The answer is exactly the same as the question priorities: Do them both.

In this case, it's not a question of difficulty, but of cost. Doing them both costs twice as much, but often will lead to a better overall solution. This is the same idea behind A/B testing where you put both options out there and let the data decide.

Even for simpler things, where 'common sense' dictates one is probably better than the other, data (or customer feedback) can often reveal completely different understandings.

And beyond ending up with a better solution, this is another way to get arguing team members to compromise and work together, which is almost always more valuable than getting a button color just right.

The Choice of Priorities

Kel — Mon, 22 Oct 2018 21:17:40 +0000

Photo by Brendan Church on Unsplash

Recently my daily feed was filled with a discussion about "What's more important? Writing maintainable software, or shipping software?"

There was a lot of back and forth about code quality, technical debt, not being able to sell something that isn't complete, and all the other points you would expect in this type of argument.

In the end, I'm pretty sure "shippability" was "winning", but I want to make a different point: The fact that you're having an argument about it, that many people have strong opinions on both sides, means that both are important.

Do them both.

Yes, that's more difficult. But that's how you get better, and it's why people pay more for experienced developers.

(If you're new, though, definitely just get something done and make it better over time. "Don't let perfect get in the way of good enough.")

Your interview questions are awful (but we can fix them)

Kel — Wed, 17 Oct 2018 17:17:16 +0000

Photo by Brendan Church on Unsplash

The first time I was involved in a technical interview I was asked to present and grade a coding question: "What does this script do?" The candidate was then handed a print out of a (relatively) simple VBScript that changed the computer name of a Windows PC.

Only one candidate answered correctly. Every other candidate failed the question with an "I don't know."

On first glance, this seems a reasonable question. Part of the job they were interviewing for often required working with scripts to deploy computers and software. I told them that we weren't looking for a specific answer, just a general idea of "What does this do?" The candidate failing to even make a guess seems like an interview fail. They couldn't think on their feet. They couldn't think creatively.

But was it really a failure of the interviewee?

As a test, we handed out that same question to a few of non-technical folks in the office. All of them answered correctly within a minute of skimming it by looking at method and variable names and guessing.

It's been a long time and many interviews since those first ones and I now look at their failure to respond as a failure on my part as the interviewer. If a non-technical person could answer the question correctly, most of these candidates should have gotten it right, too. So why didn't they? Why did they only answer with a "I don't know?"

Fear

Photo by Ben White on Unsplash

Job interviews are scary. Unless they don't need the job, there's real risk involved in failing an interview. Paying bills, making rent, supporting a family, growing their career in a direction that really excites them. The more they want or need the job, the more that fear is present with them in an interview.

An important part of an interviewer's job is to help them relax. You're not going to learn the full range of their skills if they're too nervous to answer your questions. The easiest way to help a candidate relax is to help remove their fear of failing. You can do this surprisingly simply: Ask them more questions that they're going to fail.

It seems backwards, right? But the goal here isn't to catch them in a trap, but to show them that answering a question incorrectly is safe to do. Dig into their wrong answers, see how they got there. Ask similar questions to see if they know related information. If they look nervous, tell them it's ok to not know the answer.

Some people think interviews should test for "handling stressful situations". Unless your business is in high stress situations (think: disaster relief operations), then this is bullshit. It's your job as an employer to provide a safe place to get work done.

Part of what you have to do to measure a candidates full skill is prove to them that you're not going to judge them arbitrarily. Prove to them that one wrong answer will not keep them from getting a chance at a job.

So what should I have done differently? I was on the right track, reassuring them that guesses were fine, but I didn't go far enough in helping them relax or preparing them to answer. And part of that was due to the specificity of the question itself.

Digging into a skill

When you have a question with a specific answer you create a very obvious point where the candidate can fail. They know getting the job relies strongly on the correct answer, and that fear of failure will be eating up most of their thoughts.

To help mitigate this, you ask lots of questions. Think about it like this: Would you prefer one chance, 0% or 100%, on passing a test, or 10 chances, where it's possible to get a 70% passing grade?

In the example of the computer rename script, the skill I was looking for was "The ability to work with scripts". Preferably creating and editing, but just being able to read them to see if it "did what you want" would have been fine.

A better question: "Have you ever used a script to automate a task before?"

"But wait!" you say. "That answer isn't measurable! How do I know if they got it right?!" Answer: You ask more questions.

For example: If the candidate said yes, ask them about the time they used it. Ask them about what it did, how many computers it ran on. Ask them where they found the script, and how they knew what it did.

Even if they said no, they still haven't necessarily failed. Ask them if they think they could "figure it out." (I've yet to interview a technical job candidate who wasn't confident they could figure something out that they didn't know given time and google). Now do the handout. The handout in our interview was an actual script we used daily. It was an accurate representation of the job. Tell them that. It gives them incentive to really try figuring it out since it's the job they want to do. For an even more accurate job representation, hand them a laptop with Google ready. Letting someone know that you won't arbitrarily limit their tools to get a job done does wonders for relaxing them.

By the power of your beard and Google, figure out the answer. Photo by rawpixel on Unsplash

Measuring a skill

After reading the above, you're probably thinking "But that question sounds too easy with all that help". You're right! And isn't that great? Think about how many candidates could show that they could really do the job. We just went from one, to (likely) all of them.

On top of that, if you went down the first question path, you know how deep their scripting skills go. You can measure it relative to your own skill. Are they better at scripting than you? Worse? Maybe they've written lots of scripts, but in different areas than yours. Write that down. Those are all important impressions to use when comparing candidates against each other.

Before you begin an interview, you should have a list of specific skills you're looking for and a list of open ended questions that can help candidates tell you about times they've used those skills.

Once you have that list, talk to them until you can answer these questions:

Do they know more than you?
Do they know less? How long would it take you to train them to a level of competence needed to do the job?
Do they have other, similar skills to make up for not knowing this specific skill? How deep does that skill go?
How excited are they about the skill. Is it an interest? Something they hate but do anyway?

A helpful "trick" for getting to the depth of a candidates skill is to tell them exactly what you're looking for! They'll be eager to show you that they can do it, or to show you skills similar to what you're looking for.

Keep in mind the real question you're trying to answer: Do they have the skill and desire necessary to do the job? If you can't confidently say 'yes' or 'no', keep digging, keep asking questions. I really can't stress this enough. This is important. You're in a position of authority - in a position to approve or deny them livelihood. If you reject someone for a position, you should be prepared to explain the reasons why for your choice.

Note: I've found it common that interviewers don't feel confident enough in their own abilities to judge someone else. Two things to keep in mind:

You're measuring their skill relative to yours. You don't need to know everything about a subject to do that.

Someone, likely your manager, thought you were qualified because you had the skills they're looking for. You can do this.

If you really aren't qualified, though, make sure someone else in the room is. (For example: back when I gave that first interview, you wouldn't have wanted me to grade someone's diplomatic skills.)

Comparing candidates

Once you have the relative skill of candidates, it's pretty straightforward to compare them. Once again, though, you should be able to confidently describe why one candidate is better than another. Use specific terms. In a perfect world, you would be able to coach a failed candidate explaining the things they should work on.

Also, you should have multiple people performing these skill measurements, and the people doing those measurements should have the skill level you're looking for. (There's no real point in having your worst communicator interviewing someone about their email skills.)

One other thing to keep in mind: Sometimes a candidate comes along with a great set of skills that doesn't neatly fit into any one role. If you can make it work in your organization, these people make great employees. The diversity of those skills can lead to innovative solutions to difficult problems. When you can: fit roles to people, not people to roles.

Iterating your process

A lot of my opinions on interviews formed after my boss handed me a stack of developer resumes and told me I had 30 minutes to screen each of them for the necessary tech skills. Three or four interviews a day, generally given back to back, for a couple weeks.

During that time, I iterated. I wrote down which questions worked well to draw out a candidates skills and which ones didn't. Most of the time I could confidently tell within those 30 minutes whether they had what we wanted or not. And, if I wasn't confident, I passed them on anyway. I didn't want my gut 'feeling' to be the deciding factor on someone's employment.

But I was mostly surprised at how effective this method was. At the end of every interview, I could accurately communicate their skills relative to mine to my manager so he knew which ones to interview next, and I could repeat the results of the process with the next candidate.

Iteration is always important. Something I've learned relatively recently is to keep metrics at each 'stage' of an interview process. Every stage acts like a 'filter'. They're an arbitrary line in the sand that candidates have to make it across. "The top 10 candidates". It's important to know where people fall out and if great candidates are falling through. If you see a problem, fix it and try again.

Some additional reading on the subject: We’re Bad at Interviewing Developers (and How to Fix It). (I swear I didn't intentionally pick the same title. Great minds think alike?)

Conclusion - Interviews vs. Tests

Photo by rawpixel on Unsplash

Finally, I'm not Google or Facebook. When you start hiring on that scale, you need more specific metrics to be able to assure relative consistency of skills. Those types of questions have become the 'standardized testing' of jobs.

If you're not hiring on that scale, then you likely just want more developers like the ones you have. Let them interview and make good decisions from that.

And if you do need metrics, test, but don't grade based on the results of those tests. Try to avoid letting your measuring instrument influence the results of what you're trying to measure.

React and Redux

Kel — Mon, 18 Jun 2018 22:07:23 +0000

For the longest time after React was released I had difficulty really understanding how it was supposed to be used. Coming from years of MVC/MVVM experience in Java, C#/WPF, and Angular, React seemed strange. The basic tutorials and examples showed 'how' you do something, but never why, and there was pretty much no separation between view and controller logic.

Eventually I sat down and wrote something using React and Redux, following the 'best practices', so I could understand the decisions that went into the frameworks and how they could be used.

Components

So what did I learn?

First, React is a different way of thinking of applications, but also, it's almost entirely concerned with view and view state. MVC generally separates the view state from the view and keeps it in the controller along with other application state information and in MVVM, the entire purpose of the 'VM' ViewModel is to keep track of view state. But in React, these two are combined into one abstraction called a "Component".

Components are relatively simple. They contain the logic for rendering your view to the page given a view state, and optional methods for changing that state.

A simple 'stateless' component is just the render logic. These can be represented by just a function that take a "props" object.

function Welcome(props) {
  return <h1>Hello, {props.name}</h1>;
}

Note: I'm using JSX in these examples. It's a layer on top of your javascript that lets you write HTML-like code elements that are compiled into regular javascript. I recommend reading the JSX intro for more information. (It also wreaks havoc on my current code highlighter.)

Components can contain other components, creating a component 'tree'. In this way, it's just like HTML, where an HTML element can contain other elements.

function Welcome(props) {
  return <h1>Hello, {props.name}</h1>;
}

function TimeDisplay(props) {
  return <h2>It is {props.time}.</h2>;
}

function Greeter() {
  return (
    <div>
      <Welcome name="World">
      <TimeDisplay time={new Date().toLocaleTimeString()}/>
    </div>
  );
}

Stateful components that have states that can change are generally more complicated and derived from a 'Component' base class. State updates are triggered by external events (usually UI) by using the setState() function.

This example will update on every interval "tick" creating a clock.

Note: This example is pulled almost entirely from the React documentation on State and Lifecycle.

Updates, rendering, and the Virtual Dom

When a component updates its state, it causes a re-render. The current component and its children will update.

Instead of directly updating the DOM, components update the "Virtual DOM", which is a DOM tree in memory. It's not rendered directly to the browser. This virtual DOM is then compared against the 'real' DOM and the real DOM is updated with just the changes between the two.

Image Source

Combined with the 'reactive' component updates (the component only updates in reaction to setState()), this makes React quite good at only updating what's necessary and minimizing the visible page updates (generally the most computationally expensive part of a change.)

The trade-off for this performance is higher memory use: The application's component tree is in memory twice. Because this is all abstracted away from the application developer, though, it allows the framework to optimize performance and is generally not something you need to think about.

What about the rest of the app?

React's simple pattern is quite flexible, allowing for state, view, and events, but it's also quite limiting. The component tree pattern requires your dependencies to be passed through the entire tree to get to child components.

This can get especially awkward if you introduce a new UI component that needs to reference a piece of application state logic that's not used in that area of the UI. You have to either add it to the all the parent components or alternatively use some kind of js 'global'. Neither is a good solution. Your application state rarely mirrors the UI.

Redux for application state

The solution to this problem is to move the application state into a separate store. The most popular is Redux, though there are plenty of other options.

Redux provides three main things:

An application level state store.
A way of updating that store from anywhere in the UI.
A way of updating the view state of components when the store is updated.

Redux is unidirectional, meaning events always go through it in one way.

React component (events) => Dispatch (actions) => Store update (reducer) => Component update (connect)

Let's go through this flow in order.

An event can be generated from anywhere, but is generally a UI event like a mouse click.

Note: Handling events in React has a bunch of caveats. As always, checkout the docs for more information.

class SpaceShip extends React.Component {
  moreSpeedClick = (e) => {
    e.preventDefault();
    console.log('zoom');
  };

  lessSpeedClick = (e) => {
    e.preventDefault();
    console.log('mooz');
  };

  render() {
    return (
      <div>
        <div>{this.props.currentSpeed}</div>
        <button onClick={this.moreSpeedClick}>More Speed</button>
        <button onClick={this.lessSpeedClick}>Less Speed</button>
      </div>
    );
  }
}

This event creates a Redux Action. Actions are simple objects that describe what update needs to happen in the store.

// make it go faster by an increment of 1
{ type: "faster", increment: 1}

Redux recommends creating "Action Creators", which are just functions that create these objects. Right now our actions are very simple, but in a larger app they might have lots of properties or even logic, so a function helps keep things clean.

function faster(increment) {
  return { type: 'faster', increment: increment };
}
function slower(decrement) {
  return { type: 'slower', decrement: decrement };
}

These actions are 'dispatched' through the dispatcher. The dispatcher is passed to the component in its properties and passes action objects to redux.

class SpaceShip extends React.Component {
  moreSpeedClick = (e) => {
    e.preventDefault();
    this.props.dispatch(faster(1));
  };

  lessSpeedClick = (e) => {
    e.preventDefault();
    this.props.dispatch(slower(1));
  };

  render() {
    return (
      <div>
        <div>{this.props.currentSpeed}</div>
        <button onClick={this.moreSpeedClick}>More Speed</button>
        <button onClick={this.lessSpeedClick}>Less Speed</button>
      </div>
    );
  }
}

The 'store' itself is a plain javascript object. Unlike Angular, the store object isn't directly manipulated or observed by Redux and can be arranged in anyway that makes sense to the application.

When an action is dispatched to the store, they're passed through functions called 'reducers' which take the previous state and an action, and then returns an updated state object. The common pattern is to use a switch statement on the 'type' of the action objects. Because this is just a function and plain javascript objects, however, you can do whatever you want.

function spaceshipReducer(state, action) {
  switch (action.type) {
    case 'FASTER':
      return { speed: state.speed + action.increment };
    case 'SLOWER':
      return { speed: state.speed - action.decrement };
    default:
      return state;
  }
}

const initState = { speed: 0 };
const store = createStore(spaceshipReducer, initState);

One of the requirements of Redux applications is that your store be "immutable". This means that instead of updating existing objects, you entirely replace them. This allows you to do simple reference comparisons that can greatly impact the performance of larger applications. The downside is it can make your reducers considerably more difficult to read.

// this does the same thing as the 'faster' case above
// You would use this pattern for more complex state trees
return Object.assign({}, state, {
  speed: state.speed + action.increment,
});

Note: Read more in about immutable changes in the redux basics tutorials. If using newer javascript features, there are a few other options as well.

After any action is received by the store, it fires an update event. React components are wrapped in a container component that triggers updates when the store updates. A component is wrapped using the redux 'connect' function that maps the application store to the component properties. If you use best practices (immutable), this map is bright enough to tell when that section of the state is different or not. Other than that, the wrapper component doesn't do much magic. It simply subscribes to the store 'update' event and uses setState() when something changes to trigger the normal react update.

It's also common to map the dispatch actions to properties rather than passing the entire dispatch function in.

import { connect } from 'react-redux';

function mapStateToProps(state) {
  return {
    currentSpeed: state.speed,
  };
}

function mapDispatchToProps(dispatch) {
  return {
    faster: (increment) => dispatch(faster(increment)),
    slower: (decrement) => dispatch(slower(decrement)),
  };
}

const SpaceShipContainer = connect(
  mapStateToProps,
  mapDispatchToProps
)(SpaceShip);

And here's all of it together.

Note: You'll see a "Provider" component in the full example. The Provider simply makes the redux store available to any connected "container" component without the developer having to do anything. It does this by utilizing some low-level React features that you generally don't need to worry about.

Redux Middleware and async actions

This covers the basic cases of reacting to UI events, but doesn't help with working with web services and AJAX callbacks. In the Angular world, these functions are usually placed into services that are injected into your controllers. In general, Redux doesn't provide a solution for this, but what it does provide is a centralized way of passing messages around.

With Redux, the only things that are injected to a component is the state and dispatcher. The state is just a plain object, but the Redux provides a way of extending the capabilities of the dispatcher through the use of "Middleware".

Middleware is a function that is called before the action is passed on to the reducer. One of the simplest and most commonly used middlewares is redux-thunk, which allows you to dispatch async actions. Instead of passing an action object, you pass in a function to the dispatcher. Redux-thunk sees the function and calls it, passing in the dispatcher and state.

When I say simple, I mean it. Here's the important part of redux-thunk:

if (typeof action === 'function') {
  return action(dispatch, getState, extraArgument);
}

return next(action);

If the action is a function, it calls it, passing in the dispatcher, getState accessor, and an optional argument. If the action is not a function, it's just passed on to the default behavior.

Note: getState() returns the current state at the time of calling. This has two purposes: You can get the state before and after 'dispatch' has been called (letting you perform complex logic in your action creators), and you can get the state after an async action completes (important since the state could have changed since the action began.)

Here's an example of what a 'thunk' looks like. Compare this action creator to the 'faster' and 'slower' examples above.

function warpSpeed(warp) {
  return function(dispatch) {
    // we're using setTimeout for our async action
    // but this could be an http call, or whatever
    setTimeout(() => {
      // dispatch the state update action
      // this could also be another thunk!
      dispatch(faster(warp));
    }, 1000);
  };
}

// warpSpeed returns a function that is called by the middleware,
// but the function signature is the same as before.
dispatch(warpSpeed(10));

This simple pattern acts a lot like dependency injection at the function level, or a command/mediator pattern. If you need additional 'services' or configuration you can inject them through the "extra Parameter" option.

function warpSpeed(warp) {
  return function(dispatch, getState, extraArgument) {
    setTimeout(() => {
      dispatch(faster(warp));
    }, extraArgument.warmupTime);
  };
}

I have somewhat mixed feelings on this pattern since it's mixing your store updates and mediated command messages, but passing everything through the dispatcher does keep things simple, so I don't consider it a big deal.

Other thoughts

Redux is worthy of an entire article. It’s both opinionated, but flexible. I recommend reading through their entire documentation to really get a handle on how it can be used. Also, by learning Redux you'll have a lot of the basic React concepts reinforced.

There are also plenty of alternatives. Checkout MobX for something more similar to Angular (more magic), or even roll your own (no magic)!

Since I wrote this article, I created my own alternative to redux called Honk. It was created for simple projects with typescript in mind. Check it out!

It should also be mentioned that Angular and Vue are both component heavy now, having taken a lot of cues from React. Learning one will likely help you with the others.

Finally, I want to mention that react + redux using best practices is verbose. There's very little 'magic' that hides code from the developer, and combined with redux's "best practices" you end up with lots of extra infrastructure code. The up sides are better understandability - you'll often hear people say react and redux is easier to 'reason' about - and better code separation, especially for larger projects and teams.

Good luck, and happy coding!