DEV Community: Keith Brewster

Point-Free Programming

Keith Brewster — Wed, 29 Dec 2021 03:27:55 +0000

This article was originally posted at https://www.switchcasebreak.com/blog/point-free-programming

I like functional programming. I like it just enough to adopt the functions and patterns, but not enough to commit myself to
try and understand whatever infixr :!; data L x = x :! L [x] | Nil deriving (Eq, Functor) does in Haskell (this is not an invitation to you mathematicians, keep scrolling). I think functional programming has a ton of useful applications when working with JavaScript—it's a language that lends itself well to FP paradigms, especially when the more esoteric FP languages (Lisp, Haskell, etc.) have far fewer real-world applications. One of the most interesting and divisive paradigms in FP is point-free style.

At a high-level, tacit (point-free) programming occurs when your function definition doesn't reference any of its arguments. Tacit means "understood or implied without being stated", so we're more concerned about what the function does over the data it's operating on (a "point" refers to a function's parameter input, so point-free implies being free from the terrible burden of naming them). Our goal is to eliminate any unecessary parameters and arguments from our code. If that doesn't make sense yet, that's totally okay. Let's take a very basic example:

const numbers = [1, 2, 3]
const numbersPlusOne = numbers.map((num) => num + 1)

Here we define a numbers array and an inline mapping function that increments each number in that array by one. We can take the logic from that inline function and abstract it into its own function:

const numbers = [1, 2, 3]

// our previous mapping logic
const incrementByOne = (num) => num + 1

const numbersPlusOne = numbers.map((num) => incrementByOne(num))

That's better, now we can reuse this function in the event we have any other pesky numbers needing to be incremented by 1. However, we still haven't achieved point-free style—we still have an explicit reference to num in our inline function (and remember, we're trying not to be concerned about the data we're operating on).

const numbersPlusOne = numbers.map((num) => {
  // we reference our num argument here
  return incrementByOne(num)
})

The callback function provided to .map() is invoked with three arguments: the value of the element, the index of the element, and the array being mapped over. Since we're only concerned about the first element (the value num), we can remove the wrapping declaration and pass our function reference directly in.

+ const numbersPlusOne = numbers.map(incrementByOne)
- const numbersPlusOne = numbers.map((num) => incrementByOne(num))

This works because the signature of our callback function matches the arguments passed from .map() (well, not exactly, but we'll get to that in a bit). We're expecting a single argument in incrementByOne(), the value to increment. On each iteration of .map() we're calling this function and invoking it with the element, index, and array. However, since incrementByOne() has an arity of 1 (meaning it accepts a single argument), it's only concerned with the first argument it receives—in this case, the element being mapped over. That sounds like a lot, but hopefully it will make sense soon. This example demonstrates how both are functionally equivalent:

// our point-free function doesn't reference the callback arguments
const numbersPlusOne = numbers.map(incrementByOne)

// this is functionally equivalent to the first example
const numbersPlusOne = numbers.map(function (element, index, array) {
  return incrementByOne(element, index, array)
})

This works because JavaScript functions are variadic, meaning they technically have an indefinite arity—any number of parameters can be provided to the function irregardless of what's defined in the signature. You can see this happening when you look at a function's arguments object:

function addTwo(a, b) {
  console.log(arguments) // Arguments(3) [1, 2, 3, callee: ƒ, Symbol(Symbol.iterator): ƒ]
  return a + b
}

addTwo(1, 2, 3)

Despite being a binary function (arity = 2), n number of parameters can be provided. This makes JavaScript an incredibly flexible language—we don't need to work with strictly-defined function signatures. This means we can unlock incredibly powerful patterns using rest parameters, allowing our functions to accept an arbitrary number of arguments without needing to do things like creating overloaded methods.

Unfortunately, this same flexibility can create problems when using point-free style. Consider the following example where we create a greet function. It takes a single argument (a name) and returns a string that says "hello [name]". Super useful stuff! We can call the function independently, or use it as the callback when mapping over an array of names:

const greet = (name) => `hello ${name}`

greet('Steve') // hello Steve

const greetings = ['Bill', 'Sally', 'Duane'].map(greet) // ["hello Bill", "hello Sally", "hello Duane"]

This works great, but what if someone comes in and decides that this function should also optionally take in a last name? Sure, they could just pass the first and last name as a single string to our greet function, but then I would need to think of a different example. So I ask that you please ignore how contrived the following code snippet is:

function greet(firstName, lastName = '') {
  return `hello ${firstName} ${lastName}`.trim()
}

greet('Steve') // hello Steve
greet('Steve', 'Smith') // hello Steve Smith

This still works as intended, and all is well with our application! But maybe we should check back on that code mapping over the array of names, just in case.

const greetings = ['Bill', 'Sally', 'Duane'].map(greet)
// ["hello Bill 0", "hello Sally 1", "hello Duane 2"]

Wait, what happened here? We're not passing a last name, so shouldn't it be defaulting to an empty string? Not quite—remember, the .map() callback function is invoked with three arguments: the element, the index, and the array. When our greet function had an arity of 1 (a unary function), we were only concerned with the first argument of the callback function (the value). After we created the scoped variable for our lastName argument, it became initialized by the second argument, the index. Uh oh—changing the arity of our function has now created a bug in our application!

So what can we do? We have to make sure that the function signatures match, i.e. share a common arity. Remember earlier in the article when I said this?

This works because the signature of our callback function matches the arguments
passed from `.map()` (well, not exactly, but we'll get to that in a bit)

Well here we are! We already know that .map() passes 3 arguments to the callback function. This was fine when our function arity was 1 because we only wanted to use the first argument it received. So what if we created a function that would help enforce calling the .map() callback as a unary function? That way it would always only use the first argument, no matter how many parameters are provided. Let's see what that might look like:

const unary = (f) => (arg) => f(arg)
const greetings = ['Bill', 'Sally', 'Duane'].map(unary(greet))

Lets break this down. The first thing is to look at the function signature for our unary function:

const unary = (f) => (arg) => f(arg)

unary is a curried function, which means it's a function that returns another function with arguments partially applied. While it's out of scope for this article (and deserves an entire post to itself), it's a technique for converting a function that takes multiple arguments into a series of functions that each takes a single argument. We now have something like this:

const unaryGreet = unary(greet)
console.log(unaryGreet) // (arg) => f(arg)

At first, this might not seem like it's doing much, but we've actually done something magical. We've partially applied our unary function and created a new function, unaryGreet. Let's take a look at the signature: (arg) => f(arg). It expects a single argument arg, and returns the result of calling f with it. That might be a little bit confusing, so let's look at what our unaryGreet function looks like (I've taken the liberty of filling in the inner function and naming the arguments to make it a little clearer):

function unaryGreet(name) {
  greet(name)
}

That's a lot simpler to comprehend: unary wraps our greet function with another function that only accepts a single argument. Lets take a look at how this works with our previous example:

const unaryGreet = unary(greet)

const greetings = ['Bill', 'Sally', 'Duane'].map(function (element, index, array) {
  // unaryGreet is called with three arguments
  unaryGreet(element, index, array)
})

// we are receiving the three arguments (element, index, array)
function unaryGreet(name) {
  // we pass through only the first argument to our greet function
  greet(name)
}

// greet now only receives a single argument meaning
// we are no longer mapping lastName to the array index
function greet(firstName, lastName = '') {
  return `hello ${firstName} ${lastName}`.trim()
}

And it's not just unary, we can create functions for enforcing an arity of any size. Two arguments, three arguments, even ten arguments (but probably not ten arguments). You can also see how currying helps us create point-free functions.

Some people find tacit programming to be unnecessarily obscure, or that it creates a needless obfuscation. A lot of programming is about figuring out the right level of abstraction—in the right circumstances, I believe that point-free style creates highly reasonable, declarative code. Adopting functional programming paradigms can give you a new set of mental models for structuring your applications, and like any tool, it's up to you to decide when it's the right time to use it.

How Did I Do On My 2019 Resolutions?

Keith Brewster — Tue, 31 Dec 2019 20:05:10 +0000

As 2019 winds down and we can finally rest (and oh lord, do we ever need some rest), I wanted to take a moment to reflect on my developer journey over the past year. My very first post on DEV was about my "2019 Developer Resolutions", and it's time to be haunted by the Ghost of Accountability Past, as I rank the progress that I made towards each goal. Did I complete them, or was mine the fate of the newbie gym-goer on February 1st? Keep reading to find out!

My 2019 Resolutions as a Developer

Keith Brewster ・ Dec 31 '18 ・ 4 min read

#humor #discuss #webdev #writing

#1 Start Writing

Writing is something I've always loved to do, and I managed to keep somewhat consistent with it this year. I'm a big fan of doing a deep dive into a topic—spending a great deal of time researching and meticulously tweaking my content to present the subject matter in a hopefully entertaining and also hopefully digestible way—but I've also discovered that I need some time to decompress between these kinds of articles. Moving forward, I think a mix of content (deep dives, tutorials, discussions) would help me keep more consistent with my publishing schedule.

Final Grade: 7 drafts to never see the light of day out of a possible 17 articles

Writing, but with the relics of a simpler time

#2 Start a Blog

I started working on this one early in the year, but I quickly discovered that I loved the community here on DEV, and wanted to keep my content within its ecosystem (this is just code for me being too lazy to have two places to post content). I know there are tools to hook up your DEV posts as a data source through static site generators to quickly bootstrap out a blog but man, I am lazy.

Final Grade: 0 blogs, 1 big lazy boi

#3 - Read Books

Before anyone says anything, audiobooks aren't cheating; it's just reading with your ears. That being said, I managed to get through a few books through my Audible subscription over the past year. None of them were from the list I linked in my 2018 resolutions article, but I did listen to a 49-hour audiobook of Stephen King's The Stand, which required a sense of resolve that I didn't believe I was capable of. Either way, I'm calling this resolution completed, and there's absolutely nothing you can do about it.

Final Grade: $15/month for an Audible subscription is a bit steep, no?

#4 More Side Projects

While I didn't have any completed development side projects (here's looking at you, 45 highly unfinished private repositories on GitHub), I did start a podcast with my best pal and lifetime co-worker Phil (we've now worked at three different companies together, I'm beginning to think we're a packaged deal). After putting together my recording setup, realizing it's not ideal and upgrading a bunch of it, drawing the podcast cover, figuring out hosting, building a website, recording, editing, publishing and finally promoting the episodes, I really started to miss the simplicity of writing a todo app. So let's make a compromise and call this one completed.

The hardest part about being in tech is the feeling you need to start a podcast for validation

Final Grade: 433 podcast streams since November 1st

#5 Contribute to Open Source

Thanks to Hacktoberfest, I was drawn into completing this resolution with the allure of a free t-shirt (and there's not much I wouldn't do for a free t-shirt). Free merch aside, I'm appreciative for community events like this, because it was the motivation I needed to take that first step. The most important part is that I can finally put "contributing to open source" on my resume without it being an outright lie.

Final Grade: 4/4 pull requests during Hacktoberfest

#6 More GraphQL

My current team is doing a big push to transition from a RESTful API to a GraphQL API, so luckily this was achieved by default. That being said, I did work extensively with GraphQL within my side projects. Every time I needed to build a simple API, I would overcomplicate things by slapping a GraphQL layer in front of it. Overkill? Maybe. Resolution accomplished? Definitely.

Final Grade:

{
  me {
    graphql {
      progress
    }
  }
}

{
  "data": {
    "me": {
      "graphql": {
        "progress": "not bad"  
      }
    }
  }
}

#7 Get Married

Imagine how depressing it would be if I didn't accomplish this one?

Final Grade: 1 big expensive party, 0 divorces

#8 Start a YouTube Channel

Okay, so right now it's just uploaded episodes of the podcast, but I'm hoping to start adding different kinds of content soon. I'm counting this one as completed (if only for the amount of work I've put into the thumbnails). I hope you're all looking forward to what I consider "entertainment" in 2020!

