Forem: Yazeed Bzadough

How to 10x Your Productivity by Creating a Process

Yazeed Bzadough — Wed, 17 Jul 2019 23:55:30 +0000

Originally posted on https://yazeedb.com

Thank You

My last article on killing procrastination did much better than I expected. It was reassuring to see others like myself fighting this uphill battle, and heartwarming to hear that you all enjoyed my humble piece! Thank you ❤️

In an effort to keep the momentum going, let’s talk about creating processes.

I’m Going Somewhere!

You’re scrolling through your phone and YouTube recommends yet another motivational video because it knows how much you love them, How I Tripled my Net Worth or whatever. You listen to soundbites of a dude claiming that deep breathing and not eating vegetables transformed him into a CEO.

Man triples his net worth by eschewing broccoli

Like all the others it’s loud and bold enough to stir a familiar feeling within you, and by the time the video ends, a sudden amp and feverish itch make it clear as day–you’ve been bitten by the Inspiration Bug again.

What happens next? Just the usual...

“I will become a web developer!”

“I will start working out tomorrow!”

“I will get a promotion!”

Your battle cries may vary, but your mileage won’t. You are still going nowhere.

Care to Be More Specific?

What does “I will become a web developer” even mean? How can we track progress on these nebulous phrases that you shout whenever inspiration strikes?

I'm not saying don't have lofty goals. Be inspired. Get energized! But please use that energy to be more specific. Talking feels good, we’ve gone over this, but when you inevitably come back down from that inspirational high, what are your concrete actions going to be?

Don’t just say, “I am going to learn web development” Do you know how gargantuan of a task that is?!

HTML, CSS, JavaScript
Frameworks/Libraries
Testing
Accessibility
Build tools
HTTP
SEO
Animations
REST APIs
Templating engines
State management
Command line
Fatigued yet?

This is the JS ecosystem from 2016...three years ago!

I was suffering from this around 2013, before JavaScript really detonated a few years later. If we’re going by that definition then even with nearly 5 years experience, I still haven’t “learned” web development and I never will.

Every endeavor has a ton of paths, and most of us waste precious time considering all possible paths instead of just committing to one and flourishing.

You're going to end up unmotivated again, because a specific target wasn't set.

Tell Me What You Want

You want to become a web developer, ok great.

What kind? Why?

Do you want a job? What kind of job? Do you want a business? What kind of business? Tell me exactly what you want! Once we identify your target, we can prepare for the hunt.

Here's an example of Batman guiding Joker through it.

Joker: Fine! I flipped a coin and think UIs are cool, let’s focus on Front-End development (for now). I want to become a Front-End web developer.

Batman: Good, where?

Joker: I have kids, so no more than 1 hour from the house. A remote position would be ideal.

Batman: Here’s a job description based on countless Indeed.com postings.

Job description

Strong knowledge of HTML, CSS, JavaScript
Knowledge of modern mobile/responsive design techniques
Git/GitHub
Excellent verbal and written communication
Bonus points for React, Angular, Vue, Node.js

Joker: What’s the fastest way to succeed?

Batman: Turn yourself into this candidate. We’ll work towards that by creating a process.

Creating a Process

This requires you to critically think about the goal. What steps must we take to progress?

How about a project that incorporates the job description we just found? I always recommend beginners to make a clone of todomvc.com. For best results, conform as close to the job description as possible.

Use HTML, CSS, and JavaScript
Make sure the app looks spectacular on all screen sizes
Put it on GitHub
Not everyone will agree here, but I say don't use a framework until you’re somewhat proficient in JavaScript. This means you can comfortably write basic apps without needing a framework and you understand how the pieces connect in a more complex app.
Once you’re more advanced, feel free to redo this in React, Angular, Vue, etc.

Less Shopping, More Googling

The important thing here is to pick a project. Don't buy another course or book until it gets done. You’ll learn everything by Googling the problems you encounter.

After that, pick a different or slightly harder version of the project, rinse and repeat. Do that a few times and you have a portfolio of apps you built from the ground up.

There’s your process–congratulations, you’re now exactly like the candidate in that job description. Maybe even better, depending on the apps you completed.

