DEV Community: David Leger

Kill Your Darlings: Avoiding the Trap of Mild Successes

David Leger — Fri, 22 Nov 2019 14:45:55 +0000

In a previous post, I shared my perspective on failure. I emphasized the lasting negative impact failure can have on us. It can be overwhelming and lead to undue stress if not managed well.

However, at the very least failure is explicit. It can come in the form of a poor performance review from a manager. A missed deadline. Another person being angry with us. And notably from these examples, our realization of failure is typically forced upon us through means out of our control.

Although it can be tough to handle, the knowledge of failure gives us permission to move beyond it. It's a bit of a blessing in disguise. Failure is short-term pain, but can also be the spark that triggers radical change which can ultimately propel us to some of our greatest successes. In this post, I want to explore what we should do when the lines aren't so clear cut between failure and success.

Mild success is failure in disguise.

Equally, if not more than failure, we should be wary of mild success. Mild success is failure in disguise. It seeds regret. It's settling for good enough when we are capable of so much more. Mild successes can lead us to spend months, years, or even a lifetime on auto-pilot, instead of seeking new and exciting challenges.

Let's explore a hypothetical scenario.

Perhaps you're at your first job out of university. The job is good! You're satisfied and you get paid decently well, especially compared to when you had no income as a student. About a year into the job, you've learned a lot. Things feel good. It's comfortable and you're relatively happy, maybe a little bit bored but you can deal with that. By all accounts, you're successful, and your parents are proud. You've got some complaints, but they're minor. You know there are other jobs out there that seem like a step up, but nah... your current job is pretty good. What more could you ask for?

This is very likely a mild success.

It might have been a good job to start with, but this is your first job out of university. It's all you've ever known, so you feel somewhat sentimental about the company and your coworkers. It's your one and only darling job.

I think it's important to be proactive in identifying when we've achieved a mild success. Identify it. And kill it.

In order to achieve great success, we must abandon success that is merely mild.

Kill your darlings. This is a common piece of advice given to aspiring authors. It's meant to encourage authors to let go of their most precious passages when they don't support the work as a whole. I think this can be more broadly applied to many parts of our lives beyond writing. In order to achieve great success, we must abandon success that is merely mild. Although they can make us happy, mild successes can cause us to stagnate and settle for what's comfortable, preventing us from pursuing what's desirable.

And yes, that means leaving a job that has become merely comfortable for opportunities that challenge and excite you. In the novel of your life, kill your darlings. Cut out the meandering subplots. No matter how precious, they distract from the overall story you wish to tell.

Beyond the career example I described, I encourage you to apply this concept to all parts of your life. I suspect you'll find at least one darling worth killing.

Happy hunting. 🔪

Job Security in Startup-land

David Leger — Wed, 20 Nov 2019 23:46:01 +0000

When I started my job at Manifold, my parents warned me about taking a potentially unstable job. Leaving a stable job at Cvent to go work for a Series A startup seemed like a big risk.

I've worked at Manifold for almost a year now and in that time many people have asked me if I ever worry about losing my job. My response is always: Yes, but I don't really worry about that. Let me tell you why.

Startup employees have the lowest job security in the tech industry.

For many people, taking a job at a startup is risky. Startups are notorious for having high turnover rates, and more often than not, they go out of business before becoming profitable. Startup employees have the lowest job security in the tech industry. But job security isn't as important as you might think, especially when compared with the experience that comes with working at a startup.

Instead of job security, I like to focus on career security. What's the difference? Job security is how likely you are to keep your current job. Career security is how likely you are to find a new job.

So what has working for a startup done for my career security? At Manifold, we're working on some of the toughest unsolved problems in the cloud software industry. Getting the chance to work on these problems has allowed me to refine and expand my skills far beyond the average frontend developer. I get to work with cutting edge technologies like Web Components and GraphQL on a daily basis. Beyond that, I've been able to explore new skillsets: agile coaching, interviewing, product and design, partnership management, and more.

Working for a startup might be risky in the short-term, but it will lead to far more opportunities in the long-term.

These are all things that I would not have been exposed to this early in my career, or ever, working at a larger, more stable company. Having had these experiences, I'm far more employable than the average frontend developer. Working for a startup might be risky in the short-term, but it will lead to far more opportunities in the long-term.

