DEV Community: Ed Toro

After The Coding Bootcamp

Ed Toro — Wed, 18 Dec 2019 15:23:48 +0000

So you just graduated from a coding bootcamp. Congratulations!

You're not alone.

Many graduate from online courses and in-person coding bootcamps (aka code schools) every year. This glut of talent may sound like bad news.

Jobs...

You, recent graduate, may be feeling pessimistic. There seems to be too much competition for junior positions. And it's getting worse by the (demo) day.

But I welcome it.

I believe that adding new talent to an ecosystem with room to grow actually increases opportunity overall. Startups that would have otherwise thrown in the towel for lack of talent feel emboldened to venture more. Larger enterprises gain the confidence to start new projects. Careers are advanced at all levels.

But my optimism for this new software industry landscape isn't shared by everyone. I've witnessed, both in-person and on Slack, many bootcamp grads struggling.

That struggle arises partly from imposter syndrome, which I'll address at the end.

But it's also about not being sure what steps to take now that your job training program is complete.

Junior devs are the foundation of a strong industry. We need you.

So here are some tips for those wondering, "Now that I'm done with my coding bootcamp, what should I do next?"

The Day After

What should you do as soon as your coding bootcamp ends?

Don't Go On Vacation

The day after your training ends is not a good time for a vacation.

Your last day of bootcamp isn't really your last day. It's actually the beginning of a new journey.

Your final project is not the capstone you finished just in time for your big presentation. Your final project is getting a job.

Work on this new project with as much intensity as your final days of class.

A coding bootcamp doesn't get you there. It just points you in the right direction. It's a career accelerator. If you take time off to recover from your training, you'll lose momentum.

Get Your Tuition-Money's Worth

When a junior dev asks me for career advice, the first question I ask in return is usually "How are you taking advantage of the career services offered by your school?"

Use them all.

Set up career counseling meetings with their staff.
Ask them to review your résumé.
Schedule mock (practice) technical job interviews.
Attend events held in their space, including the graduation of subsequent classes.
Use all the resources they provide for local tech networking and job opportunities.

In particular, make sure your bootcamp does a good job "training employers".

Bootcamps should do more than attract applicants to the front door. They should also be growing and grooming a hiring partner network out back.

Your school should be preparing companies for talent like you by managing expectations and playing up their reputations. If you apply to a company that has never heard of coding bootcamps, or never heard of your program in particular, ask your school for help.

Do all these things even if your school doesn't have well-defined "career services". Push for it. You deserve to get your tuition money's worth.

Don't Spend So Much Time Reviewing The Basics

Many recent coding bootcamp graduates start their post-training lives with a review. Not having every lesson memorized stokes anxiety. So they delay the start of their new careers to return to lesson one.

Sometimes that's worthwhile. If you're suffering from imposter syndrome, it can be a confidence boost to go back to some early exercises from the course and realize how something that confounded you a few months ago now seems so trivial. All your tech problems haven't gone away, but at least they've changed - they're bigger and more complex now. You've made progress.

But don't linger on basic coding exercises. You don't need to master every lesson to get a job. You just need to know enough to build things.

Instead of returning to Codecademy lesson one, create something. You'll learn more from a good project than from a review of fundamentals. And projects look much better than "badges" on a résumé.

Don't Stop Coding

Many bootcamp grads stop coding after graduation.

Some dedicate all their time to the job search, but none to honing their craft.

Some, after a long unsuccessful job search, lose hope and stop everything.

Some, even after successfully landing a job, find themselves in a role that appreciates technical knowledge, but doesn't require writing code.

Some alumni, both successful and not, attempt to return to coding weeks or even months after graduation, only to find their dev environments aren't working anymore.

Don't be like those people. Don't stop coding after graduation.

Make A Plan To Code

The most successful graduates treat their post-bootcamp time with just as much discipline and seriousness as the course itself.

Like the bootcamp did for you during the course, set up a daily schedule. Show up on time, not for class, but for yourself. Make a plan. Block out the entire day.

Many people attend in-person bootcamps because they lack this kind of discipline. Otherwise they would have opted for a cheaper, fully-online, self-paced course. If you're one of those people that can't get moving without an agenda, here are some tips.

