the best post ever written on learning to code

update – 2.5 years after publishing this post, i’m proud to release my own “how to code” course, Founder/Hacker. if online isn’t your thing, i also teach in person.

prologue

in case we haven’t met: i’m a marketer, musician, and developer in New York City.

i grew up outside Atlanta, attended public schools, scored bad grades, was rejected by a state university, accepted after writing a plea letter, and my first full-time job after college paid a whopping $43,000… in New York City.

for all intents and purposes i grew up “average” and assumed i would remain “average” with a few vacations and nice restaurant meals before i stopped breathing and had an “average” funeral.

yet nowadays i run a multi-million dollar portfolio of companies, lead software teams, teach and speak at events, travel the world, blah blah blah.

so after many requests, i’m sharing the highest leverage decision i’ve made to achieve this lifestyle: learning to code.

it begins with a story.

chicks get in the way

it was at my first job, which began January 7, 2013, where i saw developers doing their thing: coding.

their computer screens looked like The Matrix… cryptic characters, black background, and bright colors for arbitrary words like function() and end.

feeling inferior as “just a marketer” i assured myself: at least you can date hot chicks!

so i did.

i found it easy to make girls (strangers) laugh. it was easy to ask them out, and it was easy to make them comfortable enough to ________.

this comfort zone — that i could “talk to chicks” — suppressed my anxiety of not knowing how to talk to computers.

myth of the minimum IQ

when my first job flew me to Madrid to meet our developers, i remember staring at my Spaniard colleagues’ Matrix terminals, thinking: “wow, i could never do that.”

today i chuckle, but back then it’s what i believed, so it was true.

a few other things i knew were certain in January 2013:

• i’m not smart enough to code
• i’m not logical enough to be good at it, even if i learned
• i don’t “think” the way programmers think
• i could never catch up to their skill level if i start in my twenties

after rehearsing these lines a few times, i was ready to spend the rest of my career as a “non-technical,” a throwaway seat at tech conferences.

i was prepared to be That Guy developers fear meeting at cocktail events, who corners them in bathrooms with “let me tell you my idea…”

weeknights i could have spent learning were spent on Seinfeld re-runs. weekends i could have spent learning were spent swiping on Tinder.

remember my track record:

• almost kicked out of high school
• barely got into college

nobody said “you can do it Ryan” or “those developers aren’t smarter than you.”

in fact, it was my then co-founder who screamed at me “Ryan, you don’t know s*** about technology!” that motivated me to prove him wrong.

i hope this post communicates the same encouragement, without the negative reinforcement.

defining parameters

if you’re reading this you either:

• know how to code
• don’t know how to code

it’s not easy to bucket the world’s population into 2 groups, especially since there are now 59 genders, but the technical vs non-technical war rages on unchallenged.

in this essay / tutorial / tell-all, which i hope will be the best post ever written on learning to program, i’ll give you the kick in the ass [you require] to make your own informed decision:

“should i learn to code?”

the problem

before endeavoring on this guide i read many others like it.

from “how i learned Angular in 3 months” to “i used to be homeless, now i’m a full-stack developer,” and my personal favorite: “how i CURED CANCER by learning HTML.“

just kidding.

while these essays are entertaining, i doubt they help readers inch closer to a reality they claim to exemplify.

at best, decent “how to learn to code” essays link to resources where you can get started. some of these links may be affiliate style (lol), a sort of hidden compensation for the writer. hell, i’ve done this myself.

but do you wanna know how much $$ i’ve made by dropping “code school” affiliate links in a dozen blog posts with 10s of 1000s of views?

$ZERO dollars.

and i finally learned why.

it’s because inspiration isn’t enough. encouragement isn’t enough.

telling someone “you can do this” doesn’t mean anything unless they actually agree with you.

more important, inspiration doesn’t work without a why.

here are a few reasons i was personally inspired to learn programming:

• unlimited job opportunities
• it’s fun to build things from scratch, for free, with a laptop
• chicks

i’m only half kidding about the last one. and if you’re into guys, replace “chicks” with “dudes.”

so:

• if you’re interested in permanent job security,
• if you want a new sonic boom alarm clock without ads,
• if you’re single and refuse to enslave yourself to Finance in order to be successful…

this post might be for you.

the solution

instead of linking to resources, waxing computer science references, or using ANY conventional strategies of essay-writing, i’m going to shoot from the hip and begin teaching you to code within this post.