Maintainable Options Parameters for Functions in JavaScript

David Leger — Tue, 22 May 2018 16:23:58 +0000

My friend/co-worker Sam Jesso told me that he hates using flags to modify the behaviour of functions. It makes sense. Functions should follow the single responsibility principle and do exactly one thing. It makes testing and maintaining code easier because it keeps functions simple and concise. However, diving into almost any codebase will reveal that we often make exceptions and use flags.

Whether or not these exceptions are justified is not what I want to discuss. It would be impossible to come up with a set of rules or guidelines for when an exception makes sense because everybody’s code is different. But if you’ve already decided that you want to pass flags into your function, there is a simple trick you can use to make your functions’ interfaces more developer-friendly.

Rather than treating flags (or options) as separate parameters, we can group them into a single options object:

// Before
function func(inputA, inputB, flagA, flagB, flagC) { /* ... */ }
func('Some input.', 'Some more input.', true, false, true);

// After
function func(inputA, inputB, { flagA, flagB, flagC } = {}) { /* ... */ }
func('Some input.', 'Some more input.', { flagA: true, flagC: true });

Grouping options into a single object has several advantages over using separate parameters. To better understand these advantages, let’s take a look at a less abstract example...

An Example with Formatting Time

Here’s a simple function to get a formatted time string from a Date object:

function formatTime(dateTime) {
  const hours   = leftPad(dateTime.getHours(), 2);
  const minutes = leftPad(dateTime.getMinutes(), 2);
  const seconds = leftPad(dateTime.getSeconds(), 2);

  return `${hours}:${minutes}:${seconds}`;
}

formatTime(new Date());  // 01:23:45

Side note: Yes, I wrote my own version of leftPad because I’m not pulling in simple dependencies for a blog post. (Also if you don’t cringe when you hear talk of leftPad, take a moment to read this.)

function leftPad(number, numberOfChars) {
  let paddedNumber = `${number}`;
  numberOfChars -= paddedNumber.length;
  while (numberOfChars--) paddedNumber = `0${paddedNumber}`;
  return paddedNumber;
}

And yes, I know how error-prone this is but it works for our implementation here.

Anyway, back to the example.

New Requirements

We have a function for formatting time and it does a great job. But now we want to have the option switch between 12-hour and 24-hour time. And we also want to exclude seconds in some cases.

No problem, we can just add some extra parameters to the function:

function formatTime(dateTime, is12Hours, showSeconds = true) {
  const hours   = leftPad(is12Hours ? dateTime.getHours() % 12 : dateTime.getHours(), 2);
  const minutes = leftPad(dateTime.getMinutes(), 2);
  const seconds = showSeconds ? `:${leftPad(dateTime.getSeconds(), 2)}` : '';

  return `${hours}:${minutes}${seconds}`;
}

formatTime(new Date(), true, false);  // 01:23

There are several issues with this approach:

The parameters must be passed in a specific order. If we want to hide seconds, we must still pass a value for is12Hours before we can specify one for showSeconds.
The parameters are unnamed. If the function is being called far away from the definition, it may not be clear what the parameters mean. We must go to the function definition to find out what the various true/false values do.

These issues make the function interface very difficult to read understand and they amplify the potential for human error especially when a function has many options because it’s easy to accidentally skip a parameter or mix up their order.

Refactoring with an options object

A simple way to fix these issues is to refactor the function to use an object for flags/options:

function formatTime(dateTime, { is12Hours, showSeconds = true } = {}) {
  const hours   = leftPad(is12Hours ? dateTime.getHours() % 12 : dateTime.getHours(), 2);
  const minutes = leftPad(dateTime.getMinutes(), 2);
  const seconds = showSeconds ? `:${leftPad(dateTime.getSeconds(), 2)}` : '';

  return `${leftPad(hours)}:${leftPad(minutes, 2)}${seconds}`;
}

const time = formatTime(new Date(), { 
  is12Hours: true, 
  showSeconds: false 
});   // 01:23

This approach solves the issues that exist with passing flags as separate parameters by:

Exposing the flag names to the interface.
Forcing developers to label the flags properly.
Making the ordering of flags irrelevant.
Allowing exclusion of flags when we want the default behaviour.