Start with something simple, like making at least one public Git commit or pull request every day.

Try publishing one short blog about a technical topic every few days.

Then, over time, make your agenda more complex.

For example, at the beginning of every week, find a list of local companies you'd like to work for. Figure out the skills they need from their job listings. Then, for the duration of that week, target your post-bootcamp training on those items. Did your bootcamp teach JavaScript, but there's a local company you like hiring for C#? Then spend a few days getting familiar with that tech landscape. Tap into your alumni network for support.

A coding career is like a video game. The early levels that seemed so difficult are a piece-of-cake now. But there are many harder levels coming up.

Like many games, the secret is to be leveling up daily. Every line of code you write is another experience point. And every point you earn gets you closer to the next level of your career.

ABC - always be coding

Finish Your Homework

You may not have done your best work during bootcamp. Maybe you passed the course, but you skipped a few projects or assignments. Right after graduation is a good time to finish your homework.

Employers may call your school for a reference. They may ask how well you did in the program. A good way for a busy teaching team to jog their memories is by looking up your scores. Leave a good impression in the gradebook.

Build Projects, Not Badges

Everything feels rushed during a coding bootcamp. That's the point of rapid skills training.

Unfortunately, students feel like there's never enough time to work on their pet projects.

Weirdly, after bootcamp ends, students rarely return to those same projects. Many startup MVPs are sitting open-sourced in the GitHub repos of coding school alumni.

Right after graduation, but before the crunch of a new job, is the perfect time for highly effective project-based learning. Your old code doesn't yet feel like a distant memory and you finally have time to fix those rough spots you had to plaster over for your final presentation. You can even create a prototype of that startup you were envisioning before you started the course.

Instead, students find any excuse never to return to the hackathon-quality code they rushed out for their demo day. They'll spend all their time applying to jobs. Or they'll try to earn as many online training "badges" as they can.

But, as a junior dev, nothing shows off your skills better than a good portfolio of projects. You'll learn more, and more quickly, from projects than from re-watching old lectures.

If you can't think of something to build, here are some project ideas you can use for inspiration.

Polish Your Old Projects

Improve the final project you worked on for your demo day. You can also return to earlier projects from mid-course and make them portfolio-worthy - or, if it's not worth the effort, delete them from your GitHub.

Make your projects unique. Everyone in your class probably built the same stuff. Add something that makes your app stand out from your peers.

Employer-Inspired Projects

Find the skills employers want, then build something using those skills.

Try to re-build an employer's product. For example, if you're interested in working for a health IT company, built a doctor's appointment scheduling app or a prescription drug tracker.

If you're interested in design, mockup a new homepage for an employer's site or a landing page for one of their new products.

If you're interested in devops, try to launch a basic site on the company's preferred cloud provider.

Not only does this kind of work demonstrate a passion for your target company's niche, but it also makes you appear like a potential competitor - one that an employer would rather have working for them than against.

Freelancing

Freelancing is intimidating for junior devs. Imposter syndrome kicks into high gear when money is on the table. I just (barely) learned how to do this! How can I justify charging people money for it?

Just like that grade school myth, juniors tend to think there's a "permanent record" that'll be marked in bright red if they fail to deliver on a freelancing gig. Your career could be over as soon as it starts.

Instead, new bootcamp graduates should consider freelancing another step in their educations. This time, however, instead of paying to learn, you're getting paid to pick up new skills.

It's not going to pay much. Often junior devs agree to fixed-price projects that, given the number of hours and inevitable scope creep, turn into effectively less-than-minimum-wage gigs. But that's ok for your first time. And it's not forever. And, even if it turns out badly, you'll still have learned something.

Also, though this may sound hard to believe, there are plenty of low-skilled coding opportunities available - usually the kinds of things professional freelancers wouldn't consider worth their time. A little HTML/CSS can go a long way, though not usually very profitably.

And don't forget you're not alone. If you get stuck on a freelance project, reach out to your alumni community. You may be surprised to discover how many Wordpress admins there are in your web-dev course's alumni base.

Code for America

