If Scratch Isn’t the Answer, I Think I Know What Is

June 20, 2017 at 5:01 pm in Personal

(Originally posted over at Medium)

In this post, the author, Dominic Pace, argues that we should teach “actual programming” instead of Scratch. I encourage you to read that first because it makes some great points. It’s written by a high school senior who’s hit upon something important: “Learn to code” tools like Scratch and Alice really are somewhat disconnected from software development. They do help with problem-solving, and they do help students work with the very basics of software development, but they create an unrealistic expectation of how we really build software.

This is a problem I’ve been thinking about for a long time. I’d like to propose a solution that’s worked for me and my students.

I spent a few years teaching beginners to code full-time, and the biggest thing I learned about teaching people a new skill is that it’s all about motivation and connections to familiar things. The learners are eager to create things similar to what they already love to use. They’re interested in coding because they know that’s how apps and games they use daily are made.

I can relate to this and I think a lot of people my age can too. When I was a kid, I played text adventure games. And my love for coding came from being able to make the same kinds of games I was playing. It was fantastic. I was even able to find books where I could just type the code and I had the game. Then I could learn from what others did and monkey with it.

This approach is how other disciplines have learned for centuries. Bach learned composition by transcribing music from other composers.

But times have changed. The steps to making a basic text adventure game pale in comparison to building a first person shooter or a mobile game. You have to know a lot more about programming to do either of those things.

This then becomes a motivation problem — telling someone who’s excited make mobile games to type a bunch of statements into a text editor and run or compile a program that prints console output is really only going to attract the nerdiest folks in the group. Most people don’t see the immediate connection, and even the best teachers struggle to make this kind of exercise interesting enough to motivate the students to do it again. And when the student discovers just how far they have to go before they’re building their own VR games, they’ll probably just give up. I’ve seen this a lot.

This is where Scratch comes in, right? It gives quick wins. It’s easy to make some fun 2D games with Scratch. A “magic 8-ball” in Scratch is a 5 minute project, and most of that is just making the graphics.

The problem is that Scratch and other tools abstract things too far away and then makes people really adverse to doing anything in a code editor. It feels like a step backwards to them. This is similar to some folks I’ve met who did Visual Basic programming for a while, liked it, then went to get CS degrees and found out they’d have to do Java and write the GUI in code using Swing.

Both of these approaches result in people losing interest in software development. But I think I’ve found that addresses both the “it’s real programming” and “it’s relatable”:

JavaScript and HTML in the browser.

The first exercise I have people do is navigate to a web page, and pop open the web console in the browser. Then we start tinkering with the DOM using code. It works because they all know what a web page is, they immediately feel empowered, it’s real programming, and they feel like they have superpowers. I’ve seen them show their friends and family the cool programming stuff they can do.

And they can do it right in a browser they already have, on the computer they already have. They don’t have to install tools, compilers, build systems, linters, or any of that stuff. They can start coding and get motivated to keep going.

Then I can gently nudge them, slowly, towards better practices.

“Oops, refreshing that page means you lost all your stuff. Programs are just files we write. Let’s write our program in a file and run it. We’ll just open it in the browser now. Look! It runs!”

I’ve gotten resistance to this idea from a few places.

First, there’s a segment of people in the industry who look down at web development because HTML and CSS isn’t “real” programming, and JavaScript is a awful language because “many reasons.” “Front end developer” has become the new “junior developer”.

That’s just silly. You’re reading this on a platform created by a bunch of talented professional developers, many of them quite well-versed in front-end development. And JavaScript might not be the best language, but a beginning programmer doesn’t run into the kinds of problems that JavaScript can cause them. Because you’re there to guide them.

There’s another segment of people in the industry who insist that programmers have to “eat their broccoli” and do the difficult, hard programming because “that’s how you learn real programming.”

This group is already opposed to Scratch — they’re in the “it’s not real programming” camp. And honestly, I think they’ve either forgotten what programming was like before they knew stuff. (I hope it’s not that they’re just not that interested in making programming accessible to a wider audience.)

Me? I want more people to program. We need more perspectives. We need more ideas. We need more fun.

So I used this approach in my classes. And it worked. I had a lot of new programmers who got hooked on building things in a browser. They found out how fun coding is. Many of them went on to do Java, C, PHP, Ruby, and even Elixir. They learned in the browser, but they learned transferable skills in a way that was motivating.

Don’t look too hard for the perfect way to teach programming to beginners; you might look right past the one in front of you.