Final Grade: 6/6 clickbait titles, 0 actual videos

#9 - Teach

Luckily, I left this one very open ended in my original post. I had the opportunity to do a couple of talks at meetups this year (Getting Creative with React Native, Putting the Fun in Functional Programming—I write my talks around the names I come up with). I'm sure one or two people in the room must have learned something, so resolution accomplished. I've also found a newfound love for speaking, and I'd love to do more of it in 2020. I've thought about submitting CFPs, but unfortunately traveling isn't a financially viable option for me right now, and there's not a lot of conferences that happen around where I live. But who knows what surprises await us in 2020? (if you do know, please tell me—I hate surprises).

Final Grade: 45 minutes of actual talking, 5+ hours into making my slides

#10 - Reach 1k Followers on Twitter

I'm not quite there, but December isn't over yet.

Final Grade: 330/1000 followers

I hope you've enjoyed reflecting with me about the past year. There's been a ton of ups, downs, 360 kickflips and at least one instance of an uncontrollable death spiral into a seemingly endless void. Overall I'm happy with the progress I've made, and hopefully, 2020 brings everyone their most successful year yet. How did you do on your 2019 resolutions? Is there anything you want to accomplish in 2020? Let me know!

How To Start A Podcast

Keith Brewster — Tue, 12 Nov 2019 04:13:08 +0000

There comes a time in everyone's life where they're faced with the crucial decision: "should I start a podcast?" For me, that day was back in 2012. "2012?" you ask. "But Keith, what's the point of this article if that dream died seven years ago?" Keen observation—this certainly wouldn't be much of a valuable article if that were the case—so let me give you a little bit of backstory.

The Backstory

I had been creating webcomics for a game review website, as well as participating in their monthly podcast (in fact, this is where I was first introduced to what a podcast even was). When the site eventually went belly-up, I decided I wanted to try it on my own. I recorded a big, fat ZERO episodes, and I figured that was the end of my podcasting journey.