There may be a Code for America chapter in your city. If there is, and it's anything like the one in Miami, there are probably a bunch of open-source projects for you to work on.

Well-meaning devs start-and-never-finish public service apps all the time. It's volunteer work, so life (e.g. paying rent) sometimes gets in the way. Nonetheless, it's still a great place to gain experience with gracious local government agencies and non-profits.

If you're lucky, your project may even get press and attract the attention of an employer.

Hackathons

A hackathon is a time-limited competition, usually in-person (sometimes virtual), that takes place over a weekend (sometimes longer), where teams come together to quickly build apps on a particular theme or using a particular technology.

Some participate to win. If you find yourself on a good team, cash and prizes await.

Junior devs should be using hackathons to learn. Many companies use hackathons to introduce or promote their products, so use it as an opportunity to take a guided crash course in some tech and possibly create a project to add to your portfolio. Some hackathon winners even go on to form startups.

More importantly, hackathons provide an opportunity for hours of networking with both highly-skilled local talent and sponsoring companies - sponsorships that are typically motivated by recruiting.

Clean Up Your GitHub

As you work on these projects, keep your GitHub profile clean. Your
GitHub project portfolio may be more important than your résumé. Specifically, remove any half-done app repos and unnecessary forks. Make sure the projects you keep have good READMEs describing what the code does and how to use it, particularly to a relatively non-technical audience (e.g. someone in HR at a tech company or a technical recruiter).

The Job Search

You Don't Have To Know Everything To Apply

Despite the flood of junior devs into the market, coding remains a niche skill. Few people know how to do it. Some of what you've learned to do seems like magic to other people.

Companies hiring devs aren't necessarily techy themselves. You may not know much, but you don't have to know everything to apply to a job. You just have to know more than the person on the other side of the interview table.

You've essentially learned how to take information you found online, usually for free, and sell it to people. Use that grift to your advantage.

You may not know the answer to every interview question. That's ok! Knowing the answer isn't what marks your progress. It's knowing how to find the answer that makes the difference.

Your pre-code-school self didn't understand what the questions meant - tech jargon is a foreign language to non-coders. The you-of-a-few-months-ago wouldn't even know where to begin to search for answers or even recognize the answer when you found it.

You don't have all the fish. But you know how to fish. You know where StackOverflow is and what it does. Most people don't.

No matter your seniority level, there will always be things you don't know. Not knowing the answer isn't your bootcamp's fault. Not knowing how to find the answer is.

The Product Of You

Searching for a job is similar to building a startup. Find a problem a company has, then turn yourself into the solution.

You might have to do this a few times until you find your place in the tech ecosystem. You may make a few skill-set pivots before the product of you is validated.

But that's ok. Every new line of code you write still counts, even if you don't use all those skills in your next job.

Discover For Yourself

There are companies hiring coders who have never heard of coding bootcamps. Of the companies in-the-know, some don't recognize your particular school.

Your city's entire tech scene didn't attend your demo day. The few that did don't represent your entire local tech ecosystem. Don't expect them to notify other companies about your awesome presentation.

Your school isn't going to hand you a list of every potential employer in your city at graduation. They may not even be able to. The companies that need your skills may not be on anyone's radar yet.

Get out there and find them.

Is that a... job?

Check The Local Tech News

Around a decade ago I learned about a company that had just won some local tech business award. They weren't well known. They didn't even have any open positions posted. But I introduced myself anyway. And I got that job.

Companies make news because they want attention, both from investors and talent. Check your local tech news daily to find companies that may be open to considering you.

Focus on businesses that have just raised funding. Investment doesn't go to companies that just want to sustain. It goes to ventures that want to grow, which usually includes growing a team.

Network Like A Stalker

Your local tech scene may seem intimidating and unwelcoming to newcomers. There are many events on Meetup and Eventbrite, but you may not be familiar with all the tech jargon in the descriptions.

Find the courage to attend anyway. Go with a group of your fellow classmates if necessary. Because being on the guest list has advantages.

You may be granted access to the other names on the attendee list. Scan it for interesting people, both before and after the event. Add them to your target list.

Focus on meeting people who work at the companies you're interested in.

Then stalk your prey, which I mean in the nicest possible way!

