By Jenn Schiffer

April 17, 2017

Learning About Learning About What We Want to Be Learning

As an educator, engineer, and follower of many of the same kinds of people, I am hyper-aware of how learning to code is a struggle for the whole spectrum of experience of developers in the field, myself especially! We all have our own ways of combatting or succumbing to impostor syndrome, but at the end of the day we work in a very demanding industry that requires constant learning and evolving. Where does one start?

Image

Those of us who have been programming for years like to reminisce about when building the Web meant blog themes and static sites in hilariously unpredictable web editors. Today, it feels like we spend 90% of our time setting up developer workflow and deployment processes, leaving 10% to actually programming an app while learning what the heck we just set up. And somehow we are expected to all learn the same way!

I, personally, am a visual learner who is not very good at “reading the manual.” Other great developers I know cannot follow online videos or conference talks, but they can read all the docs! We have very different styles of learning, but online we have created this perception of the “JavaScript Rockstar™” who very few, if any, folks can fit into perfectly. I think that one way of combatting this fake idea is by having open conversations about how we learn, what we want to learn, and what is keeping us from learning.

On Glitch.com, we have a variety of apps built by and for the community to get started with different technologies — Twitter bots, Alexa skills, Mocha unit testing, Grunt task management, HTML5, and so much more — but there are* so many things *that are missing. I want to build more and have others build more, but I also want to make sure we’re providing services people actually want and need, so the week before last I went on Twitter and asked what you wanted to learn.

I was floored by the candid responses from all walks of developer life — beginners, language experts, library authors, “buy more twitter follower” bots — and I think we all learned a little more about ourselves and how we perceive how others learn. I know I did.

In no particular order, here is the list of libraries, frameworks, APIS, etc., which people said they wanted to learn but weren’t sure where to start:

A couple of folks responded to my question wondering why anyone needs to learn any of those things. Of course, the general discussion at no point said “you must learn this thing” but sometimes our anxieties from the fast-paced always-learning dev scene causes folks to project onto others those anxieties in argumentative ways. This, naturally makes it hard to have an open, candid conversation — many of the above responses came to me via direct message — so it is clear that the learning problem is a culture problem.

Besides culture-incubated insecurities, the biggest reason folks gave is that they don’t really have a purpose for it — or at least that purpose hasn’t been articulated to us in a way to sell us on the technology.

New tools can be extremely daunting, especially when they are a different paradigm than we are used to. In the past, I’ve wanted to get more involved in functional programming but have been concerned about the rhetoric of some of its more vocal community members. I’m not the only one.

I see this barrier lowering a bit for JavaScript developers with languages like Elm — a functional language that compiles to JavaScript — and it seems like many of you are curious and excited about it too.

So it seems like these barriers are 1. needing to know why one would use a thing and 2. discovering if one can learn a tool without being shut down or turned off by the community behind it.

**I mean, we can all stand to be a little bit nicer, right? **It’s very clear that even the creators of the libraries we are intimidated by experience their own anxieties about learning and also teaching folks how to use their tools.

Another thing we should do is have conversations about why one should be learning different web technologies, beyond them being “cool” or popular. Let’s be completely honest here — there is nothing inherently cool about a JavaScript library, framework, interop, or whatever. At the end of the day, we should be using the languages and tools that best serve us when we need them.

As it’s impossible to know everything — I’m so sorry to break this to you — I think it’s very important for those who are authoring web development tools to give discrete examples and scenarios. In my past life as a web app consultant, I’ve found that creating user personas has helped me focus my empathy towards my users. It turns out that design processes also work great for documentation and marketing! If I can’t put myself in my users shoes, how am I supposed to make a connection that gets them to use my product?

And of course, you want real-world useful examples of your tools in action. We at Fog Creek have been super stoked to see all of the great “Hello World” apps coming from the community, which many folks have been remixing to make their own amazing creations.

Image

If you’re the author of a JavaScript library or framework, Glitch is the perfect platform for you to show off your examples and demos in action. And the people you want to use it can just remix them and not have to worry about dev-ops or environment workflow or processes — it just works and it’s their own copy. The only thing you need to do is tell a story as to why they would want to try it!

We love to see what you all make, and we are always looking to populate our community site with all of your cool dynamic apps and static pages. If you make something cool and want us to show it off — or you yourself are wondering *why *and *how *to use Glitch — let us know by tweeting @glitch or you can email me at [email protected]!