Fast forward to 2019. My friend Phil and I keep finding ourselves working together (we're currently on job #3). We've built up a great friendship and strong rapport over the past five years, and we've decided to take our relationship to the next level and start making content together (starting with a weekly podcast).

Now that this is officially a thing, I'd like to share some of my experiences. It was a bit of a rough start, but we've finally started to build some momentum. Here's my list of the most important things to consider before starting a podcast. (Side note: if you'd like to read a little more about our podcast, Phil wrote an article covering who we are and what we're doing).

Friday Night Deploys Podcast with the DevPlebs!

Phil Tietjen ・ Nov 5 '19 ・ 2 min read

#webdev #podcast #beginners

Have A Structure

Unless you're able to give a masterclass in improv, trying to record a podcast without a structure is going to be a terrible affair. That's not to say you can't have organic, authentic conversations. There's many different styles of podcasts, from fully-scripted, down to just having conversations with friends. When I say "have a structure", I mean understand what the flow of your podcast from beginning to end. If you don't, you can find yourself talking in circles.

Phil and I recorded four separate attempts before our eventual "true" episode 1. We first tried recording on the train during our morning commute (it was our first gimmick, it didn't work out so well). After that, we recorded a couple of episodes where we tried to talk about development news, but it felt forced and unnatural (we were also recording a week in advance—I'm not sure if you've noticed, but news moves quick in web development). Finally we settled on a personality-driven, web development-focused podcast, and it just clicked for us. That's how we finally knew we'd found where we needed to be.

One thing I'd definitely recommend is a strong intro. It's the first impression you'll make on your audience, and it's a great opportunity to deliver a taste of your personality and stand out from the others.

Have A Niche

If you jump on the microphone every week and talk about whatever comes into your head, you're going to have a difficult time targeting an audience. I'm not saying it can't work, but unless you already have a dedicated following who will tune into your new venture, it will be incredibly difficult to get people to jump into something with no context.

You don't necessarily have to pigeonhole yourself either. You can go as broad or as narrow as you'd like. But the more focused your niche, the easier it will be to target an audience around it. However, it comes at the cost of losing a potentially larger reach. Figure out where you're comfortable sitting, and start from there. You can always pivot into other content down the road.

Have The Equipment

Okay, I know not everyone has the means for this, and I would never want to gatekeep someone from pursuing something they're interested in doing. But if you want to take podcasting seriously, you're going to want to invest in somewhat decent equipment. You could be producing top tier content, but if your microphone sounds like weapon-grade static, your audience is going to drop out.

You can help kill background noise with tools like Audacity, but there's only a limited amount of polish you can put on rough edges. There's no way to fix a bad recording. An up front investment in a decent cardioid microphone (and a pop filter) will go a long, long way. It would be really disappointing to lose your message behind poor audio.

Learn To Edit

Editing can be a painstaking process. I generally spend 3-4 hours editing a one hour episode of a podcast (I don't really have a frame of reference for whether or not this is a long or short editing process). Besides cleaning up content, this also involves tidying up the audio. This is usually fixing EQ, balancing dynamic ranges with compression, bringing up the audio volume, and some other assorted tweaks to build a fleshed out, layered audio track.

The more you do this step, the quicker the process becomes, but taking the time to deliver the best quality you can will reflect positively with your audience.

Have Fun

The reason why podcasting didn't happen for me in 2012 was because it just wasn't fun. I really enjoyed doing the group podcast with the other content creators on our site, but when I tried to sit down and do it myself, it felt too awkward and unnatural. Having Phil to do this podcast with brings out the best parts of that experience for me, and it's been a blast to do this together.

If it ever became tedious, I wouldn't try to force it just for the sake of making content. But right now I hope we are delivering something that's fun and valuable for people, and it's something I really enjoy doing. So this might actually be the most important point: always make sure you're having fun. It's going to be reflected in your end product.

Conclusion

Podcasting can be a great creative outlet, a tool to teach, or just something fun to do with your friends. One of the most exciting parts is there's no limit to what you can do with it. It took Phil and I a little bit of momentum to get going, but I think we've finally hit our groove now. Find the right structure that works for you, and get to recording! If you'd like to check out our podcast, it's available on all major podcasting platforms.

devplebs.

@devplebs

I'm happy to announce our podcast "Friday Night Deploys" is out now! Available all over the place. It's about jobs & no promises but if you listen you might get a huge bonus at work.

Spotify: spoti.fi/34zdIzN
Apple: apple.co/33beVNi
Google: bit.ly/2oO0Vdk

14:42 PM - 05 Nov 2019

0 2

Thanks for reading! Until next time,
Keith Brewster

Hacktoberfest: My Journey Into Open Source

Keith Brewster — Tue, 15 Oct 2019 01:11:43 +0000

I've been developing professionally for a little over five years. I've grown from a junior developer blasting through hacky front-end solutions with jQuery, to a senior developer making entire project architecture decisions. I've gone from being too nervous to raise my voice about something in the fear of being called out for not knowing what I'm doing, to writing articles on development & talking at meetups. Over the past five years I've gone through a ton of personal and professional growth, but in all that time I've never found an accessible entry point for contributing to OSS. It was something that I knew I wanted to do, but it always felt like there was a huge barrier to entry. I never knew where to start—trying to find a project to contribute to was an overwhelming experience, and when I finally happened to stumble across some potential issues, I wasn't sure of the proper processes to follow (some projects have well-defined contribution guides, but a lot don't).

Then an opportunity presented itself. I heard some buzz about an event called Hacktoberfest; an initiative encouraging developers to contribute to OSS in an effort to make it more accessible and inclusive. This seemed like the perfect stepping stone to making my first OSS contribution. The idea is simple: open up four pull requests on public repos in the month of October, and win a free t-shirt. A number of OSS projects seemed to be participating⁠—marking issues with a Hacktoberfest tag⁠—luring in sharp and hungry developers. And with the looming incentive of a free t-shirt if I was one of the first 50,000 people who completed the event, I was imbued with a fiery passion. There's very few things I wouldn't do for a free t-shirt, after all.

I ended up wrapping up my four pull requests last week, and I wanted to reflect on the good parts and bad parts of my experience.

The GOOD

Hacktoberfest is an incredible opportunity, both for people who are looking to begin contributing, and for newer developers for building up their skillsets. A contribution to an OSS project could mean a huge confidence boost for a new developer—and who knows—maybe help them in landing them their first job (I know when I'm browsing resumes, OSS contributions are always one of the first things to jump out at me). A lot of these projects emulate the kind of structure common in a lot of workplaces (if I had been involved in OSS before my professional work, I'd have been a lot more comfortable with managing project source control in a team environment).

It's also an incredibly positive event. I've seen nothing but words of encouragement for people completing the challenge on Twitter, and it's amazing to see newer developers excited to have their very first pull requests accepted. From what I've seen, a lot of projects have been very accommodating in guiding people through their commits. In a field that can often see a lot of ego, as well as people arguing over different tools & methodologies, it's nice to see an event bring people together in such a supportive way.

Also, free t-shirts. The world needs more free t-shirts.

The BAD

While there's a few resources seeking to rectify this issue, the fact remains that GitHub has a terrible ecosystem for searching out projects looking for contributors. Luckily Hacktoberfest provides some help by listing out a few places to start, but filtering out projects you're interested in contributing to is still an arduous task. Maybe it's because I was being a bit picky; since I've been a developer for five years, I didn't want to snag up anything that would have been better suited for newer developers. This made my search even more difficult—especially because it still needed to be manageable between my full-time job, and being completed within the one month deadline.

The next thing I noticed is that Hacktoberfest is incredibly popular. It can be a frustrating experience to try and find issues that haven't already been claimed within fifteen minutes of them being opened. This is a bit of a double-edged sword: it's good to see so many people are getting involved, but claiming an issue can be a little chaotic (especially in projects that don't have any sort of system in place for assigning issues to developers). I ended up opening my pull requests on Mattermost, as they opened up a huge number of issues for Hacktoberfest (it's also a really cool project that I've used at a workplace in the past).

Conclusion

Will I continue to contribute to OSS? I definitely plan to. I have a lot going on right now between work and starting a podcast, so it's a matter of managing the little time I have. However, OSS drives a lot of the modern web, and seeing as we leverage so much of it in our day to day lives, I believe it's important to give back to the community (if we have the capacity to do so). I have a great respect for open source maintainers, because it's a lot of work to review pull requests, manage issues, plan features, track changes—all of this while trying to actually get the work completed. Hacktoberfest was an amazing opportunity, and it knocked down the walls I had put up around myself for diving into OSS.

Are you taking part in Hacktoberfest? Have you completed your four pull requests? Let me know what you've been working on!

What I Look for During an Interview

Keith Brewster — Mon, 30 Sep 2019 23:45:46 +0000

I've had to interview a number of developers throughout my last couple of jobs, and I've been slowly refining a list of common traits I've found that successful candidates have all shared. I wanted to talk about what I've found to be the largest indicators of a top candidate, and also some of the red flags. I find that most posts about interviews are from a candidates perspective—how to prepare for an interview, common interview questions—but I wanted to highlight some of the non-technical traits I'm looking out for. I should also preface this article by saying I'm not representative of all interviewers; everyone is going to have their own styles of interviewing, and what's appealing to me doesn't necessarily mean it's important to other employers. I'm just providing my perspective on what I've found to be the most important qualities. Alright, now that the preamble is out of the way, let's jump into it!

Trait 1: Attitude

I think attitude is one of (if not the most) important traits of a candidate. Especially in my current workplace that practices pair programming—I want a candidate that I could see myself working with for 8 hours at a time. We do code/PR reviews, so a successful candidate needs to be open to feedback and collaborating on problems with other team members. Now, not every workplace practices pair programming, but I feel this characteristic is still applicable across almost any circumstance. You don't want someone who's going to stir up a ton of conflict amongst the team.

In my experience, the more ego that's in a workplace, the more toxic the culture becomes. I believe the most positive environment is one that values inclusivity and mentorship. You could be an excellent developer, but if you're not willing to share that knowledge with your team to help build everyone up, then a lot of that value is immediately lost. We're all constituents of the same goal, so if we're putting up barriers between developers, we'll never be able to work as a cohesive unit. People often conflate high skill with success, but a focused team will always outperform an individual.

Trait 2: Passion

This one is tricky for me. I think a positive work/life balance is incredibly important to maintain, and I know not everyone has the time to pursue a bunch of side-projects. That being said, having a body of work or an online presence (whether it be contributions to OSS or involvement in a development community) makes it a lot easier to understand the capabilities & skillset of the candidate. Also, self-learning is incredibly important—especially in web development where things move so rapidly—so having an idea of where a candidate goes to keep up to date on emerging technologies is a huge benefit.

I don't need a candidate to have hundreds of green squares on their GitHub contribution chart. If they've made the effort to participate in development outside of work experience, it helps me understand the kind of developer they are before the interview. This assists me in refining the questions that I prepare, which usually results in a better interview. So yes, when you include links to your socials on your resume, interviewers absolutely check them out. I understand this may be a touchy area, but again, it's not a dealbreaker for me. I don't need you to eat, sleep, and breathe code.

Trait 3: Communication

I'm not a fan of whiteboard interviews. I feel like it's not a good representation of a candidates ability to solve the types of challenges we deal with on a daily basis. I'm not saying that there's no value in these types of interviews—it's just not my style. I prefer learning about a candidate through asking questions about the projects they've worked on.

Keeping questions open-ended and having a candidate talk about their technical background has (in my experience) been a better indicator of a candidates ability, moreso than whether they can throw together a function that takes in two binary trees as arguments, and return whether or not they're perfect mirrors of each other. I'm much more interested in whether they can communicate technical concepts to me vs if they've memorized the common interview algorithms. You can tell a lot about someone's work ethic just by listening to how they talk about development.

I've met brilliant developers with terrible work ethic, which is kind of like mixing 16 year scotch with Coke Zero. There's certainly a lot of potential but it's been lost underneath a layer of disappointment, and if you drink too much you'll end up with a massive headache.

Trait 4: Honesty

If I'm asking you technical questions and something comes up that you're not familiar with, I don't want you to try and lie or talk your way around it. Be honest and tell me that it's not a concept that you're familiar with, and we can work it through it together. If a candidate seems genuinely interested in understanding a concept, then it demonstrates that they have a curiosity and willingness to learn. I never expect a candidate to fully understand every facet of the tools we work with, but if they're able to show they're strong, capable learners, then I'm less concerned about practical experience (this, of course, has limitations. I need the candidate to at least be familiar with the stack we work with).

I've had interviews where a candidate was clearly unfamiliar with a topic, but tried to talk their way around it. I understand the pressure of an interview scenario, and admitting you don't understand something might seem like a sign of weakness and hurt your chances at the position. But I can tell you that getting caught in a lie is 10 times worse than being not knowing something. This is an immediate red flag for me. It's also an indicator that a candidate might have trouble keeping open communication in a workplace setting when they're running into blocks, or struggling with a task. Don't do it!

These are just the things that I've noticed in my experiences thus far. Maybe they're obvious, but I'm still learning something new with every interview and constantly refining my practice. If you're in the position where you're performing interviews, I think it's important to take a moment of introspection after each one to review your process. Remember, this is going to be the candidate's first impression of the company, so it's important to maintain a balance of being able to assess a candidate's technical ability while still providing an authentic representation of the company's values.

Here's an interview tip: never project yourself onto the candidate. I've met too many people whose expectations for a candidate come from looking in a mirror. Don't expect the people you're interviewing to share your experience or exact skillset. A diverse workforce is a strong workforce.

I hope this provides some clarity on what we're observing from the other side of the table. Other interviewers, what are some of the traits of a candidate that are the most important to you? Let me know!

Thanks for reading, and feel free to say hi on Twitter!

Does Your Workplace Encourage Open Source?

Keith Brewster — Mon, 16 Sep 2019 14:43:02 +0000

I recently attended a conference where Jason Lengstorf gave a talk called "You Belong Here: How to Make Open Source More Open". Over the course of the talk he labelled the ways the Gatsby team had encouraged OSS, and how to make it more accessible and inclusive to a greater audience of people. I was curious how many people are working for companies/teams that have this same attitude.

Does your workplace encourage you to contribute to open source? If they do, do they give you time during work hours for working on open source projects? Do they have any open source initiatives of their own?

The Upside of Downtime

Keith Brewster — Mon, 09 Sep 2019 02:19:43 +0000

I know you've heard it a thousand times before. But it's true - hard work pays off. If you want to be good, you have to practice, practice, practice. If you don't love something, then don't do it. - Ray Bradbury

There's this prevailing line of thought that you can achieve anything if you work hard enough. It's the foundation of the American Dream🇺🇸 (or at least the best that I can understand it as a maple syrup-chugging Canuck). And I believe (for the most part) it's true; hard work and perseverance does pay off. I'm a cookie cutter example of this—I was homeless for two years in my early twenties, and I've worked my way up to become a software engineer. But I'm not here to debate the ethos of the American Dream🇺🇸, I'm here to talk about the side effects of continual hard work. These side effects manifest themselves in a number of different ways; if you're not careful it could negatively impact you, your relationships, and your mental health.

I think this mindset is nowhere more evident than in the field of software development. You have recruiters and job postings searching for "rock star programmers". You hear stories of companies who purposely keep deadlines short; expecting their developers to work long hours to get the work completed. It can be intimidating for new developers to see these high expectations being set—we've all joked about the entry-level developer role that requires 3+ years experience—but this can feel overwhelming to someone on their first job hunt. And it's not just jobs that can drive these expectations of hard work, but programmers themselves as well. Our field is constantly changing, there's tons of skills to develop and improve on. I think most people get into programming because they love to solve problems, and with a constantly growing selection of tools and resources to solve these problems with—the learning never ends.

Sometimes it's difficult for me to know when to turn off. If I wasn't using my free time to work on side projects, read articles, or do research for blog posts, I'd feel a tremendous amount of guilt. I was spending less time with my wife and dogs in order to watch tutorial videos on new technologies I wanted to learn. The time I'd usually spend with my hobbies turned into hours of reading articles I had bookmarked throughout the day. And this worked—for a while. But over the past few weeks, I've been carrying an exhaustion that no amount of sleep nor exercise could make a dent in. I've been irritable, moody, and finding myself too worn out by the time I got home from work to be productive.

So this weekend, I decided to turn off. No Twitter, no side projects, no courses. Instead my wife and I watched movies, spent time relaxing, and had friends over for wine and board games. Now, there were times I wanted to pick up my laptop and jump into some work—and more than once I had to close Twitter after instinctively opening it to check my notifications—but for the most part I was completely disconnected. And something funny happened: that feeling of exhaustion slipped away. I wasn't irritable, I felt relaxed. I had a clear head for the first time in what felt like months. As a result, it bolstered the relationships I had been ignoring. I can now go into the work week with a fresh mind and a good attitude.

If I can leave you with any piece of advice, it's that we need to start collectively putting a larger focus on work–life balance. It's important to work hard, to push yourself and learn new things. But you also need to know when to shut off. Make time for your friends and family. Pick up your hobby (or whatever you love to do). Understand your limits and be careful not to push them. In exercise, there's something known as overtraining syndrome. It's when you push your body too much without adequate periods of rest. Not only will it affect your health, but it also counteracts any progress you'd see as a result from working out. I think this same idea exists with development. If you try and push yourself too much, it will negatively impact your ability to absorb the concepts you're trying to learn. Make time for yourself to rest, and stay healthy.

Until next time,
Keith Brewster

You Will Fail (And That's Okay)

Keith Brewster — Fri, 30 Aug 2019 01:19:52 +0000

"I get knocked down, but I get up again, you're never going to keep me down" - Ancient Proverb

Note: I wrote this at the beginning of the year, but I wanted to make some updates based on some new perspectives.

It was December 2018. I was looking for a new job opportunity, and I managed to arrange an interview with a market research company based out of Toronto. By the title of this article you can probably infer that it probably could have gone better. As I walked out of their office into the cold, Canadian winter, I felt an overwhelming sense of defeat. And not the regular sense of defeat most Canadians generally feel when winter starts. It was a myriad of different emotions: anger, disappointment, confusion, disappointment—just a bunch of disappointment, really.

Think I'm joking about feeling defeated during Canadian winters? This picture was literally taken outside of my college.

Over the past couple years, I've become a lot more confident in my skills—when I apply for a position, I actually feel like I'm a good fit. I've moved into senior developer roles; I've had responsibilities in mentoring junior devs and interviewing new hires. I've shed off a little bit of that imposter syndrome; things have been pretty good—except all of that went out of the window during this interview. Maybe it was the entire Margherita pizza I ate only an hour beforehand, or maybe I just cracked under the pressure (it was probably the pizza though).

Pictured above: the culprit

The position seemed like a perfect fit. I had been working professionally with the stack they were using for around four years, and I have a post-grad certificate in Big Data Analytics—this was definitely a bonus for a market research company. A friend of mine was working as a highly-respected developer with this company, and had recommended me for the position. Things really couldn't have been much more in my favour. I was critical darling "The Shawshank Redemption", and the Oscar for Best Picture was mine to lose.

The Shawshank movie poster on Wikipedia had an attribution clause I was too lazy to read, so I found this terrible stock photo to illustrate my point instead.

Except Shawshank Redemption didn't win Best Picture. And I wouldn't, either (in case you're curious, Forrest Gump beat both Shawshank AND Pulp Fiction for Best Picture that year. Also, am I nailing this analogy?). Here's the thing: even though I had a ton of advantages coming into this, the simple fact is—I just had a bad interview. It's not that I wasn't prepared, or that it was anything outside of my capabilities. I just ran into a snag mid-interview, I panicked—cooler heads did not prevail—and by the time I figured out what the issue was, it was too late. I swallowed my pride and walked my interviewer through what I would have done to finish the challenge.

How I felt, but in cat form.

I never got a call back; I was devastated. I took it out on myself. But here's the thing; just because you have a bad interview doesn't mean you're any less of a developer (even though it can feel that way). After blowing the interview I felt awful—all of the old feelings of inadequacy started to flood in. I thought back to my first year at college, struggling to keep up as my peers seemed to grasp the concepts that just wouldn't click for me. Though it's natural to feel bummed out, it's important to not let your mistakes define you. When I was struggling in college I worked harder until I could excel past my peers. When I blew the interview I worked harder, and two months later I landed a fantastic opportunity where my career has grown to monumental heights. Every struggle turned into another opportunity to improve.

I wanted to be open about this experience because I feel like it's important for people to talk about the less glamorous moments (especially on social media when we're constantly surrounded by brilliant people doing amazing things). I think we've all been through the process: the countless resumes shipped, the seemingly-endless applications filled out. Months without hearing back on any prospects. The technical recruiters who claim they're excited to work with you, only to ghost you like a bad Tinder date. The feeling that maybe you're just not cut out for this. It can be hard to stay motivated through it all. I faced it when I was starting out my career, and I'm still dealing with it now.

Here's the thing: you will fail, and that's okay. Because once you find success, it will taste so much sweeter. There's already far too many failure-related proverbs, so I'll spare you the yearbook quotes. So I blew an opportunity—I'm not going to quit just because I had one bad interview. It will take at least three bad interviews to stop me.

Thanks for reading, and I hope you enjoyed my story. I'm doing better now but feel free to send me hug emojis on Twitter.

What the Heck is a Microservice Architecture, Anyways?

Keith Brewster — Mon, 26 Aug 2019 02:02:35 +0000

You're the Red Ranger, karate all-star and leader of the Mighty Morphing Power Rangers. You're sitting in the head of the Megazord; the alien-busting, sword-swinging robot formed by the individual Zords of each of the other Rangers. In the Megazord you're invincible—nothing Rita Repulsa sends at you is any match for your tremendous power. You stare at today's "monster-of-the-week"; a large alien covered in eyeballs with tentacles for arms. Your face twists into a coy smirk; this should be over with a single swing of your skyscraper-sized sword. "Alright Rangers," you yell out, "let's get him!"

It doesn't get much better than this.

"Uhh, there might be a problem?" Kimberly, the Pink Ranger says nervously.

"What's that?"

"Billy has mono, so he couldn't make it."

You stare down, realizing the left leg of the Megazord is missing. Almost if coming to the same realization, the Megazord starts to teeter uncontrollably. With a loud crash, you slam into the ground. The world moves in slow motion as you're tossed into the wall of the cockpit. As you slowly pull yourself out of a daze, you look up to see the monster quickly approaching.

"Pick us up!" you yell at Zack, the Black Ranger, who controls the arms of the Megazord.

"More bad news," he replies, "but QA is still doing regression tests on the bug we found in my Zord last week. It wasn't ready for release today."

Probably how you're feeling, right now.

Ignoring the fact that the Megazord is obviously more powerful than the individual components that make it up (because it would be less of a spectacle if a super cool giant robot ended up splitting into objectively less cool smaller robots), I wanted to try and introduce to you the idea of microservices, and why they've become a popular architectural pattern over the past few years. It's not a perfect analogy—really I just wanted the opportunity to make a Power Rangers reference.

If you've looked at job postings for software developers within the past couple of years, there's a really good chance you've seen the line "familiar with microservice architecture". You may not know exactly what it is, but there's certain things you can almost immediately infer: it involves small services, and it's a pattern of architecting something. You think to yourself, "well, I put Ruby on Rails on my resume, and all I did with that was write a Hello World app—I'm sure I can get away with the passing knowledge of microservices achieved by reading an article on the internet." I'm not going to make any promises, but hopefully by the end of my article you can look that interviewer in the face and say, "yeah, I AM familiar with microservice architecture!" before bellowing a guttural howl, tearing the sleeves off your interview top, and flipping the desk of the interview station in a single, explosive toss.

If you read my article about declarative programming, you may have seen me mention that declarative programming had an antithesis. Microservices also have an antithesis, known as Monolithic Architecture. This is just a way to describe a system built as a single logical unit. In simpler terms, this just means a single codebase that contains functionally different layers (for example: server-side application, presentation layer, database layer, etc). Historically, this is how enterprises have been building applications. There are, however, some downfalls to having all of your application code live in one spot. As a codebase grows through the never-ending cycle of operational churn, so does the ability to maintain it. You'll start to incur technical debt. New features become more difficult to implement. Bugs become harder to find. Developers will begin to stage revolts against upper-management. The Czar will be overthrown in a violent protest.

Too soon?

The microservice architecture pattern grew out of the need to mitigate the difficulties of maintaining an enterprise application as it scales in size. Patterns popped up over the years to help with this—for example—domain-driven design helps to manage side effects that might occur when functionality becomes too tightly coupled to different areas of your application. Over time, however, it becomes difficult to continue maintaining this structure—this is where microservices come in. Microservices seek to strip common functionality out of a codebase and abstract it into its own service. Because this service runs independently, it can now focus solely on a specific business boundary.

I'm going to try and break down a microservice into its individual characteristics (kind of like breaking an application into microservices—that's your first example, ha ha).

They're Small

"Alright Captain Obvious," you speak aloud to the screen you're reading this article on. Yes, I understand that this was probably implied from the name, but what might not be as obvious is how small they should be. The answer isn't as simple, unfortunately: it depends. What if you break a service up into too many microservices? What if you end up with one bloated microservice handling too much functionality?

Here's a good rule of thumb: decide the business boundaries of the service, and start from there. Here's an example, say you have an app where users can create profiles and write articles (boy, this sounds familiar). You've created a function to handle uploading photos. This photo needs to be transformed & uploaded to an AWS S3 bucket, and then metadata needs to be saved to a database. This has a pretty clearly defined business boundary (photo upload management), which seems like a good candidate for being stripped out and becoming a microservice.

You might hear talk online about the "two pizza" rule (popularized by Amazon), which means the microservice should be small enough that the team working on it can be fed with two pizzas. One time in college I ate an entire extra large pizza in one sitting, so I'm not too confident with this metric. I also think there's no exact formula, and while this exercise might work well for a large enterprise, the value of microservices is much more universal than that. This should be determined by whatever best suits your personal and/or organizational needs.

Not the exact pizza I ate, just a dramatization.

Single Responsibility Principle

You may be familiar with this term (it's the "S" in SOLID). If you're not familiar, let me explain. It's the idea of grouping things that change for the same reason. Now that I've given an incredibly vague answer, let's go into it a bit deeper.

SRP maintains that a class should only change for a single reason. If there's two reasons that it might change, it should be divided into two classes. This might sound a little overkill, but as your application grows in complexity, it's important to maintain resiliency in your code. When you have a class that has multiple reasons to change, it's hard to predict side effects. One change will unintentionally influence how other responsibilities are implemented by the same class. Everything becomes tightly coupled to each other; if something needs to change, it could potentially break other functionality in the class.

Microservices borrow this same principle, in that each service should only manage a single responsibility. Each service has its own task, but can communicate with other services to solve larger, more complicated business problems. Teamwork makes the dream work, after all.

If your microservice looks like this, you're doing it wrong.

Communication

In a microservice architecture, each service should encapsulate their own domain knowledge, and the implementation details of each service are hidden from the others (another throwback to my article on declarative programming). This means that in communicating with our photo uploading microservice, the client doesn't need to know anything about how it's actually processing the images. It just cares about handing off an image to be processed. With microservices, it's important to carefully design well-defined APIs. It's also paramount that you properly handle versioning as to not break the services that rely on it. Taking the time to properly draft out the APIs of your microservices will save you a big headache down the road.

They're Independently Deployable

One of the pain points of a monolithic system is that change cycles are tied together; a change to a single, small part of the application necessitates the entire application being rebuilt and deployed. Microservices should be able to be independently deployed without a need to make changes anywhere else. If a change to a microservice requires changes to the main application, chances are the functionality of your microservice is too tightly coupled to your codebase.

Decentralization

What is this, blockchain? (laugh track plays). Decentralized governance is an important component of microservices. If a service is too tightly coupled to other business processes, you lose out on some of the main benefits of a microservice architecture. If your services are decentralized, you're not bound to any specific technology stacks, libraries, or frameworks. You could be running your photo uploading functionality through Golang, but handling account management through a Node API.

It's not just the conceptual models of an application that can be decentralized, but data storage as well. Microservices are responsible for persisting their own data & state. Where a monolithic system would have a data layer to manage data persistence across the entire application, microservices are much more flexible. You can have your services run different instances of the same database—or, if you're feeling particularly sassy—an entirely different database system altogether.

Why Microservices?

Scalability

With a monolithic application, you can achieve horizontal scaling by running multiple instances of the app behind a load balancer. However, this requires scaling the entire application, and not just the parts that require additional resources. Theoretically speaking, if 90% of the traffic on your site was going through a single function, you'd need to scale out your entire application to manage that single endpoint. Because microservices are individually deployed, they can also be individually scaled to meet demand. Neat.

Resiliency

One of the benefits of a microservice is that if it fails, it doesn't torpedo your entire application to the bottom of the ocean. Keep in mind that the proper fault protection must be in place—because the services are autonomous, the client doesn't know the health/state of your microservices when they send requests to them. It's important to manage these scenarios through a combination of monitoring and other fault protection measures (retrying requests, short-circuiting to avoid bottlenecks, etc).

Faster Development

Having an autonomous service means it's easier to add features and manage bug fixes. Changes can be made independent from the main application. You can safely roll back to a previous version if an update goes wrong. You can implement changes without worrying if it's going to cause side effects somewhere else in the app; this means less time to test, and fewer overall concerns to address.

Designing Microservices

There's no perfect formula to designing microservices. It requires careful deliberation about the business domain and goals of the application. Defining the boundaries of the individual services will be the biggest challenge, but making sure to follow the Single Responsibility Principle will help to provide an idea if your service is doing too much. Microservices designed around a business boundary should be "vertical"—meaning—not designed around a horizontal layer of your application. You wouldn't move your entire data layer to a microservice, because different data is contextualized to different domains in your application. Microsoft has compiled a handy list of microservice design patterns you can read here.

It's Not Without Drawbacks

Hold on, we need to talk.

As cool as it sounds, microservice architecture doesn't always fit organizational needs. There's a sort of teeter-totter effect with microservices; for all of the benefits that come with them, so does the complexity of managing your architecture. You may be saying, "but Keith, wasn't microservice architecture born out of the need to manage application complexity in monolithic systems in the first place"? Don't worry, the irony isn't lost on me—but you're essentially trading one problem for another.

In monolithic systems, it becomes difficult to add new features or update existing ones, because responsibilities or functionality could be widely spread across the application. A change to one service might have a ripple effect across the rest of the app. This causes a lengthy integration process as all teams need to be aware of the changes being implemented. Microservices tidy this up by making sure the each service is managing a single responsibility (and to that effect, different teams can manage different microservices). This sounds great, but now you're left trying to manage a massive web of autonomous services.

Have you ever had a bunch of things you needed to carry into another room but you don't want to make more than one trip? So you carefully tuck items between your arms; your left pinky hooked around the handle of something much heavier than you should ever rely on your pinky to carry. You start to slowly shuffle your feet, carefully balancing the items as they inevitably start slipping through your grip. This is basically what managing a microservice architecture is.

There's also other things to consider. Because each microservice is responsible for its own data persistence, it's difficult to maintain data integrity across multiple services. Having overly chatty services could increase latency times as requests jump back and forth between services. Also because of decentralization, there's a lack of governance in the code. Without setting specifications or standards, the independent nature of these services can make things difficult to maintain (especially if they're being written in different languages). It requires a different set of skills to manage this sort of highly-distributed architecture, so this could be considered another deterrent for an organization.

The important thing is to understand your organizational needs, and weigh the costs against the benefits. If you decide that microservice architecture is a good fit for you, go wild! There's so much more to say about designing microservice architecture, and there's a lot of great resources out there if you want to continue your research.

So the next time an interviewer asks if you're familiar with microservice architecture, just think back to this article and say: "I think it has something to do with the Power Rangers?"

Thanks for reading, I hope I was able to teach you something!

Best Wishes,
Keith Brewster (Twitter)

Haiku Poems for Web Developers

Keith Brewster — Mon, 19 Aug 2019 16:02:10 +0000

I type git commit
and I'm stuck inside of vim
it's been six years now

learning JavaScript
is like a really cool sword
you hold by the blade

I have to git pull
I'm not religious, but Lord
please no merge conflicts

nineteen ninety nine
my first site was a page of
Dragonball Z gifs

school taught us Java
and said we'd be Java devs
boy, they were way off

imagine if we
stopped gatekeeping junior devs
too bad we're a-holes

put in a PR
where I forgot to remove
console log("please work");

looked up array slice
eight times this week; here comes my
imposter syndrome

TDD is great
wait, the deadline is for when?
we'll write tests later

my work day is just
faking confidence for the
product manager

let's take a moment
to remember the short lives
of our side projects

I wrote Hello World
maybe three years ago so
yes I know Python

no time to fix tests
git force push no verify
so long, pre-commit

QA just called in
a full bomb disposal squad
my code did not pass

I just spent two hours
choosing a colour palette
should have done law school

I pretend I know
what this "Kubernetes" is
it sounds like it's drugs

I do something called
hype-driven development
I like shiny things

I say I'm full stack
but I just never got good
at any one thing

What the Heck is Declarative Programming, Anyways?

Keith Brewster — Tue, 13 Aug 2019 16:03:00 +0000

Chances are—at some point in time—you've heard someone bring up the concept of declarative programming. Maybe it was in a Medium article, or maybe you saw someone mention it on Twitter. Perhaps you were hanging out at a local tech social, when all of a sudden the brilliant, psychopathic CTO of some shady startup real estate disruptor started smashing empty beer bottles on the bar, brandishing the crude glass weapon & threatening to slash everybody in the room if they didn't stop using if/else statements.

They probably looked something like this.

"Declarative programming?" you ponder to yourself, "perhaps Wikipedia is able to summarize it in a simple & digestible manner for all of the newbies interested in doing some light research on the subject." Except you don't ask yourself that, because you know that reading anything technical on Wikipedia leaves you with the kind of headache rivalled only by the hangover after a twelve hour binge of the cheapest malt poison available at your local liquor store. The articles you come across are all different flavours of the same pain. One long-winded term eventually leads to the next, until it becomes a never-ending rabbit hole of self-destructive internet sleuthing, and by the time you're on the other side you can't even recognize yourself in the mirror anymore.

Actual photo of my research for this article.

Okay... so that could have been hyperbole, but hopefully I can ease the pain a little. A lot of people will argue the semantics of what can be considered truly declarative; I'm not writing my PhD thesis, so we're going to be learning the fun way (if you want the PhD version, please see this StackOverflow answer).

If you've ever looked up what declarative programming is, you'll probably be well-acquainted with some variation of this common answer:

Declarative programming is describing the WHAT and imperative programming is describing the HOW.

Alright, but what does that mean? There's a few things to unpack first: declarative programming has an antithesis known as imperative programming. You'll almost always find comparisons of these two opposing paradigms. But here's the thing, while these two approaches are opposites in execution, it doesn't mean they don't co-exist. This brings me to my first lesson:

Lesson 1: Declarative Programming Can't Exist Without An Imperative Abstraction (It's Just Layers)

I know I said this would be a beginner-friendly guide, so let me simplify what I mean by this. My work has this weird, fancy coffee machine with two pages of different coffees that it's capable of brewing, in which you will only ever drink exactly two of them.

The second page has an option for "vanilla choco latte", but nobody is brave enough to discover where these flavours come from.

Think about using this ungodly contraption vs. a French press. Let's say you're feeling particularly risk averse, and decide that you're going to stick with regular ol' coffee. You approach the monolithic coffee dispensing monstrosity and click "Pilot Monument". The machine makes a startlingly violent chugging noise, and the coffee dispenses into your cup. You don't really need to be concerned about what's happening between when you press the button and when it you get your coffee—you just get the drink you asked for. The coffee machine is a rough example of declarative programming. The implementation details are hidden; you express what you want, you don't specify how it should be done. Lets look at the imperative approach with the French press:

Pick your beans and grind them.
Boil water in a kettle.
Remove the plunger from the French Press, and pour your coffee grinds in.
Pour the boiling water into the French Press.
After 3-4 minutes (or desired steeping time), press the plunger down slowly to separate the grinds from the water.
Pour the result into a mug to enjoy.

There's a clearly defined control flow to follow; each step of the process is clearly laid out and executed. It's all good and gravy to tell an application what you want it to do, but something still needs to be pulling these levers behind the scenes!

Here's the same concept applied in a more practical setting. You may be familiar with the higher order function map added with ES6. If you're not familiar, let me summarize it quickly: map is a property of the JavaScript Array object that will iterate over the array that it's called on, and execute a callback on each item. It returns a new instance of an array; no modifications are made to the original object. Let's take a look at a comparison of functions (both declarative and imperative) that map over an array of strings and append the octopus '🐙' emoji on the end of each one (objectively the best emoji).

// Declarative
const addOctopusEmoji = arr => arr.map(str => str + "🐙");

// Imperative
const addOctopusEmoji = arr => {
  for (let i = 0; i < arr.length; i++) {
    arr[i] = arr[i] + "🐙"
  }
  return arr;
}

Fairly straightforward, and a good demonstration of this first lesson. map is a much more declarative approach than the traditional looping mechanism. You're not programming the control flow that determines how to iterate over every index of the array and apply the necessary operation. map does this heavy lifting for you. But map has an imperative abstraction. It's not magic, it needs to be doing something under the hood. The difference is that you don't need to be concerned with the implementation details of how it goes about doing its business (and as a bonus, it returns you a new instance of an array. This means you're not mutating any existing references like in the imperative example & causing any unintended side effects; more on this later). It's just layers, friends! Alright, now you're one step closer to being a declarative programming champ.

Basically you right now.

Lesson 2: Declarative Programming Is Not Functional Programming

That's not to say they're completely different ideas. A lot of people consider functional programming a subset of declarative programming. A true declarative program is written as an expression that gets executed/evaluated, with the ability to specify what you want the result to be (again, going back to that description you read everywhere). A good example of a declarative language is SQL.

SELECT
  *
FROM
  tough_guys
WHERE
  name = 'Keith Brewster'

Query returned 0 results.

Sorry to every other Keith Brewster out there, don't act like I haven't seen you while Googling myself.

You're not in charge of manually parsing the name column of a table and finding every tough guy named 'Keith Brewster'. You provide the constraints in the form of an expression, and SQL returns what you asked for. Thanks, SQL.

Now let's look at JavaScript. You can't just slap a single expression into an application and expect the JavaScript engine to run everything for you. You have to build out the functionality of your application with a series of functions (see where I'm going, here?). This doesn't inherently make JavaScript a functional programming language, because FP comes with its own set of rules and constraints. You can—however—apply these concepts in your code and use JavaScript like an FP language, just the same as how you could use classes and inheritance in JavaScript and operate like an OOP language. It's just another way of building out your application architecture.

What architecture should we build this house with, boss?

Functional programming is considered a subset of declarative programming because it also seeks to avoid writing code in an imperative or procedural way. I'm not going to dig too much into FP here (maybe it's foreshadowing for a future article). All you really need to know at this point is that declarative is not functional, but functional is declarative.

Lesson 3: A Decent Amount Of Modern Frameworks Handle UI Declaratively

Side story: in college I was constantly entrenched in Java. Every semester we just did more and more Java. Sometimes we touched other languages (C++, C#, PHP), but most of the time we were just building variations of calculators or solving math problems that we already covered in Java. Needless to say, it came as quite the shock when I left school and found that the job market was not 95% Java, despite my education preparing me for such a reality. I hadn't picked up much of an interest for web development in college, but I quickly fell into it after graduating. Getting thrown into JavaScript was a huge change for me; I started seeing people write code in different, exciting ways. If I can make one recommendation in this article, it's to open yourself up to different perspectives. Seeing how other people approach problems has been instrumental for me in growing as a developer.

Anyways, back on track. What is declarative UI? It's just another abstraction, but instead of hiding the implementation details of a function, we're hiding the implementation details of changing the UI—stick with me here. Let's take a look at how React takes a declarative approach to UI:

<PotentiallyGreenButton
  handleClick={toggleIsButtonGreen}
  buttonGreen={isGreen}
>
    {buttonText}
</PotentiallyGreenButton>

So here we have our PotentiallyGreenButton. It's a button that could be green, or maybe it's not green. We'll never know. Back in the day, if you wanted to update a DOM element you'd need to create a reference to it, and apply your changes directly to the element. That's a major inconvenience; your functionality is coupled to that single element (or depending on how you target elements, all of them). React abstracts updates to the DOM so you don't have to manage it. You're only concerned with developing your components—you're not in charge of the implementation details of how the DOM elements are updated during every render cycle. You also don't need to concern yourself with managing DOM event listeners. React provides you a library of easy to use SyntheticEvents that abstract all of the DOM event logic away so that you can focus on your important business logic (in this case, the green-ness of your maybe green button).

Lesson 4: In The End, There's No Right Or Wrong Way

I love approaching my code in a declarative way. Maybe you don't, maybe you like explicitly stating your control flow. Maybe it's just easier for you to understand, or just comes more naturally to you. That's totally cool! It doesn't make you any less valuable as a programmer, so don't feel bad if you're not used to it (and don't let anybody else tell you otherwise). The most important thing is being able to understand the ideas behind the methodologies of different approaches. You do you!

Before we wrap up, I just wanted to highlight a few reasons I love taking a declarative approach to coding:

Context-Independent:

A more declarative style allows you a greater degree of modularity. If your functionality isn't coupled to any sort of application state, it becomes context-independent. You can reuse the same code in any application, and it should function the exact same way. This means you should avoid changing any data that lives outside of the context of your function (global variables, etc).

Readability

This might be a hot take, but I think a declarative approach is more readable, as long as you put in the effort to have self-documenting function/variable names. Some people might find it easier to look at a control flow (loops, if/else statements) and follow along with each step, so this is more of a subjective benefit.

No Side Effects

Hey remember that little blurb of text inside the parenthesis back in my first point saying "more about this later"? Well, we're here! A side effect is what happens when modifying a value in one area causes an unintended effect somewhere else in the application. In a declarative application you should treat everything as immutable. That means that after you've initialized a variable, it can't be modified. If you want to update a value, you should initialize a new variable based on the item with any of the modifications you want to make (much like we did in our octopus '🐙' example with array.map). If you're not mutating application state, it shouldn't cause a side effect anywhere else in your app.

It's Fun!

Taking on a new approach to how you code is a fun challenge, and you may find yourself discovering new ways to approach problems. Because you stop relying on loops, you work more with recursion. Trying to reduce reliance on if/else statements might lead you down the path of functors. It's good practice, at the least!

It's finally over, you've made it.

Whew! Thanks for sticking with me this far, I know there was a lot of content to digest. If you enjoy what I do, consider following me on Twitter. I hope I've been able to help you out a little today!

Cheers!

My 2019 Resolutions as a Developer

Keith Brewster — Mon, 31 Dec 2018 20:14:08 +0000

Here we are, it’s the end of another year. As we say goodbye to the sometimes-great-sometimes-uncontrollable-trash-fire that was 2018, it’s time to start planning our New Year’s resolutions. As developers, it’s a perfect opportunity to lay out our development goals for the new year. But we also know that resolutions can be a real drag to follow, so I've broken my goals up into ones I will definitely accomplish, ones I will probably accomplish, and ones that I will briefly consider accomplishing. So join me in sending off 2018 the right way—full of ambition (and 400mg of Ibuprofen to curb our collective violent hangovers).

Me taking a quick nap, exhausted from all of the ambitions I have for 2019.

Resolutions That I Will Definitely Accomplish

Start writing

Hey, I’m writing right now, so we’re already off to a great start! 2019 will be the year I put pen to paper (metaphorically speaking, I haven't owned a pen since I started college). Articles, blog posts, maybe even a book (this is quickly becoming one of the goals I will briefly consider accomplishing). I’ve always wanted my words on the internet (apologies in advance), and I'm incredibly grateful for the opportunity to use platforms like this to reach an audience.

Start a blog

I'll be honest with you, this is pretty much just expanding on the first goal. If you make your goals similar enough, it's easy to tackle two at the same time. It's a great trick to feeling more accomplished and I highly recommend it.

Read books

There’s a lot of important books that I haven’t read (though, to be fair, there's also a lot of unimportant books I haven't read). I think I made it through maybe 75% of one book last year so I really have nowhere to go but up. I'm hoping to remedy this in 2019 with this handy list sent down to me yesterday from the heavens (via recommended articles):

29 Must Read Books For Programmers

Blaine Osepchuk ・ Nov 14 '18 ・ 7 min read

#career #productivity #learning #effectiveness

If anyone has any other suggested readings, let me know!

More Side Projects

I'm pretty satisfied with the side projects that I completed in 2018. Unfortunately, I was incredibly encumbered by my lack of free time (I generally work 60-70 hours a week between two dev jobs because I'm getting married in February and weddings are an unstoppable destructive force to your bank account). Up until this point, most of my applications have been relatively small in scale, and I'm hoping to work on something with a much more significant impact this year.

Resolutions That I Will Probably Accomplish

Contribute to Open Source

Contributing to an open source project is something I’ve always wanted to do, but I have always been too overwhelmed when searching for a starting point. It's kind of like how my college gym had this rock climbing wall that I always wanted to try out, but I never knew how to approach it. Are you supposed to use hand chalk? How do you put on a harness? Do I need special rock grippy shoes? So I just got really into running instead.

More GraphQL

I like GraphQL a lot. I've used it a bit in my own incredibly unfinished projects. I've used it in my own incredibly unfinished GatsbyJS blog. But I still have a limited grasp on the full power available, and I will use 2019 to unlock it's true, dark potential.

Get married

Sure this isn't exactly a development goal, HOWEVER my level of productivity at home directly correlates with my fiancee's current level of happiness. You may also notice I put this under probably accomplish and, well, I’m getting married on February 22nd and a lot can happen between now and then (that was a joke, please don't tell her).

Resolutions That I Will Briefly Consider Accomplishing

Start a YouTube channel

I’m a little more hesitant about this one. I was thinking of doing development stories & opinion pieces, but 2018 was a rough year to have opinions and I feel like 2019 won’t be any better. I did, however, buy Sony Vegas for $35 on a Humble Bundle (to curb the guilt of my previous use of a not-so-legitimate copy of Adobe Premiere) and I feel like I should put it to some sort of use.

Teach

I don’t know in what capacity. Maybe a course. Maybe tutorials. Maybe sagely advice to a young opportunist who I meet on the street through random happenstance. I am thirty-one years old now, which I feel is an appropriate age to start aggressively forcing my wisdom on to teenagers with a proclivity of self-importance only awarded through years of surfing through passive aggressive comments on StackOverflow.

Reach 1k Followers on Twitter

A man can dream, right?

I hope you enjoyed my list of development goals for 2019. Let me know if you have any big plans for the new year. Thanks for reading, and I'll see you all next year. 🎉