What do you think? Share your thoughts!

1 comment

One Year at DigitalOcean

June 20, 2017 at 11:40 am in Personal

Today marks one year with DigitalOcean, and I couldn’t be happier. I’m so unbelievably lucky to get to do what I do there. I work on the DigitalOcean Tutorials collection, where I help community authors get their articles published. It’s the perfect job for me, as I get to draw from my software development and system administration backgrounds, as well as my writing, editing, and teaching experiences. Writing software is fun, but DigitalOcean gives me the opportunity to help others get better at what they do. I not only get to publish awesome tutorials that people know and love, but I also get to help authors develop their skills so they can be better communicators. I can see the impact I’m having in conversations at conferences, on Twitter, and with the authors themselves.

Flowers from DigitalOcean

DigitalOcean sent me anniversary flowers. Because that’s how they roll.

Here are just a few of the cool things I’ve published this year:

In addition to these articles, I’ve had the opportunity to work on a bunch of other side projects. I helped smooth some process things out, took a slight detour into doing some marketing work, learned a ton about SEO, and participated in a hackfest where I worked with four awesome developers to build something pretty cool.

The best thing about the job is the team I work with. The company is full of amazing and talented people, and the team I’m on is no exception. Everyone on our team has great ideas, is passionate about helping people learn, and is incredibly supportive. I’ve learned so much from my teammates this year and I’m incredibly grateful for their help. There are lots of places you can trade your skills for money. But not every place makes you excited to head to work every Monday.

I’m looking forward to the next year at DO. I’ve got some big plans for year two.

Oh… we’re hiring. If you are a system administrator or software developer with a passion for helping people level up, I’d like to work with you. We should have a talk if you feel you haver the right mix of technical skills, teaching experience, and can edit articles for structure, technical content, tone, and grammar. Here’s what we’re looking for:

No comments

Settling In at the New Gig

August 12, 2016 at 11:28 pm in Personal, Tech, Work

I’m nearly two months into my new job. For those of you that haven’t heard, I am a Technical Editor at DigitalOcean, a fantastic startup based in New York City. I work with a great team of people, and I help open-source enthusiasts share their knowledge through written tutorials. I’m responsible for taking their submitted tutorials and testing them out, looking for inaccuracies, security problems, or other issues a reader might encounter. As I work through them, I look for continuity problems, voice, tone, and style issues, and I often help them improve their writing skills.

This is an amazing opportunity for me because I get to teach people through writing, since our community site gets a ton of traffic, and I get to be part of an organization that has core values that directly align with mine. I also get to bring my experience in writing, editing, publication, and teaching to this organization.

Best of all, I get to work with some super smart and genuine people. There’s always someone around with a positive thing to say or knowledge to share. ?In previous places, I’ve always been fortunate enough to have that on my team, but it’s been rare to see that throughout the organization.

By the way, our team is hiring. Do you have strong system administration experience and love to help people improve their writing? Come work with me. ?And if that’s not for you, DigitalOcean has a few other opportunities as well.

This current opportunity isn’t a software development position.?But don’t worry…. I’ve found ways to continue doing software development.

1 comment

Moving On…

May 23, 2016 at 12:26 pm in Personal, Teaching, Work

I’’ve had an amazing time teaching aspiring software developers. Over the course of the last four years I’ve had the privilege of teaching over 400 students how to use Linux, how to build their first web sites, and how to write their first software applications. I’’ve met some truly incredible people and forged some great relationships which I hope continue on for many years. But today I turned in my letter of resignation and am looking forward to what lies ahead. I’ve accepted a job offer that was too amazing to pass up, but more on that later.

I’ve learned so much from this experience. I’ve learned how to teach a diverse group of people. I’ve become more comfortable than ever dealing with politics, time crunches, leadership changes, disgruntled customers, and of course, the fundamentals of computer programming. In order to teach those things well, I had to go back and relearn things myself. I now have big ideas about teaching software development to adults, and I hope to share those thoughts as time permits through various outlets.

I’’m leaving behind an incredibly talented and wonderful team. They’re among the best people I’ve ever known and they’re going to continue to do great work. I will miss them. I will miss the students as well. It’s incredibly rewarding to see someone transition from knowing nothing about programming to a professional software developer who can do great things for others and provide for their families. I have so many stories like that and am fortunate to have been a part of that journey for these four years. I am forever thankful for that.

But it’s time for a change. I’ll announce exactly what that change is when the time is right.

