Lowering the Barrier to Entry

Coding used to be something that was at the fingertips of anyone with a computer. These days it has become fairly complex. Even once initial learning hurdles are overcome hobbyist/casual developers face significant challenges due to resource constraints (e.g. time). I’ve created a bare bones proposal with three ways this barrier could be reduced thus allowing a larger number of individuals from more diverse backgrounds to contribute to the web in the form of content and applications.

Thoughts appreciated. :slight_smile:

I’m not convinced. Like you I learned to program on DOS with QBasic then Turbo Pascal etc. It was a few years before I got an internet connection and began with HTML and CSS and eventually JavaScript, all in Notepad. I’ve been through the text editor -> IDE -> text editor arc landing on VSCode for now. I wouldn’t recommend a complex IDE or GUI system to new programmers (learning logic, state etc. can be done with GUIs like Scratch as my kids are doing.) You want them to have the simplest input through the simplest function with the simplest output at first.

Python is pretty simple to Hello World (web) in with an index.html and python -m SimpleHTTPServer 8000. Then edit and refresh away.

You’re right though that the framework de jour, Node.JS, has a dizzying number of dependencies for even the most basic Hello World. I wouldn’t ask new programmers to start there though.

A new programmer has quite a range of tools and systems to help them learn. You can do everything online in your browser and never need to install a single dev dependency. macOS, Ubuntu, and Windows all come with the basics for local development and localhost:8000.

While Stackoverflow has a newbie problem it is still loaded with existing answers to common questions new programmers will have. It’s a much better resource than what you and I had when we were starting out.

Possibly the area to improve on is expectations. Do we expect new programmers to have created complex SPA web apps in their first weeks or months? It seems like many coding courses end up with that expectation. Pumping out “React Ready Juniors”. Or now they expect to have a RNN after a week’s coding.

Learning takes time, learning requires dead ends and butting heads against brick walls, learning to be OK with frustrating situations and learning to debug your way out of it.

1 Like

Thanks for taking the time to comment Paul!

I agree that it is fairly simple to get started (in some languages) with basic development. I’ve refined the vocabulary I use in my proposal to emphasize “productive development” as opposed to introductory.

Folks can get through the basic concepts, create small hello world apps, etc. – but there is a significant jump from this to applications they would be eager to distribute to others and which could find some measure of popularity.

I’m also thinking particularly of individuals who either (a) haven’t decided to become full-time developers (yet) or (b) see development as a hobby rather than their main vocation.

I agree that expectations for new full-time developers can be too high…most job descriptions seem to describe super heroes rather than real humans when it comes to the scope of skills “required” for developer positions.

And I do think there is value in facing dead ends, bricks walls, etc. and learning to cope with them…but I also think that if people encounter too many dead ends or run into too many brick walls they may give up rather than learn perseverance. :slight_smile:

1 Like

Agreed the step from Hello World to Hello Customer is harder now if you stay at the code level. Perversely you can more easily get a working, buyable bit of software distributed with non-code than with code. It’s also a problem that once you need to do something your no-code framework doesn’t allow it is harder than having started with code.

I think there are some interesting attempts to get there at the code level though. JAMstack with “zero config” like Parcel or hosting like ZEIT Now.

There’s just a lot of noise around the right path to take and it’s very easy to find incompatibilities with one small variation e.g. I lost a few hours last week getting a Webpack config in TypeScript only to find out many packages I needed didn’t have good-enough TypeScript support. So I reverted back to ES6 Webpack config. There was no one place I could have learned that from, it took many Stackoverflow posts, blog posts, and cobbling it together.

Can this step from Hello World to Hello Customer be automated though? Is any system going to be better than pairing with an experienced developer who has been through it?

To the point of your other post there could be better support of all the nearly-there packages so that variants don’t end in dead ends so often. Funding better documentation and guides and keeping them up to date as a cross-functional dependency changes or a new one is introduced.