In 2014, for the Google Summer of Code program, I applied to build a JIT compiler for the MoarVM virtual machine. (It is actually more correct to speak of my work as a JIT backend than a full-fledged compiler - the 'frontend' of the compiler was already under development when I started). At the time, I knew just short of nothing about compilers, let alone JIT compilation. So what I did instead was learn, and make lots and lots of mistakes.
And it worked. The JIT backend I created has been in production since 2014, with a new backend since 2017, and a small (but thriving) community of contributors. It is far from the worlds most advanced JIT compiler, but it does provide a nice speedup on real-world perl 6 programs. All the while I've continued learning.
So... definitely try ambitious things :-)
1) Stop and spend time trying to get a clear mental model of what you are confused about
2) Push forward and try to build despite not understanding
In the past, when I tried doing super-ambitious things, I used the second strategy. Many sleep-deprived (tip: “sleep is for the weak” is BS) nights in which I accomplished nothing left me with a strong feeling that I should not try to do impossible things. However, since I learned the first strategy and have been applying it successfully to projects at work, I am rethinking this. I have increasingly been feeling like I would be able to be surmount large challenges if I first set myself up for success in terms of resources and people to ask for help.
A) Do you apply a “step back and study” strategy to tackle confusion? Have you found it successful?
B) Do you have any more detail you could add on how it works?
C) How do you set yourself up for success outside of a work setting? For instance, I would like to write a server-side debugger for nodejs that is independent of google chrome and works toward a pry.rb-like developer experience. However, I haven’t written C since by OS class in uni and I don’t know the internals of node.js. How would I go about building trustfull relationships with people who know the internals of node.js so that I can ask them questions in the style of https://jvns.ca/blog/good-questions/
So when you pose the question, whether to push or take a step back, in my experience, it's better to pick clarity over aggressive pushing. It's subjective though. While I think there are overarching principles, I also think that different people react to these situations at least a bit differently.
To say a few words about confusion when confronting something you don't fully understand, I think the more confusion you can take, the better. Ideally confusion should be second nature to us, too often we jump to something prematurely just to escape it. When you think about it, we never fully understand all the things at play. It's about not being paralyzed by that.
My condensed advice is:
1. Are you still making progress? Keep going. Don't give up.
2. Are you spinning your wheels? Take a step back, re-evaluate what you know, investigate things you are not clear on.
3. Still stuck? Ask for help. Don't panic or be ashamed. Show the progress you've made in step 1 and share the things you studied in step 2.
a): 'Studying' is definitely very important to get an idea of the context of the thing you are trying to solve. (I did a lot of reading both before and during the project). But, it doesn't always relate easily to the problem you have right now. (E.g. I'm using linear scan allocation, and the papers on that method all glossed over the nature of a 'live range', which took me 3 iterations to figure out). And without a practical problem to guide you, it is easy to get lost in literature.
b): What I find is that before I try to do something, I typically put together a high-level overview of how I think I can achieve it (what stuff to change where, and what I will need for that, roughly). But I'd classify that more under planning than under studying per se.
What I also do is take lots of notes. I have several large org-mode files (big fan) and before that paper notebooks in which I write down thoughts as they come up. I think org-mode is superior because it lets me organize things after the fact. Notes are a crucial bit of making progress for me, because I don't need to revisit the same things over and over.
The other thing that I find helps very much (and which I wasn't very good in at first) is to do incremental, small-step improvements. Move a function here, change an struct there, change an interface, move some process earlier or later, split it up. Simple things that you can do and that you know will not go wrong. Many problems can be broken down in that way, and the few that can't can at least be 'isolated' so that you can fix them 'atomically'. I wrote a blog post about this some time ago, if you'll excuse the link: http://brrt-to-the-future.blogspot.com/2016/06/in-praise-of-...
c): I was lucky to be able to join the perl community as part of a GSoC project, and fortunate that the perl community is altogether friendly and welcoming. And I really can't speak for the node.js people at all. But what I will say that anyone with a genuine interest in contributing (as you seem to have) and a willingness to do the work to learn (and to listen) will find a warm welcome from nearly all open source projects, because all of them are relatively understaffed compared to their ambitions :-)
So in your situation, I'd start with checking out the node.js source, start with trying to figure out how a debugger could work (there is lots of prior art here, of course, so you can check out the chromium source as well), and ask your questions basically as the jvns comic demonstrates.
I hope that answers some of your questions.
I have a simple little project I'd like to make to manage movie night with my friends. Right now we do it all over email and it's a confusing mess. Since I'm new to the world of web apps (and looking for an excuse to dive in), I needed to learn some background and now I'm firmly gripped by analysis paralysis. I've learned a bit of Go, of Ruby and Rails, Dart, Angular, and some others. I've read through most of the HTTP spec and I have Roy Fielding's paper where he defines REST in my Pocket account.
This morning I'm thinking I should check out Azure or maybe Google Cloud. But also I've done work in Java + Tomcat... maybe I should dust of my JDK?
I need somebody to say "here are the four things you need to make a one-page app that lets users express some preferences and constraints and a little engine in the background can tally the results".
Don't be lured by the latest and greatest HN koolaid. Stick to the bare minimum. The more complexity you add to a project the harder would be to maintain.
To make a food analogy, if you're trying to learn how to cook, you don't need the latest kitchen gadgets.
Just ingredients, pots/pans, and a reliable, controllable source of heat are enough.
Adding extra pieces (especially when you're getting started) is only going to make your learning curve steeper.
rails new && rails g scaffold Movies title:string && rake db:migrate && rails s
Visit localhost:3000 in your browser and there you go.
With that short line, you can CRUD Movies including a functional UI.
Obviously “real” apps will require a bit more work, but not much depending on how complex you need things to be. The Rails Guides are super helpful.
If someone wants a more robust and production-ready intro to Rails, Michael Hartl’s free Rails Tutorial is exceptionally good.
RoR feels like something I really should have in my toolkit anyway.
You should work through the book Rebuilding Rails if this is your goal.
For the client side I would recommend vue, but react is also very popular.
Once you have chosen the backend/frontend technologies then you can start building. If you don't know anything about rest learn how your apecific framework does it. You don't need to learn rhe whole spec. At least not in the beginning.
I really just need to stop considering...
I love to throw out crazy ideas. Most of them get filtered away, but I've gotten to prototype some initially unapproachable stuff:
* Generate a dsl for interacting with web pages in ui tests from the frontend framework templates
* Write a test recorder that lets you step through the browser state
* Write a Jenkins plugin to track who's probably broken what test
* Write a VSCode plugin to add run buttons to CodeceptJS tests
* Write a git hook that maintains two way synchronization of a folder between two separate git repositories (by rewriting & copying commits).
My co-workers see me do crazy stuff, but in actuality, it's not that hard. I would say that VMs are definitely harder than what I've done, but I think the concept is the same: the unfamiliar seems unapproachable.
I should add I have had support of more people than I can name :-)