I’ve been defining my personal mission as get more brilliant minds into software engineering. Engineering is where I am, and I would love to work with even more brilliant minds!
I’ve been thinking about mentoring, about workshops, about books, and every time I draft anything, React appears as a key element. But why?
Therefore, by designing content that features React heavily, I am playing to my strengths. Is that a good enough reason to ingrain React to those brilliant minds I want to lure? “You should learn React, cause I’m good at it”?
That doesn’t sound right. I was a pro at Angular 1.14 once upon a time. Should it have been my cornerstone then, when trying to teach engineering? If yes, should it only have been dethroned if I somehow became “more pro” at something else?
So this is my sanity check for React as a gateway into software engineering. I’ll outline my thought process and I’m eager for your thoughts and counterpoints. After all, no matter how objective I try to be, this is just one person trying to arrive to a good answer. For those problems, the more discussion and viewpoints the better!
It’s how I’ve arrived to exploring React more and more way back when, before deciding that switching to it from Angular was the best decision going forward for me, my colleagues and my apps.
So the mission is get more brilliant minds into software engineering. There are certainly many aspects in achieving this, such as “marketing” the roles you could have, the salaries, the perks…
However, the goal I want to examine now is a practical one. You can “sell” any career on paper, but when people start getting hands-on, that’s where their resolve is in the biggest danger of depleting. Which makes sense: Most people love being good at things, and dislike being bad at things, and it’s very hard to be good at something starting out.
So the first big goal is I’d be setting for someone I’m hoping to entice towards a software engineering career, is “build something that leaves you more intrigued and excited to be a software engineer”.
Much like a picture is worth a thousand words, an interactive UI is worth millions of lines in the terminal. There are tons of cool little programs you can make beginners write, sure, but they’ll never approach the wow factor of seeing something visual and colourful that responds to touch. I find having to use the keyboard removes the user from the experience, a little tiny bit. Keeping things mouse or touch-driven maintains a more immediate connection.
I’ve also found it sometimes tricky to get even experienced engineers to trust the command line. I personally find it satisfying to code using only tests running on a terminal until whatever I’m trying to build is fully done, but so many engineers insist on running the real thing and physically clicking around “to see it working” every step of the way. And of course, I used to be one of those engineers. I’m not condemning that approach, it intuitively feels “more real”.
Also, even when you are building something user facing, you can still make great use of the command line, you can still benefit from isolating smaller problems and engineering concepts you’d want to focus on, by been shown the ways of Test Driven Development, or Behaviour Driven Development.
Finally, if it is user-facing, you can share it with a friend quickly, without that friend needing much further context to appreciate you’ve built something real. It’s harder to say “hey download this file, open your terminal then run:
~/Downloads/signupForWOD.sh [email] [password]
And you’ll be signed up for Today’s WOD at Gymbox!”. Of course, just telling your friends “You know, I’ve built this little script that signs me up to the day’s WOD without me having to remember to do it manually at 7am the previous day” is amazing. You’ve built something real, something that is giving you real value!
But what you’d probably be getting back from your friend then is a sweet “cool story bro” and that’d be it, which just isn’t enough for me. Seeing people interact with the thing you’ve built is a next level payoff, and something that will drive you further forward to implement changes, and fixes, and new features, and all the things.
This drives into my second assumption: The user-facing thing I want you to build has to be on the web. “You have to build a web app”.
Why a web app?
How about a native app?
You know, like a snazzy iOS app, maybe using something like SwiftUI? Native apps almost always look “more professional”, there’s a decent amount of resource to guide you and SwiftUI in particular has tons of drag & drop elements you can experiment with. Watch enough tutorials and drag around enough things, and you’ll have one of those slick List / Detail views in no time flat. It will animate perfectly and even take into account Dark Mode.
But how would you share it with your friend? Would you need to buy a license and go through the App Store process in order to give them a link to download, a couple weeks down the road? Would you really go through that trouble for a silly app you’ve built mostly for learning purposes?
Would your friend even go to the trouble of downloading anything from the App Store on pretty much a whim? Does your friend even have an iPhones? Were they even on their iPhone when they got that link from you?
With a web app, you just send a link and no matter where they click it, they’ll see it in all its glory, without having to then think: “do I really have time for this? Do I want to install it? Is it secure? Am I on WiFi? Should I FaceID to accept? Actually open it afterwards?” There are more “drop-off” points with a native app, even if you’re just talking about sharing them with friends, let alone real users.
Also, do you even have a Mac do develop that app in? The storage space to download and update Xcode? How are you liking Xcode anyway? What are the best practices you need to enable working on that?
With the web it’s so easy to get started using Code Sandbox. It’s a magical project I’ve been enamoured with from its early days and nowadays it’s grown to a full-fledged IDE in your browser, with everything set up for you according to best practices. It makes your code look beautiful and sanity checks it for things that might catch you out, especially when you are a beginner.
You can see your code reloading and running on a window on the side, you can share that window, you can share yourself live-coding, you can collaborate, or you can even deploy what you’ve built with one click. Nothing confusing to download, nothing to
brew install, you can get started even on your phone! Literally all you need is a browser.
You may be able to streamline developing a SwiftUI app to almost such an extent with a good enough mac, but the buy-in is much harsher than following a link, and it is something you have you pick up and do yourself, not something the ecosystem has sorted out for you already.
How about a video game?
You know, like an Unreal Engine game! You can even release it as a web app in the end, you can have all sorts of targets “for free”!
I do think this is a good idea… However, for me, a lot of making a good game using Unreal Engine or Unity, is not about the code you have behind the scenes. With what Unreal calls “blueprints”, you might even have your game on Steam without ever writing a single line of code!
You will have developed an understanding of software engineering concepts by that time: I will consider you a software engineer even if all your logic is visual nodes you’ve dragged around the UI, but I do think you’d have demonstrated a skillset sometimes overlapping but most of the time quite different to that of a “traditional” software engineer. I would peg you as a video game developer, a niche with even fewer transferrable skills to “general software engineer” than being a web app developer.
It’s also hard to build a prototype that is better than the frankly amazing starter kits the Epic Games team behind Unreal has put out. When you can start with a working First Person Shooter, or a third person space flight sim out of the box, how much more work do you have to do to switch from “hm, that’s mostly what the template already had” to “I built this”. What’s in scope for getting you to the “I built this!” payoff, is so much bigger than in a web app.
And that’s beside the problems similar to the previous section for a native app, in that “can my laptop run this setup”, “how does this multi-window editor actually work”, “how can I isolate smaller concepts and test things” are questions that will plague you, but which you can dodge with a web app and Code Sandbox. They are problems you’d rather not have when you’re just trying to see if software engineer “fits” you.
How about an assistant app?
You know, like for Amazon Alexa or the Google Assistant! Conversation Design is fascinating to read about in general, and it is a neat trick to pull out your phone and say “Ok Google, ask GYMBOX WOD subscriber to sign me up for tomorrow’s workout”.
However, despite first-party tutorials and documentation both Alexa Skills and especially the Google Assistant Actions / Dialogflow have, I do think creating something with them is a level beyond fundamental software engineering. You can use it to build something amazing after you’ve gotten a handle on how code gets written, it’s great to extend your skills that way, but if you dive in straight into that sort of app, you would be building a different skillset, and the fundamental software engineering gaps you’d be leaving would be harder to close later.
Of course, there are many more paths into building something user-facing and, again, I welcome your comments. The paths above are the ones I’d be more tempted to use as gateways into software engineering, the ones I examined more closely before agreeing with myself that “web app” is the best target. It seems there are three key things that make “web app” win over them:
- Ease of use / minimal environment setup to start with
- Ease of app share-ability with friends / larger audience
- Closeness to a traditional programming language / exposure to software engineering fundamentals
So if you do share your own thoughts, it’d be super helpful to include how “with X you can get started in 5 seconds and share something in minutes!”. Maybe there’s a Code Sandbox equivalent somewhere else and I just don’t know of it, or how to use it properly! But I can only make decisions using my own knowledge so, until then, let’s move on to the last assumption.
“You should build something use-facing, on the web… with React!”
So why would you want to build an app with it? Well, its ubiquity plays a role but, for me, React’s biggest advantages track with the three points of consideration above for picking “web” over anything else:
- It’s as easy to get started as one click, using Code Sandbox. Follow this link on any device and you’re there! And, again, that’s starting with best practices enforced and immediate visual output of what you’re building out of the box, not a hacky REPL that gives you no guidance on code style or previewing.
- You have excellent user reach by virtue of targeting the web, and the “one-click deploy” integration. Browser support is fantastic thanks to defaults in Create React App, the boilerplate the above link is based on, and you can even get server-side rendering if you start with Nextjs. Helps your game load for your friends to start playing it before they get second thoughts on whether they’ve really got time for it.
v-formagic directives to pollute your head, just vanilla loops and conditionals for your control flow. Defining a function that takes some properties and returns some html is much closer to how a traditional programming language works, than what UI frameworks like Vue or Angular are trying out.
Now, especially Vue, I wouldn’t want to discard straight out. It’s featured in Code Sandbox as well, so it gets the same benefits as React on that front; they are actually Code Sandbox benefits after all.
Additionally, React is demonstrably further ahead in popularity and “job secure-ability” than the alternatives. Bleeding edge alpha versions of the the code itself are used daily in literally Facebook, one of the biggest apps everywhere in the world. React Native is its own huge thing, seen as an easy-in to cross-platform app development even if that perception isn’t without its faults.
React will be there, still be extremely popular and in high demand, by the time you’ve put in Gladwell’s ten thousand hours. It will be teaching you loads of non-domain specific software engineering and problem solving along the way. I don’t think that can be said with such certainty for any other React alternative.
So, why would you want to learn React in 2020?
Because React is the easiest-in into software engineering. The easiest-in into creating dependable apps of real-world complexity, apps that can reach a big percentage of real people.
And reaching real people with the stuff you’ve built is awesome.
That’s why I want you to get there, the fastest way possible.