Specifically, every time one of your targets attends a networking event, try to be there, find them, and say "hello".

Connect with them on LinkedIn, Twitter, and Facebook. Join every meetup that they've joined. Monitor event attendee lists. Then keep showing up, over and over.

What a coincidence bumping into you again!

If you've already applied for a job at that company, make it impossible for them to ghost your application.

Make them want you on their team even if they can't yet think of a role for you yet. Be persistent.

Just don't be creepy about it. Don't show up at someone's wedding uninvited. Keep to networking events and respect boundaries.

Steal Someone Else's Job

The tech job meant for you might not look like what you expect.

There are people who get paid to enter data into forms and spreadsheets all day - the copy-pasters. Some people get paid to communicate - make phone calls, write emails and text messages, schedule appointments, etc.

There are many jobs that can be made easier, even obsolete, with the right app, especially if you have the skills to use and customize the software.

Steal those jobs, build those apps (or discover them online), and replace those people.

When you're done, refer your newly unemployed former coworkers to your coding program to be trained for the new tech economy.

Take The Interview

Just take the interview.

You'll never know everything a company wants. Companies understand there's no such thing as a "perfect candidate".

Instead be a "perfecting candidate". If an employer wants you to learn something new, create a training plan for yourself. Make a list of all the resources you'll use to ramp up, both before and on-the-job. Include not only online training courses, but also people or Slack communities you'll reach out to for help, including your school's alumni.

Just take the interview.

Take it, not because you're ready, but because it shows respect. The people who work at companies are human. They can get hurt feelings if you turn down an interview request because you're "not ready yet". And making a company feel bad is a quick path to rejection.

Just take the interview.

Take it even if you don't want the job. Make it an informational interview. Find out what skills they're looking for and learn about the company culture. Add your name to the applicant pool. A quick introduction will give you an advantage if you later change your mind.

Just take the interview.

The worst that can happen is you don't get a job you want. But the interview experience is still valuable.

Find out why the company didn't select you. Or ask someone who works there, staff from your school, or an alum to find out for you.

Then focus your learning on those missing skills to improve your chances for the next opportunity.

Don't Gripe About Your Bootcamp In Interviews

Given the tremendous growth in the tech-education industry, bad bootcamps are to be expected. They all get bad reviews, but some get more than others.

However, saying "My school sucks, but I'm still a good hire" is not a winning interview strategy.

I'm not saying don't write a bad review or share your story with other prospective applicants. Please continue to do that. It helps.

I'm saying that a job interview isn't the place to vent your frustrations about your training.

First, complaining about your training is similar to complaining about previous employers. If you're hired and later leave, the company may assume you'll complain about them at your next gig. That underlying "bad feeling about this" can be enough to bomb your hiring chances.

Second, you're hurting your classmates. A school's reputation is built on its alumni. Coding bootcamps don't produce curriculum. They produce junior devs. You are the product. What you do reflects on the entire program.

By complaining about your bootcamp in an interview, you're hurting the school's reputation and, more importantly, hurting the employment prospects of any classmates who don't share your opinion.

Instead, if you found your training lacking in some way, talk positively about all the things you did to make up for it. It's ok to sell yourself as a better candidate than your classmates. It's not ok to sell yourself as better than the school itself.

Don't Run Away From Your Past

Unlike college, most coding bootcamp students don't attend straight from high school. Many are career-switchers. Some may even have a prior non-technical degree.

But even if your old job was working retail or bussing tables, don't run away from your past. Career-switching coders are good because of where they came from, not in spite of it.

Don't hide your old career. Those skills still count - they may be transferable.

Specialized coders are valuable. There are lots of med-tech companies who want to hire former pharmacists or medical billing specialists. Restaurant and hospitality-tech may appreciate a former cook or waiter who now knows how to code. Pitch yourself as a combination of your old life with your new skills.

Take The Job

The phrase "unemployed coder" is an oxymoron. If you can code, there should be a job out there for you.

But "underemployed coder" is quite common. There might not be a full-time position open for you at this time.

However, there are many small gigs available. There's always someone willing to pay you to make things happen on the magic mystery machine.

