Functional programming is one of the most powerful ways to learn how to write clean and scalable code. I truly believe every software developer could benefit with a little bit of foundational knowledge in functional programming.

Anyone who has embarked on this journey to learn how to code has came across this question. Your first thought might have been to google it. Next thing you know, you realize that the internet is filled with lots of good opinions. Too many good opinions.

So, you decided to learn to code and maybe went through a few online tutorials. You know a lot of different things — syntax, conditionals, classes, prototypes, etc.But what’s next? You actually want to build something, but it feels like you’re not able to put everything together. What do you do next?

Everyone’s circumstances are different— including timing, affordability, job obligations, family responsibilities, and so much more.Therefore, while I don’t have a silver bullet answer to this question, I’ll share how I evaluated this decision for myself.

“It’s hard to know if the decisions you’ve made are the right decisions. Maybe there was a decision that I made that was entirely wrong, and I don’t even know it yet. You can’t A/B test the past.”

MooTools was a well-known JavaScript utility library for building “powerful and flexible code with its elegant, well documented, and coherent APIs”. Its core contributing team was made up of a brilliant set of developers, and we’re lucky today to be speaking with three of them.

Imperative vs. Declarative. Pure vs. Impure. Static vs. Dynamic.Terminology like this is sprinkled throughout programming blog posts, conference talks, papers, and text books. But don’t be turned off by this jargon. Let’s jump right in and break some of these concepts down...

The first programming languages I learned were JavaScript and Python, both of which are dynamically-typed languages. But my foray into static types have added a whole new dimension to how I think about programming.

Static types offer many benefits when writing programs. Let’s explore a few of them.

As a JavaScript developer, you can code all day long without encountering any static types. So why bother learning about them?Well it turns out learning types isn’t just an exercise in mind-expansion. If you’re willing to invest some time in learning about static types’ advantages, disadvantages, and use cases, it could help your programming immensely.

You’ve probably heard the expression “easy to reason about” enough times to make your ears bleed. The first time I heard this expression, I had no idea what the person meant by it. Does it mean functions that are easy to understand? Does it mean functions that work properly? Does it mean functions that are easy to analyze?

Internationalization is a big problem. If you want your application to make a worldwide impact, you have to deal with language barriers. Unfortunately, the road from “Your funds will arrive by July 7th” to “Vos fonds arriveront le 7 Juillet” is far from simple. Before your application can succeed outside the English-speaking world...

Closures are a fundamental JavaScript concept that every serious programmer should know inside-out. The Internet is packed with great explanations of “what” closures are, but few deep-dives into the “why” side of things. I find that understanding the internals ultimately gives developers a stronger grasp of their tools...

On a high level, module bundling is simply the process of stitching together a group of modules (and their dependencies) into a single file (or group of files) in the correct order. As with all aspects of web development, the devil is in the details. :) Why bundle modules at all?

If you’re a programmer or techie, chances are you’ve at least heard of Docker: a helpful tool for packing, shipping, and running applications within “containers." While the Internet is full of excellent usage guides for Docker, I couldn’t find many beginner-friendly conceptual guides, particularly on what a container is made up of. So, hopefully, this post will solve that problem :)

If you’re a newcomer to JavaScript, jargon like “module bundlers vs. module loaders,” “Webpack vs. Browserify” and “AMD vs. CommonJS” can quickly become overwhelming. The JavaScript module system may be intimidating, but understanding it is vital for web developers.

If there’s one thing I’ve learned about programming over the last few months, it’s that you don’t have to be a programming wizard to build something useful.Case in point: My teammates Banun Idris, Colin Seale and I spent the last couple of weeks building our first open-source library.

We went over basic web architecture in part I, and we talked about web application structure in part II. Now it’s time to roll up our sleeves and tackle part III: a closer look at HTTP and REST.

In my previous post, we dived into how the web works on a basic level. For this post — part two of a three-part series — let’s double click on understanding how the client, server and other parts of a basic web application are actually configured to make your web browsing experience possible.

If you’re just getting into web development, chances are you think you know how the web works — at least on a basic level. But then you try to explain how a basic website works and draw a blank. What does an IP address mean again? How does the “client-server” model work, exactly?

Documentation can be incredibly scary for newcomers. It certainly was for me — I avoided docs like the plague. I was frustrated by the difficult jargon and overwhelmed by all the new concepts. Like many newcomers, I relied on blog posts and tutorials to walk me through issues, only cracking open the documentation when truly desperate.

There comes a time in every developer’s life when jQuery welcomes her into its dark underworld. That point when her code does gymnastics on the page, but collapses to a tangled mess underneath. You could hit the wall with this anywhere in your career. “Is this the norm?” you ask yourself.

One of the things I’m realizing as I progress is that a significant chunk of my time as a developer is spent debugging. When I first started coding I had this misconception that the better I got, the less time I’d spend going back to fix errors. I imagined clicking away on the keyboard, shredding through code. Boy was I wrong.

My journey into software development has officially begun.I spent the past week putting in 12-hour days at Hack Reactor, an immersive coding program here in sunny (cloudy?) San Francisco. After 6 straight days of Sublime Text, Stacks, Queues, Hash tables, Graphs, Prototypal chains, Scopes, Closures, the keyword “this,” I’m so cross-eyed I can barely see the screen.

I recently stumbled upon this Quora post by a concerned parent asking for advice in discouraging her daughter from becoming a programmer. At first glance, I was furious. I couldn’t fathom why a parent would purposely crush her daughter’s dreams of entering an exciting and challenging profession...