This Works Everywhere

I’m a huge fan of universal principles, and create a process is one of them.

Whatever you’re doing–programming, speaking, lifting, sports, chess, Chinese, you learn it through following a trusted process. Either pay someone (school, bootcamp, course, mentor) to create that process, or do it yourself.

Bottom line is that process must be created, otherwise you’ll keep getting inspired, making vague declarations of change, and remain the same.

That’s momentum my friends. It’s wrecked me several times, and now I know some of you feel that pain too. It’ll push us right off the cliff unless we slam the brakes and turn the car around.

But just remember next time, before you start going the other direction, use a map.

Until next time!

For more content like this, check out https://yazeedb.com!

Deeply Understand Currying in 7 Minutes

Yazeed Bzadough — Wed, 17 Jul 2019 23:41:20 +0000

Originally posted on yazeedb.com

Eric Elliott’s exceptional Composing Software series is initially what got me excited about functional programming. It's a must-read.

At one point in the series, he mentioned currying. Both computer science and mathematics agree on the definition:

Currying turns multi-argument functions into unary (single argument) functions.

Curried functions take many arguments one at a time. So if you have

greet = (greeting, first, last) => `${greeting}, ${first} ${last}`;

greet('Hello', 'Bruce', 'Wayne'); // Hello, Bruce Wayne

Properly currying greet gives you

curriedGreet = curry(greet);

curriedGreet('Hello')('Bruce')('Wayne'); // Hello, Bruce Wayne

This 3-argument function has been turned into three unary functions. As you supply one parameter, a new function pops out expecting the next one.

Properly?

I say "properly currying" because some curry functions are more flexible in their usage. Currying's great in theory, but invoking a function for each argument gets tiring in JavaScript.

Ramda's curry function lets you invoke curriedGreet like this:

// greet requires 3 params: (greeting, first, last)

// these all return a function looking for (first, last)
curriedGreet('Hello');
curriedGreet('Hello')();
curriedGreet()('Hello')()();

// these all return a function looking for (last)
curriedGreet('Hello')('Bruce');
curriedGreet('Hello', 'Bruce');
curriedGreet('Hello')()('Bruce')();

// these return a greeting, since all 3 params were honored
curriedGreet('Hello')('Bruce')('Wayne');
curriedGreet('Hello', 'Bruce', 'Wayne');
curriedGreet('Hello', 'Bruce')()()('Wayne');

Notice you can choose to give multiple arguments in a single shot. This implementation's more useful while writing code.

And as demonstrated above, you can invoke this function forever without parameters and it’ll always return a function that expects the remaining parameters.

How's This Possible?

Mr. Elliot shared a curry implementation much like Ramda's. Here’s the code, or as he aptly called it, a magic spell:

const curry = (f, arr = []) => (...args) =>
  ((a) => (a.length === f.length ? f(...a) : curry(f, a)))([...arr, ...args]);

Umm… 😐

Yeah, I know... It's incredibly concise, so let's refactor and appreciate it together.

This Version Works the Same

I've also sprinkled debugger statements to examine it in Chrome Developer Tools.

curry = (originalFunction, initialParams = []) => {
  debugger;

  return (...nextParams) => {
    debugger;

    const curriedFunction = (params) => {
      debugger;

      if (params.length === originalFunction.length) {
        return originalFunction(...params);
      }

      return curry(originalFunction, params);
    };

    return curriedFunction([...initialParams, ...nextParams]);
  };
};

Open your Developer Tools and follow along!

Let's Do This!

Paste greet and curry into your console. Then enter curriedGreet = curry(greet) and begin the madness.

Pause on line 2

Inspecting our two params we see originalFunction is greet and initialParams defaulted to an empty array because we didn’t supply it. Move to the next breakpoint and, oh wait… that’s it.

Yep! curry(greet) just returns a new function that expects 3 more parameters. Type curriedGreet in the console to see what I’m talking about.

When you’re done playing with that, let’s get a bit crazier and do
sayHello = curriedGreet('Hello').

Pause on line 4

Before moving on, type originalFunction and initialParams in your console. Notice we can still access those 2 parameters even though we’re in a completely new function? That’s because functions returned from parent functions enjoy their parent’s scope.