That's not to say full-time is necessarily better than freelancing. There are plenty of crappy FT jobs too.

But there are no "dead end" coding jobs. Because, as a junior, every line of code you write levels you up. Even the worse junior dev gig is still getting paid to learn, which is a step up from paying to learn at a bootcamp. And that learning, even in poor circumstances, opens up new opportunities.

So take whatever job you can find and start building experience.

What if I don't like any of the jobs I'm being offered?

A bad job isn't a life sentence. You can leave whenever you want. And, if the environment is toxic, you should ASAP.

But if you're just mildly unhappy with your new role, keep at it, while continuing to search for a new gig on your off time. Keep looking for something better even if you've just accepted the offer.

I've heard from many new devs who balk at the idea of leaving a job too soon after starting. They feel disloyal - like it'll appear on their "permanent record". Or like they're cheating on a spouse. So they "stick it out" way past a job's natural expiration date.

But a job isn't a marriage. You really can leave whenever you want for almost any reason.

So, if it's not too much trouble, keep at it. If you don't enjoy the job, it'll only take a few months of experience to unlock better opportunities.

Ignore Job Titles

In the future, the way we talk about coding will sound weird. It'll be an assumed part of basic literacy.

For example, saying "I learned how to code! Now I want a job as a coder." is going to sound like "I learned how to write! Now I want a job as a writer." Almost every job requires some writing skill, regardless of whether the word "writer" appears in your job title.

We've already seen it happen with basic computer skills. Even auto mechanics use a computer to order parts these days.

We're beginning to see it happen with coding skills. Many administrative jobs now have a "Nice to Have" section for things like basic web design skills, HTML/CSS, or even WordPress.

You may officially be called an "office administrator" or work in marketing or sales. But being able to, for example, keep the company's website up-to-date gives you an advantage. You're more productive than the coding illiterate masses.

Someday those "nice to have"s will turn into requirements. Later they'll just be assumed of any computer-literate applicant.

You're ready for that future now. Don't be afraid to take those jobs. As long as you're coding, even just a little, you're improving, even if your job title doesn't contain the words "coder", "developer", or "engineer".

Don't Call Yourself Junior

A few months (even years) into a job many alums still refer to themselves as "junior". Stop doing that. Just tell potential employers your experience and let them decide where you stand at the company.

Managing Imposter Syndrome

Imposter syndrome is real. Everyone has it, even senior devs. But for newly-minted coders, it's particularly acute. You'll feel, even after finishing the course, what the critics have always argued about coding bootcamps: that a few months (or however long your course was) isn't enough to prepare you for a job.

But don't let feeling like a phony get in the way of your career. Confidence, particularly during an interview, can make a difference.

You may not think you're ready, but you're better than you think you are. Here are some tips to help you overcome imposter syndrome.

You're The Best Class Ever

If your school is doing its job, the most recent graduating class should be the best one ever.

First, you should have the largest alumni network of any prior graduating class. That network should include people with influence on hiring decisions who will vouch for you.

Your network should also be well-known. Potential employers should understand that, by hiring you, they're also hiring the alumni who support you. You should never feel stuck or alone on the job.

Second, you should be the best-trained class ever. Good coding bootcamps improve the curriculum between every cohort. You should have learned topics that previous alumni were never exposed to. That gives you an advantage.

Don't Worry About The Skills You Don't Have

Computers aren't magic. They are simple machines that go very fast.

You know how to use the hammer. Don't worry so much about whether the hammer is metal or wooden, long or short, heavy or light.

If you've learned, for example, Ruby, it's actually not a big leap to switch to Python, .NET, or Java. Many languages look the same (i.e. almost all of them look like C).

Once you've got some programming fundamentals down, you can figure out the rest as you go.

Talk To People Outside The Tech Bubble

If you ever need a confidence boost, try talking to some of your non-tech friends and family about what you've learned. If they stare at you like you're speaking a foreign language, then you must have learned something.

Then imagine competing against those people for a tech job. (Because, sometimes, that's actually what's happening).

Don't Let The Haters Discourage You

People are going to stand in the way of your new career.

Devs with multi-year CS degrees may be jealous you got a job after a few months of training.