what to expect for the next 30 minutes:

• i will not ask you for $$
• i will not link you to anything that asks you for $$

getting started

the toughest hurdle in learning to code is taking the first step.

there are 1000s of online courses, platforms, programming languages, frameworks… where to begin?

even confident, self-aware, sharp professionals with a penchant for research (Google searching) are overwhelmed in answering the question: what’s next? (source: my Ivy League friends still don’t think they can do it.)

giving up, or “i’ll just be a non technical person foreve, yolo” resignation, probably happens every 2-3 minutes.

do the math:

• 35,000+ startups (source: Angel.co)
• 1 million+ developer job openings
• < 100,000 computer science & developer bootcamp graduates per year

there are 10 available jobs for every person who knows how to code. meanwhile, unemployment rates for lawyers is 3x the national average, at 15.5%.

so here’s the truth. and i’ll offer a few more later:

it doesn’t matter where you start, so long as you start somewhere.

“should i do frontend or backend? Ruby or Python? Angular or React?”

blah blah blah.

when someone asks me these questions at a conference or meetup, i know they’ve been infected.

time to disinfect.

the essence of code

learning to program is really just learning to think logically.

you might know a developer who is eccentric or acts “asperbergers-ee”.

i’d argue most of these cases happen because after an [average] person learns to program, a tectonic shift happens in their headspace whose side effects include speech manipulation.

since programming is just about things being true or false (or, mostly true/false to machine learning folks), code makes it easy to perceive the world as black or white.

this is why i wrote:

• everyone either knows how to code, or does not know how to code

if i wasn’t a programmer, but still wanted to summarize the world’s population, i may have instead written:

• you kind of know how to program
• you’re a seasoned developer
• you conceptually understanding programming
• you’re thinking about learning to code
• you don’t know how to program

can you spot the difference?

sure, the population could be bucketed into 5 personas (vs 2), but it’s messy.

learning to code provides requires clarity in truthiness of things that, for better or worse, permeate daily life.

and we witness this clarity when we meet a hard core programmer we’re convinced is fundamentally different, or has a special mind.

we’re convinced this special-ness precludes us from being like them.

i hope you understand now that their eccentricity was an effect of programming – aka logical thinking – and not a cause.

with that cleared up, here are the concepts that govern ~all modern programming languages.

things that don’t change

forget Python, Angular, JavaScript, CoffeeScript…

programming languages are “DSL’s” — domain specific languages — that exist to help us express logical ideas and calculations in a language we understand: English. (or Japanese, Chinese, etc).

learning “things that don’t change,” a strategy i first heard from teachers Chris Lee and Kevin Wang, guarantees insulation from fads and ultimately, wasting time.

for example, say i want to build a flash card app that tells me if i’ve provided the right answer to a question.

let’s spend 20 minutes pushing through 4 core tenets of programming to build a sample application within this essay:

1. conditionals
2. methods
3. types
4. looping

the links above will skip to those sections, but will also skip concepts that put everything into perspective.

i highly recommend you read everything in the order it was written. pour a cup of coffee or take a dump in the middle to maintain attention.

conditionals

imagine a flash card appears on my iPhone X with question “What’s 2 + 2?”

i input “4,” hit enter, and the following code is executed on the app’s server.

of course, this isn’t exactly right. because 2 + 2 is always 4, and i don’t see my “4” input anywhere in this code.

let’s try again, taking a lesson from 8th grade Algebra I class.

we’ve now assigned x to whatever the user inputted. if this were a plain algebra problem, it would look like:

this concept is the if conditional. if something is true, do something.

but we can make our if-conditionals a little more interesting.

what if we want the user to see an Error message, if they input a wrong answer to our flash card question?

our code is executed top to bottom, left to right.

with x being the user’s input, if they were to provide 3 or 5 or some other number, our code would obey the else condition and execute the alert "Incorrect!" logic instead.

one more extension to the if/else conditional.

suppose our Flash Card application asks users a multiple choice question. something like:

“Input a number that is at least 4 but less than 6.”

here we introduce elsif. it acts like else, except carries it’s own strict rules, or conditions.

therefore, if the number “3” were assigned to x, it would of course skip Lines 2-4 because the result of Line 1 is false.

however, when x hits Line 5, it would again result in false.

this is a very different outcome than if Line 5 simply read “else.” in developer speak, this would cause what’s known as a subtle bug, which are some of the hardest to reproduce and fix.

taking a break from coding