In the meantime, I’’m still hacking on Codecaster and working on a couple of other projects. And I’ll continue to find ways to help people get better at software development.


The Hogan Formula For Software Estimation

July 26, 2015 at 6:20 pm in Tech, Work

Measuring how long a software project will take is a futile endeavor. Unfortunately, people who hire software developers have a habit of asking for the impossible. Like when they want you to build a Facebook clone in 2 weeks for $200.

So to appease my clients and managers over the years, I developed a formula to somewhat accurately address the “how long will it take” question. And despite it being a bit tounge-in-cheek, it’s startlingly accurate when you sit down and think about it.

Here is the formula:

TimeToComplete = (bestGuess * 2) + 1 --> Shift to the next unit of time.

Here’s an example. Someone comes to me and wants me to build a 5 page web site for them. My immediate thought is that building 5 pages of HTML with a Bootstrap theme should take me about 6 hours. That’s based on my experience as a developer over the years. I know I’ll use a bunch of pre-existing things and I know my way around CSS and HTML.
So if I run that through my formula, here’s what I get:

(6 * 2) + 1 = 13 hours --> Shift to next unit of time = 13 days.

It’ll take 13 days to complete this project, according to this formula. Does that make sense? Let’s look.

Day 1: I meet with the client and gather some specific details about the project. It turns out that the client needs 6 pages, not 5, but one of them is a contact form. I’ll be writing a little PHP. Client insists they have all the copy already written for all the pages, and they have photographs. After the meeting, an emergency for another client comes up and I have to deal with that. I can’t spend any more time today working on this project because I’m burned out.

Day 2: I build a mockup of the homepage in HTML with Bootstrap. I then develop a couple additional options. I put a PDF together and I show it to the client by sending an email. I get no reply.

Day 3: I follow up with the client. No reply.

Day 4: It’s Saturday.

Day 5: It’s Sunday.

Day 6: I call the client, since email isn’t working. The client replies that they like the first mockup idea I sent, and wants to proceed with that. I ask for content for the “About” page. They tell me they’ll have their office person send it over. I build out the pages in the template they chose using mocked up content. Productive day.

Day 7: I push the work up to a staging server so the client can play with it. I still don’t have content. I send the URL to the client. They play with it but tell me it doesn’t work on their machine. I test the site in multiple browsers and everything looks fine I head to the client site to see what the issue is with the site. The site comes up fine. They were confused because the text “Lorem Ipsum” was displayed on the page instead of the text they wanted. I ask again about the copy they were going to send over, and they hand me hand-written notes, saying their office person was out of town this week.

Day 8: I key in the content, because I’m nice. I push up the new site. They send me over some photos which I need to adjust to fit. This takes most of the day, but the site is eventually deployed. I get on the phone and walk them through the contact form. They have changes.

Day 9: I’m unable to work on the site much due to other obligations. But I do fix the contact form and ask them to test it.

Day 10: The site is complete, but I’m waiting on final approval from the client. The person in charge has taken a long weekend.

Day 11: It’s Saturday again. But the client does approve the work, with a couple of minor changes. I state that I can make those changes on Monday and I can make it live on Monday.

Day 12: Sunday again.

Day 13: I work through the changes and get on the phone with the client, who says things look great. I put the site live and they use Dwolla to send over a payment. Done.

Does that sound like a realistic scenario?

The problem I’ve found is that developers only think in terms of code. So when you ask “How long will it take to get something done” they immediately drop into “How long would it take to code up an untested first version of something based on what I’ve done before?” As developers, we have to remember that software is 20% code and 80% people. People need time to think about things, they need time to review, and they need time to recover from mistakes or bad choices. We have to factor in vacations, distractions, and many many other things.

Developers love to be a hero with their estimations. I’ve done this. I’ve said “Oh yea that’ll be easy. I’ll just get that done in 10 minutes. And sure enough, two days later I’m still working on it.

Now, in the only-somewhat-fictional scenario I outlined, the client had all their ducks in a row. They paid on time. I didn’t have to work with the ISP to recover their web site password and login information. I didn’t have to deal with people who nitpicked every pixel of the design. All of those things factor in to how long it takes, and all of those have nothing to do with how fast you can write code.

You will have to provide time-based estimates to people who don’t understand software. Do right by them, and yourself, by doing whatever you can to be as honest as possible. Maybe my formula will help you make a more informed decision. Or maybe it can just be a joke between you and your team. Because when you’re talking about a project that would “only take six months” and you’re on year two.