Employers may take advantage of you during salary negotiations because you're new to the industry.

Devs who use other technologies are going to disrespect the tech stack you learned.

Haters gonna hate. Don't let them win. They're all just trying to overcome their own imposter syndromes. They're pushing you down to lift themselves up.

Imposter Syndrome Will Not Be Defeated

No amount of advice can conquer imposter syndrome. Even if you power through all your anxiety to successfully land a job, you'll still live in fear of being fired every day - as if, at any moment, they'll discover your "true identity".

So my last bit of advice is based on my anecdotal experience with alumni who have been let go from companies. Usually, they don't get fired because they can't code.

Companies understand they have to invest time in juniors to ramp them up. What they don't like to see is when a new hire stops caring - when they get so frustrated that they stop asking for help and quit improving themselves. That's the most efficient path to the exit.

Since imposter syndrome can't be defeated, you have to fight it every day. You fight it by continuously and incrementally improving yourself, whether it's through online learning or simply asking for support from your teammates or community.

Imposter Syndrome Honorable Mentions

The coding bootcamp you just finished isn't the end. Don't think of it as a goodbye. Think of it as an orientation for the rest of your career.

Good luck!

Teaching Functional Programming: Two Big Picture Approaches

Ed Toro — Tue, 06 Nov 2018 19:09:14 +0000

Functional Programming (FP) has been around just as long, if not longer than, Object-Oriented Programming (OOP). But it's only (relatively) recently gaining in popularity, particularly in the JavaScript community. Why?

I went to MIT in the early 00's. Structure and Interpretation of Computer Programs (SICP - sick-pee) was my textbook. So my first formally-taught programming language was functional. Then I worked in industry for over a decade and hardly ever thought about FP. Now I'm shocked to learn that the textbook from college I don't remember very well anymore is considered the "functional programming bible".

Don't get me wrong. It's a good textbook. I'm sure it made me a better programmer. But FP wasn't something I applied very often in my Java/ActionScript/PHP/Python/Ruby/JavaScript career. OOP patterns dominated.

Then I taught at Wyncode Academy for four years and found myself trying to explain some FP concepts to newcomers. In a world dominated by OOP, it's hard to explain FP. It's so different.

After learning OOP, why is FP so much harder?

Related questions: Why has it taken so long for FP to catch on? Why aren't I talking about techniques for learning OOP in an FP-dominated world?

We in the coding community need to grapple with why the OOP->FP transition is so hard to teach. Evangelizing FP like a religion repeats the same mistakes that caused FP to languish in the industry for so long.

Many introductions to FP are missing something. It's not just an alternative programming style. It's a new way of thinking. When introducing something big and new to my students, I try to ease them into it. These same tricks may also work with more experienced programmers from OOP backgrounds.

One of the techniques I used at Wyncode to get a running start into a hard concept is storytelling. If I can get my students to understand the context - the big picture - I find it easier to later explain the technical details.

So here are two big-picture strategies for introducing FP - particularly to an OOP audience.

Big Picture 1: History

Sometimes it's good to start from the beginning: How does a computer work?

The most common (popular? easy-to-understand?) model of computing is the Turing Machine. The state that FP programmers complain about is staring us right in the face in a Turing Machine. An algorithm for operating this machine represents transitions between different states, e.g. from some boxes being on/off (1 or 0) to some other boxes being on/off.

If we try to imagine two Turing Machines operating on the same section of tape at the same time, we can begin to understand why "shared state" and concurrency in OOP are hard problems. But that's a post for another time.

The Turing Machine is a universal machine. It can be used to solve every solvable (effectively calculable) math and logic problem. This simple collection of operations - move left, move right, write a dot, read a dot, erase a dot - are enough (given enough time and resources) to tackle every math problem in the universe. That's what Alan Turing proved in 1936.

In many ways, a Turing Machine is how a computer "works".

But this is also how a computer works.

A full adder circuit

This is a circuit for addition. It's the kind of component found inside the CPU of a computer.

This is not a Turing Machine. It's not universal. It's just addition. It can't (easily) be "reprogrammed".