In addition to making the function more readable we’ve also made it maintainable because it’s now easier to add many flags to our formatTime function without adding more and more nameless booleans, making the function calls unreadable. We could add flags for showMinutes, showMilliseconds, or even an option to specify a custom delimiter to replace the default colon. Whatever flags or options we add, the function will remain relatively readable.

One More Thing...

Even though we’ve made the function’s interface easy to use and add to doesn’t mean that all the functionality for those parameters should be aggregated into a single function. Use your best judgement and decide when to delegate functionality to helper functions.

React Quick Tip: Use Class Properties and Arrow Functions to Avoid Binding `this` to Methods

David Leger — Mon, 29 Jan 2018 15:19:11 +0000

When you want to access this inside a class methods of your React component, you need to bind it to your method:

class Button extends Component {
  constructor(props) {
    super(props);
    this.state = { clicked: false };
    this.handleClick = this.handleClick.bind(this);
  }
  handleClick() {
    this.props.setState({ clicked: true });
  }
  render() {
    return <button onClick={this.handleClick}>Click Me!</button>;
  }
}

Binding this to handleClick in the constructor allows us to use this.setState from Component inside handleClick. Without this binding, this is re-scoped for handleClick and loses context of the component’s setState method.

But this is completely unnecessary, extra code!

You can clean up this ugliness by using some new ES6+ features. Here is the same component, rewritten using class properties and arrow functions to avoid binding this to handleClick:

class Button extends Component {
  state = { clicked: false };
  handleClick = () => this.setState({ clicked: true });
  render() {
    return <button onClick={this.handleClick}>Click Me!</button>;
  }
}

Note: You must have transform-class-properties enabled in your own Babel config in order to use class properties. If you’re using Create React App, this is already enabled for you.

Why Does This Work?

This works because of two reasons:

Arrow functions, by their nature, do not re-scope this, so we don’t need to bind this in the class constructor.
JavaScript has first-class functions, meaning functions are treated the same as data. So arrow functions can be assigned to variables, or in this case, to class properties.

Bonus Tip

Notice in the second example, I defined state as a class property as well, negating the need for a constructor.

Why Code Reviews are Important

David Leger — Mon, 01 May 2017 16:09:33 +0000

Ah code reviews... That dreadful, tedious task that interrupts your focus and takes time away from meaningful work. I can’t count how many times my code has sat in PR (pull request, if you’re unfamiliar with git lingo), lonely and waiting for approval by my fellow developers. It’s understandable that people put off code review for the reasons I mentioned above and many more.

As a junior developer (which I still am), I felt similarly towards code reviews. I didn’t like doing them. I thought, Why am I reviewing code written by senior developers? It’s not like I’m going to catch any of their errors. However what I didn’t understand at the time was that the code review was more for me than it was for them.

This became clear to me while I was reviewing a PR from a senior developer one day. While looking through their code I thought to myself, Wow! This code is really well-written — it’s readable, modular, and well structured...

I was learning React and Redux at the time, and if you know React, you’ll know that everything you do seems a bit weird at first. It’s hard to pick up on best practices on your own (at least I thought so), so being able to see how more experienced developers write components is a great way to learn how to write better code.

Once I was able to see code reviews as a learning opportunity rather than a check on my coworkers’ code, I was able to gain a lot of value from them. I began challenging my own way of writing code with the approaches of my more experienced coworkers and modifying my our approach along the way. I also began asking questions about why something was done a certain way if I didn’t understand it.
This change in mindset around code reviews meant I was able to pick up React and Redux much more quickly than I expected.

Within just a couple weeks I was fully up to speed, completing similar amounts of work as the rest of my team and it was mostly because of the things I learned while reviewing the PRs of my coworkers.

Hi, I'm David Leger

David Leger — Sun, 30 Apr 2017 14:37:33 +0000

I have been coding for 7 years.

You can find me on Twitter (and other platforms) as @davidleger95 or at my website: www.davidleger.me

I live in Fredericton, NB, Canada.

I work for Cvent.

I mostly program in these languages: JavaScipt.

I am currently learning more about making the world a better place through creativity and code.

Nice to meet you.