we just recapped a core concept in all programming languages: conditions.

it’s not too early to think about how this section may have changed your perception of programming in general.

first: everything we just did was in plain English.

no binary 1’s and 0’s, no discussion of how Ruby is actually written in C, another programming language. no need to understand why certain keywords like “if” or “end” have their own colors, known as syntax highlighting.

it doesn’t even matter where i wrote these snippets of code. while not recommended, you could paste the above snippets into Microsoft Word or Google Docs and it would still be valid Ruby.

the point i’m making is that beginners often try to understand the “why” of programming.

we can’t allow ourselves to appreciate if, else, elsif statements unless we see The Big Picture. why?

did our dad teach us Angular Momentum when he took the training wheels off our bicycles?

yes, there are laws and technologies and a wealth of history that explain how programming really works. but if you’re just starting out, trying to comprehend them is a waste of your time.

methods

remember this if/else statement we wrote that evaluates whether our user’s input is the correct answer to “what is 2 + 2?”

what if we want an entire quiz inside our Flash Card app to be simple math problems…

would it make sense to write code like this?

the only unique elements in the above example are Lines 2, 9, and 16. the true path says “Correct!” on the user’s screen, and the false path says “Incorrect!”

this leads us to another principle in programming: DRY, an acronym for “don’t repeat yourself.”

we can make the above code more concise by simply adding new algebraic-style variables.

if x is the user input, can’t y be the app’s answer?

in this example, the user inputs a number, ie “4”, which is assigned to x. then, somewhere else in our code, we’ve decided that y equals the Flash Card answer. finally, the == double equals simply compares the value on the left and right, to see if they’re the same. 

remember, a single = is for assignment, ie x = 3, and a double == checks if left and right are the same. thus:

understanding this, we can now create a function – or, reusable bit of code – that uses the same core logic to evaluate different pieces of information.

here’s an example:

let’s break down what we wrote above:

• Line 1, def addition_problem is how we “define” a method, hence the shorthand def
• Line 7 is the closing end for our addition_problem method, which tells the application where to stop executing code
• the (user_answer, correct_answer) section on Line 1 is where method “parameters” are defined

method parameters are optional, and not all methods have them. you might wonder how a method could be useful if it doesn’t work with dynamic data, like a user’s input.

here are a few examples, written with library code not yet depicted:

in our first method, date_night?, we’re simply using a Date library to evaluate if the weekday (wday) of today is 5, or Friday. in bitcoin_price we’re actually invoking, or “calling,” another method from another library, to figure out the current price of Bitcion.

as you can see, these methods allow us to perform simple calculations throughout our application, without rewriting their inner code logic. another thing they let us do is change application logic later. for example, what if we wanted our “date_night?” logic to apply to Thursday’s instead?

with all our references to this helper method, we can simply change Line 2 to Date.today.wday == 4, and boom: everywhere in our application, we now evaluate things as true or false, based on Thursday as date night instead of Friday.

this strategy of identifying reusable code and encapsulating it into methods means we can add as many cards as we want to our Flash Card “math” module, with just a single line of code that invokes addition_problem method, passing in the correct answer as the 2nd “argument.”

a couple protips on terminology to clean up our language here:

• when methods are “defined,” ie written/created for use later, this is called method definition
• the comma-separated dynamic values that methods define are called Parameters
• however, when we actually “use” a method later, this is called method invocation, or “calling” for short
• when we call a method and pass dynamic values into them, those values are called Arguments, not Parameters

kinda silly, but important to some folks in the community.

DRY principles outside programming

DRY is a great way to think about many of life’s challenges, and most of us already apply them subconsciously.

a few examples.

the beginning of most legal contracts assigns “_____, hereby The Seller”, then uses that variable (The Seller) throughout the agreement. if The Seller changes, a lawyer updates it once at the top, instantly altering the entire contract in a single stroke.

Google Chrome asks web surfers if we want to save password for future logins to that website. systems thinkers who don’t care about security click “yes.”

before writing Thank You cards we print return address labels with our name and apartment so we don’t have to rewrite it on the top left of every envelope.

the list goes on.

if you find yourself saying things like “let’s put this in a Google Doc!” or “i’ll make us a spreadsheet,” you’re already wired to DRY thinking.

if not, you’ll learn, because programming (and life) is easier when you do less to achieve more.

syntax

so far all our code examples have been in Ruby.