There's also no Turing-machine-like "state". Apply voltage to the inputs corresponding to the numbers-to-add and detect voltages in the outputs corresponding to the sum. As soon as the voltage is shut off, the answer goes away. There's no "tape" sitting around to read or manipulate. Two circuits can't operate on the same logic gates simultaneously. (I don't think they can, but I'm sure someone will comment to prove me wrong.)

This circuit is also fast. While a classic Turing Machine flips 1s and 0s back-and-forth on some medium, this circuit operates at the speed of electricity through a wire. There are no moving parts.

A circuit is a different model of computation. Each of the logic gates (AND, OR, NAND, NOR, XOR, etc.) are pure functions. They accept inputs and produce outputs with no side-effects. If all we have is the ability to create and combine these "functions", we can also solve every solvable math problem in the universe. That's what Alonzo Church proved, also in 1936.

So we've got two different models of computing: the Turing Machine's little boxes of 0s and 1s (objects) and Alonzo's Church's lambda calculus built out of logic gates (functions). Which one is correct?

For a time there was a debate about whether an abstract Turing Machine could solve the same set of math problems as lambda calculus (and vice versa). Eventually they were proven to be equivalent.

Being equivalent means that they're equally powerful. Any algorithm that can be written for a Turing Machine can also be written using functions. So any program that can be written in Turing Machine software can also be represented in circuitry hardware.

What does it mean to "program in hardware"?

We can see "hardware programming" embodied in Application-specific Integrated Circuits (ASICs). Circuits can be created that are "programmed" to do one thing very quickly, like mine Bitcoin or play chess.

Since the proposal of the Church-Turing Thesis, we've had two programming options. Hardware is faster and software is slower. Make a mistake in software? Just hit the delete key and try again. Make a mistake in hardware? It's time to grab a soldering iron. It's a classic engineering design trade-off.

So let's say we have an algorithm written in an OOP style that we'd like to convert into an ASIC. It's probably a good strategy to rewrite the program in a FP style so it better maps to the circuit diagram's domain. Most programming languages are flexible enough to do that, but some are better at it others.

# Elixir pipes
"1" |> String.to_integer() |> Kernel.*(2) # returns 2

Many FP-oriented languages tend to look like circuits. Specifically the "pipe operators" in Unix, Elixir, F#, JavaScript (maybe someday) and others make code look like a circuit diagram: inputs go into the left, flow through a number of "gates" (pipes) until they're transformed into the final output on the right. It's probably not a coincidence that the pipe operator used by some languages (|>) looks like a logic gate.

The NOT gate

Putting my coding instructor hat back on, a good "big picture" way of introducing FP is to start by talking about how circuits work, how they can be "programmed", and how we can model circuit diagrams in code.

Big Picture 2: Philosophy

I picked up a Philosophy minor with my CS degree, so one of the things I'm fascinated by is the intersection between those two fields of study. I find talking about the overlap helpful when teaching new coders, particularly those with Humanities instead of STEM backgrounds.

A philosophically important concept in FP is "functional equivalence".

Perhaps the best example demonstrating this equivalence is Tom Stuart's great article "Programming From Nothing".

Stuart demonstrates how a program (specifically the ubiquitous FizzBuzz) can be written entirely out of functions. I'm not going to repeat that entire exercise here, but I am going to borrow his explanation of how numbers can be represented entirely with functions (the Church encoding).

Start by defining the concept of zero as a function that accepts a function argument and does nothing with it.

# Ruby
ZERO = -> (func) { 
  # does nothing
  func
}

Similarly, we can define all the natural numbers as functions that accept function arguments and call them n-times.

ONE = -> (func) {
  # calls it once
  # same as "func.call()"
  func[]
  func
}

TWO = -> (func) {
  # calls it twice
  func[]
  func[]
  func
}

To test these "function-numbers", pass them a test function.

HELLO = ->() { puts "hello" }

# same as "ZERO.call(HELLO)"
ZERO[HELLO] # nothing displayed
ONE[HELLO]  # one "hello" displayed
TWO[HELLO]  # "hello" twice

This functional-numeric representation can be hard to play around with and debug.

p ZERO
# outputs #<Proc:0x000055d195ae57b0@(repl):3 (lambda)>