Real-life inheritance

After a parent function passes on, they leave their parameters for their kids to use. Kind of like inheritance in the real life sense.

curry was initially given originalFunction and initialParams and then returned a “child” function. Those 2 variables weren’t disposed of yet because maybe that child needs them. If he doesn’t, then that scope gets cleaned up because when no one references you, that’s when you truly die.

Ok, back to line 4…

Inspect nextParams and see that it’s ['Hello']…an array? But I thought we said curriedGreet(‘Hello’) , not curriedGreet(['Hello'])!

Correct: we invoked curriedGreet with 'Hello', but thanks to the rest syntax, we’ve turned 'Hello' into ['Hello'].

Y THO?!

curry is a general function that can be supplied 1, 10, or 10,000,000 parameters, so it needs a way to reference all of them. Using the rest syntax like that captures every single parameter in one array, making curry's job much easier.

Let’s jump to the next debugger statement.

Line 6 now, but hold on.

You may have noticed that line 12 actually ran before the debugger statement on line 6. If not, look closer. Our program defines a function called curriedFunction on line 5, uses it on line 12, and then we hit that debugger statement on line 6. And what’s curriedFunction invoked with?

[...initialParams, ...nextParams];

Yuuuup. Look at params on line 5 and you’ll see ['Hello']. Both initialParams and nextParams were arrays, so we flattened and combined them into a single array using the handy spread operator.

Here’s where the good stuff happens.

Line 7 says “If params and originalFunction are the same length, call greet with our params and we’re done.” Which reminds me…

JavaScript functions have lengths too

This is how curry does its magic! This is how it decides whether or not to ask for more parameters.

In JavaScript, a function’s .length property tells you how many arguments it expects.

greet.length; // 3

iTakeOneParam = (a) => {};
iTakeTwoParams = (a, b) => {};

iTakeOneParam.length; // 1
iTakeTwoParams.length; // 2

If our provided and expected parameters match, we’re good, just hand them off to the original function and finish the job!

That’s baller 🏀

But in our case, the parameters and function length are not the same. We only provided ‘Hello’, so params.length is 1, and originalFunction.length is 3 because greet expects 3 parameters: greeting, first, last.

So what happens next?

Well since that if statement evaluates to false, the code will skip to line 10 and re-invoke our master curry function. It re-receives greet and this time, 'Hello', and begins the madness all over again.

That’s recursion, my friends.

curry is essentially an infinite loop of self-calling, parameter-hungry functions that won’t rest until their guest is full. Hospitality at its finest.

Back at line 2

Same parameters as before, except initialParams is ['Hello'] this time. Skip again to exit the cycle. Type our new variable into the console, sayHello. It’s another function, still expecting more parameters, but we’re getting warmer…

Let’s turn up the heat with sayHelloToJohn = sayHello('John').

We’re inside line 4 again, and nextParams is ['John']. Jump to the next debugger on line 6 and inspect params: it’s ['Hello', 'John']! 🙀

Why, why, why?

Because remember, line 12 says “Hey curriedFunction, he gave me 'Hello' last time and ‘John’ this time. Take them both in this array [...initialParams, ...nextParams].”

Now curriedFunction again compares the length of these params to originalFunction, and since 2 < 3 we move to line 10 and call curry once again! And of course, we pass along greet and our 2 params, ['Hello', 'John']

We’re so close, let’s finish this and get the full greeting back!

sayHelloToJohnDoe = sayHelloToJohn('Doe')

I think we know what happens next.

The Deed Is Done

greet got his parameters, curry stopped looping, and we’ve received our greeting: Hello, John Doe.

Play around with this function some more. Try supplying multiple or no parameters in one shot, get as crazy as you want. See how many times curry has to recurse before returning your expected output.

curriedGreet('Hello', 'John', 'Doe');
curriedGreet('Hello', 'John')('Doe');
curriedGreet()()('Hello')()('John')()()()()('Doe');

Many thanks to Eric Elliott for introducing this to me, and even more thanks to you for appreciating curry with me. Until next time!

For more content like this, check out yazeedb.com!