this is to simplify understanding and embrace things that don’t change, but for kicks here is our first if statement in 4 other languages.

java

python

javascript

php

i won’t get into every difference between these examples.

at a glance, however, we notice Python requires : colons, Java and JavaScript (these are very different languages!) use {} curly braces, and Python also doesn’t care about closing end keywords to “wrap up” a conditional expression, like Ruby.

oh, and PHP requires extra code at the top and bottom of our file. gross!

for now, the most important distinction between these examples is the amount of code required by different languages to achieve the same thing, from 3 to 10 lines.

generally speaking, the amount of code we write to express a bit of logic is known as verbosity.

code that carefully explains, through long method and variable names, or obvious inline comments, is called “verbose” by developers, sometimes in a snarky way.

ultimately, how succinctly you write code is up to you, but keep in mind that some managers or applications prefer one style over another for performance or political reasons. ;)

types

so far we’ve been assigning and comparing integers like 4, 11.

but there are also decimals, floats, strings, arrays, and hashes.

Integer

any whole number, positive or negative.

String

text, ie “Correct!”, which can also include numbers, ie “3 Correct Answers” or even “1,” if assigned inside quotes.

Array

an array is a collection of objects or values, usually referred to as elements, surrounded by [] brackets and comma-separated:

[3, 4, 5] is an array of integers.
["three", "four", "five"] is an array of strings.
[3, "something", 5] is an array containing integers and strings.

Hash/Object

pending your programming language these may be called maps, hashes, or objects. let’s stick with “Hash” for now, and describe them as a “set of key/value pairs” like this:

{'key' => 'value'}

their usefulness kicks in pretty intuitively:

here we’ve assigned multiple questions to a single Ruby variable, questions, and we can access each question like this, using what’s called “bracket notation:”

in addition to retrieving we can also assign key/value pairs this way.

below we stub an empty hash, then “load it up” as we go, possibly throughout the Flash Card application.

Float / Decimal / etc

each language has their own rules for number handling, but to give you an idea, 5.3 might be called a Float or Decimal, or both.

protip: if you sum or divide or multiply differing number types, unexpected rounding operations could cause your math to be slightly wrong and tough to debug.

combining types

Arrays are collections of objects.

an integer can be an object, but so can a string, and so is a hash.

Ruby lets us constrict an array like this, with an integer, string, and hash, without any errors:

figuring out the best primitive types to use for any given value in your application is an ongoing challenge that engineers like to debate over afternoon coffee, in online forums, and anywhere else they want to sound smart.

don’t worry about a specific framework for type assignment, for now just understand that they exist, and each type of object (string, array, integer, etc) has its own built-in methods.

looping

so what’s the point of these different types of objects, elements, or variables?

i’ve intentionally saved this concept for last, because it unlocks the incredible power of programming overall.

looping is when we iterate through a collection of values to perform functions (methods), operations, filters, etc and ultimately achieve a new result.

suppose we want an average age of every student in a 10th grade math class.

we could input each student’s age into a calculator…

(16 + 15.6 + 16.25 + 17.1 + 16.4 + 15.8) / 6 => 16.19 years old (average student age)

but what if our class had 100s of students, like a college lecture?

how would we easily derive our denominator – in this example 6 – to divide by and achieve the average age?

this is a great use case for looping.

suppose that instead of a calculator we add each student’s age to an array of ages, then divide by the quantity of students dynamically:

a few things are happening here, and remember, our code is executed top to bottom, left to right:

1. first, we put all the students’ ages into an array of Floats (decimal numbers) in Line 1
2. next, we “instantiate” a new variable, total_years, and assign it the value 0.0 so it plays nice later with addition operators
3. lines 5-7 execute a loop of our ages array, using each...end syntax, which we’ll cover in a moment
4. Line 9 divides the total_years variable (97.15) by the number of students, calculated dynamically with the size method

let’s zoom in on #3 and #4.

styles of method invocation

earlier we defined a method named addition_problem, which we invoke by passing in 2 arguments: a user’s input, and the correct answer to the math problem, ie addition_problem(3, 4).

in the example above, however, we invoke .size on our ages array, without passing in any values. how does this work?

under the hood, ages.size (which yields 6) is the same thing as calling Array.new(ages).size.  

shorthand operators

another new quirk in our code above is the += operator.

this is shorthand for the expression:

total_years = total_years + age

since we want to add the current student’s age to our existing summation of all the students’ ages, we can write += to save a few characters. same goes for *=, -=, etc.