So to make it easier to work with we can define a method that will convert these functional-numbers into the object-numbers we're used to.

# convert number function into number object
def to_integer(func)
  # count how many times counter is called
  n = 0
  counter = ->() { n += 1 }
  func[counter]
  n
end

p to_integer(ZERO) # 0
p to_integer(ONE)  # 1
p to_integer(TWO)  # 2

This converter creates a counting function and passes it to the numeric function. The ZERO function will call it zero times, the ONE function will call it one time, etc. We keep track of how many times the counter has been called to get the result.

Given these function-number definitions, we can implement addition.

ADD = -> (func1, func2) {
  -> (f) { func1[func2[f]] }
}

sum = ADD[ZERO, ZERO]
p to_integer(sum) # 0

sum = ADD[ZERO, ONE]
p to_integer(sum) # 1

sum = ADD[ONE, ONE]
p to_integer(sum) # 2

If TWO calls a function twice, then ADD[TWO, TWO] will return a function-number that calls its argument four times (the function-number FOUR).

It's a mind-bending exercise. When I get to the end of "Programming From Nothing", I get the sense that this is an interesting product of the clever application of a fundamental computer science concept, but not something I could use in my day job.

And that's exactly the sense that I (and I suspect many others) have about FP in general - it's clever, but doesn't seem very useful. That feeling of unnecessary complexity is exactly the problem we need to solve if we hope to make FP techniques more popular.

So a better place to start teaching FP than Church numerals is The Matrix.

In that 1999 sci-fi film, the reality perceived by most humans is actually a simulation called "The Matrix". A few months ago Elon Musk suggested that this "simulation hypothesis" may be real, starting weeks of "Philosophy 101"-level media on the topic.

What does The Matrix have to do with FP?

The metaphysical debate, of which the "simulation hypothesis" is but one response, is very old and mind-numbingly complicated at times. So my attempt to summarize it won't do it justice. But the big idea is that we have no proof that the world around us is real. Maybe there are actual objects in the world or maybe we're just brains in jars.

So there are at least two contradictory theories of what, for example, the number one is. Is it a thing (a noun, an object) that we can interact with (touch and feel)? Or is it an action (a verb, a function), something that acts on the world, but isn't embodied?

The functional-one is a simulation of the number one. It's functionally equivalent to the object-one, meaning it does everything the object-one can do. For example, we can do arithmetic with it.

But it's not really "there" in the way that objects in OOP are "there". It's a Matrix simulation. It doesn't have inherent attributes - it isn't x, it just does x.

To pick a less abstract example, is the chair you're sitting in real or just forces pressing against your body? A "chair" may be a chair-object that exists in the real world or a chair-function: a (hopefully comfortable) force pushing against you with no underlying objective basis.

A red delicious apple

Consider color. Is a red delicious apple really red (adjective describing a noun) or does it act red (verb)? Is color an inherent attribute of a real underlying apple-object or just an action that an apple-function is programmed to do when light shines on it? Is the apple real or just a simulation?

# A "real" apple
class Apple
  attr_reader :color
  def initialize
    @color = "ruby red"
  end
end

p Apple.new.color # "ruby red"

# A "simulated" apple
APPLE = -> (applied) {
  return "ruby red" if applied == "light"
}

p APPLE["light"] # "ruby red"

The difficulty of this philosophical concept is a good metaphor for why FP is so hard to teach in an OOP-dominated world. To help students understand, start by opening up their minds to the possibility of a world made up solely of "functions". Start with that big picture concept, then transition towards FP models of the world: how they differ from OOP representations yet maintain equivalent results. Ask an experienced OOP developer to consider rewriting a class into its functional equivalent.

Conclusion

Transitioning from OOP into FP can be hard. It's not just a different programming style. It's an alternative model of the world. And the better we are at easing students into that paradigm shift, the easier it'll be to avoid another half-century of ignoring this useful tool in the coder's toolbox.

Edits
Writing is just as debuggable as code. So I've decided to clarify that I'm presenting teaching strategies for introducing FP to OOP-minded programmers. FP programming itself isn't hard. It's the paradigm shift that needs support.