now for the good stuff – our loop.

each…end looping

if ages is an array of student ages, then a single element from our ages array might be 16 or 15.8. but how do we access those individual ages, for summing with our total_years variable?

the anatomy of a loop:

1. collection
2. inner-loop variable name(s)
3. stopping point

in our example, ages is the collection and calling the built-in array method .each lets us then define a variable on-the-fly, or age in this case.

many programmers use pluralized collection names, then define inner-loop variables that are equal to the singular version of the collection’s name, to represent individual elements.

a few examples:

• ages.each do |age|
• people.each do |person|
• answers.each do |answer|

(this is not required, but is a best practice in development that makes it easy for other developers to read and extend your code later.)

now that we know what a collection is, and we know .each is being called on it, and we know that do is simply kicking off our block of logic….

the only remaining component here are “pipes,” those straight up and down lines. inside our pair of pipes is the inner-loop variable name, which (again) is commonly the singular version of our collection name.

after defining an inner-loop variable name we can write new logic underneath the .each do |variable| line of code that works with a specific element in our collection, or array.

see it in action:

in this grocery example we merely print out each element.

but we can also harness each element’s value to create a new value, which is the case in our ages example.

loops are the essence of programming firepower.

let’s go back to our flash card application and write a few bits of code that put together everything we’ve covered:

• variables
• conditions
• methods
• integers, hashes, arays
• DRY
• looping

if you think you see something we didn’t cover verbatim in this tutorial, you’re right.

that’s our final concept to address, one that underscores the basis of everything developers do.

learning how to learn

if you’ve ever had an idea, it might have sounded like this:

• two-sided marketplace
• connects X with Y
• charges a % commission per sale

when i read the above spec i see Uber, Airbnb, Indeed, and Coinbase as just a few examples.

yet all of these platforms are different. so how can they be summarized with the same attributes?

going back to our understanding of DRY principles, we learn as developers that everything we want to do has already been done, even if the use case was different.

no, we can’t download an Airbnb clone and click Deploy. but we can find snippets of logic to handle 2-party payments, or show popup modals, or calculate commissions, etc.

when [good] developers decide to build something, they first break the “problem” into a set (collection) of much smaller problems.

our flash card application could be broken down in the following way:

• ability to ask a question
• ability to evaluate an answer
• ability to show user their score

these are OK, but we can be much more granular.

so far in this post we’ve focused on the 2nd bullet, “ability to evaluate an answer.”

within that spec we focused on basic arithmetic, creating a math module and writing a method that performs any addition problem, then provides the user/application feedback about the truthiness of the user’s answer.

applying this to our final code snippet above, where i’ve inserted unexplained code like "#{}" syntax and  questions[question_number][:answer] notation for accessing nested values, we might execute the following Google searches to understand what’s happening:

• “#{}” in Ruby
• “Ruby hash [] bracket notation”

at the time of this writing, the 1st result for each of those queries explains the code i wrote above.

if reading those results bothers you, the need to look up a tiny syntax nuance or “rule” of {{ insert programming language }}… get used to it.

i’ve never met a developer – at any skill level – who doesn’t crack open Google every 20 minutes to read documentation on methods, best practices, design patterns, and opinions.

the idea that you need to memorize thousands of words and rules to do a great job or build something powerful is a lie.

and with that, let’s talk about a few more lies.

developer elitism

Paul Graham, founder of YCombinator and arguably the godfather of startups says in his book Hackers & Painters that the hackers are those who weren’t cool in school. that they were different, weird, or not good with the ladies, etc.

i think for many hackers in hubs like San Francisco, this is true: programmers IRL (in real life) can be a bunch of socially awkward losers.

but what Paul fails to address in his essays about programmers is the dark side that i’ve personally observed for 5 years:

developer elitism.

the way i see it: developers who were teased in school are now striking back as adults by telling the world that programming is a complex topic, only to be understood by the ordained few.

silicon valley’s ethos is Revenge of The Nerds, and nobody seems to care.

this makes sense, of course:

• XX programmers finish CS degrees / bootcamps per year
• (XX * 10) programming jobs exist

it’s simple supply & demand: the wider gap between programming talent and job supply, the more programmers are paid. the smaller the gap between talent and market demands, the less programmers are paid.

for this reason i think, if we do insist on branding all programmers as sharing one characteristic, it’s that programmers and engineers are foremost those who recognize and exploit supply and demand deficiencies in the free market.

if, for whatever reason, calligraphy was a highly sought after profession, many of silicon valley’s brogrammers would be etching poetic right now from a cabin in Tahoe. (yes, some coders have an intrinsic love for programming, but they’re the exception, not the rule.)

dear readers who only have the tolerance to retain 1 piece of information from this blog post, remember this:

everyday life (sales, relationships, customer service) is much more complicated than knowing how to code.

any developer who tells you otherwise is lying to protect their salary or ego.

a journey of milestones

programming is like any skill: there is a learning curve, then another learning curve, then another…

the first learning curve of playing guitar is being able to quickly switch between chords. for piano it’s coordination and the simultaneous comprehension of Treble and Bass clefs. for drums it’s independence to play different rhythms on each limb.

snowboarding? maintaining balance and carving in both directions. typing? not looking down at your fingers, being able to hold “shift” and hit the right character on your first try.

learning curves are universal, and for every skill they land at different “markers,” from 1 hour in (card games) to a few months (ie: speaking Spanish).

in programming, the first learning curve is memorizing syntax. then, it’s learning how to think logically. finally, it’s learning how to break huge problems into smaller ones.

what’s nice about this sequence is they happen organically… your first programs will probably break due to syntax errors, not algorithm logic.

second-degree projects will require smart planning, and further down the line you’ll tackle problems so big you may spend weeks with a whiteboard and a notepad before writing a single line of code.

getting fancy

we learned about if...end statements, but did you know that the end isn’t always required?

here’s another way to rewrite our previous example in Ruby:

by executing a conditional expression’s outcome before the if and underlying logic, we’ve saved 2 lines of code.

here’s another way of writing an if...end statement, using the opposite form of truthiness:

instead of if we’ve written unless, which just means the inner logic ("puts Incorrect") will execute IF the “unless” expression evaluates to false.

confused? don’t worry if this feels awkward.

using if...end versus unless...end is yet another stylistic preference in programming.

that said, it’s sort of like hitting a backhand in tennis. while you may be able to run around the ball to force a forehand stroke every time, there are benefits to being comfortable with swings from both sides of your torso.

for instance, the following code uses unless...end and arguably reads better to a programmer reviewing it:

as you can see, sometimes it’s more intuitive for “unless” statements vs “if” statements, because this is how humans speak: affirm the positive, deny the negative.

there are many more styling, short-hand, and design patterns in coding la-la land. the good news is they’re only a Google search away.

for reference i’ve written 200,000+ lines of code this year and know just a few dozen of these tricks.

the best way to absorb best practices is to write code, read code, and ask questions.

finding motivation

lifestyle bloggers Ed Latimore, Mark Manson and Buddha share this salient advice:

every decision you make is pain.

if you decide to work out and watch your diet, you’ll experience the pain of muscle soreness, of saying “no” to free cheesecake, of your alarm clock taunting you for a morning workout.

conversely, if you decide to not exercise and eat whatever you want, you’ll feel the pain of shorter lifespan, nasty looks at the pool, and possibly the inability to secure a job or romantic partner.

their argument, then, is not to try and avoid pain, because such a goal is futile.

instead: embrace pain, and choose the right pains to endure.

learning to program, like learning to play guitar or speak Japanese, requires a bit of pain before it’s fun, profitable, impressive.

but if you don’t learn, and you desperately want to…

that repertoire of Netflix knowledge will cause much greater pain long-term.

things more complicated than coding

have you ever been in a romantic relationship for more than a few months?

have you hosted multiple meetings to close a sale or get accepted to college?

have you ever planned an epic date, vacation, or outing with friends?

if your answer to any of these questions is YES, you’ve done more complicated things than programming.

frankly, coding is a bunch of if,else,elsif statements. it’s a collection of methods and variables and strings and numbers, telling a computer if something evaluates to true.

are you still afraid? you shouldn’t be.

the only folks with something to fear are Real Developers who disagree with this essay, because it challenges their status and identity.

which brings us to my final note…

don’t identify as a developer

i’ve painfully dubbed myself a “developer” throughout this post for readability.

but i don’t usually talk about myself this way. i don’t call myself a developer, i call myself a maker. someone who adds value.

many developers do the opposite. “C++ programmer at Google.”

cool story bro, but what do you do?

i look forward to a new generation of folks who talk to computers && girls, but don’t put their identity in either.

here’s to creating things, with code or otherwise.

Ryan