[brrt]

I just wanted to share that everything jvns is saying here is true.

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 :-)

[afarrell]

I would like to know, when you run into the situation that you don’t know was is going on with what you are building and feel a sense of confusion, do you:

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.

Questions:

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/

[dmos62]

A heuristic I use that is very accurate for me is whether or not I can easily step away from what I'm doing (for a break, or just to finish the day) or do I feel a compulsion to keep going. If stepping away is difficult, I'm definitely in a "death spiral". At this point I can be sure that my productivity is already low, and it will just get worse. It's a burnout; a feeling that your problem-solving apparatus has overheated; severe tunnel vision coupled with impatience. It's weird that it produces such a drive to continue.

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.

[reggieband]

It is interesting because I went through this exact question recently with an intern.

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.

[Serow225]

The Feynman Algorithm: 1) Write down the problem. 2) Think real hard. 3) Write down the solution.

http://wiki.c2.com/?FeynmanAlgorithm

[brrt]

These are all good questions, and not so easy to answer :-) Any answers I can give are personal, of course, and may well have no relevance to your situation.

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.

[criddell]

My problem sometimes is just getting started.

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".

[elorant]

Ruby on Rails is more than enough for your needs. Pair it with some simple HTML, plain JavaScript (no frameworks whatsover), and a database of your choice and you're good to go. Or you could use plain JSON with no database at all. No cloud either, just host it to a simple shared hosting provider.

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.

[disqard]

GP, I hope you heed this person's advice.

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.

[criddell]

Is Ruby on Rails really a candidate for bare minimum? Part of the reason I backed off was the enormity of Rails. Part of why I'm doing this is to understand what's going on under the covers and Rails feels like it has a broader and more opaque cover than most other options.

[briandear]

With scaffolding, you can have a functioning Rails CRUD app in literally minutes. There is a lot of stuff Rails _can_ do, but not a lot of stuff you _need_ to do. You don’t even need to write a single line of JavaScript if you don’t want to.

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.

[criddell]

Hartl's tutorial is the one I was working through. It's excellent.

[elorant]

I only mentioned it because you said you did some research/learning on it. Seems like the best choice from all the technologies you listed because it is the more mature for web development.

Other than that, no it isn't necessary. You could start with plain HTML and JavaScript only. But sooner or later you'll have to choose one tech for backend.

[criddell]

That makes sense. Thanks for taking the time to respond.

RoR feels like something I really should have in my toolkit anyway.

[afarrell]

> Part of why I'm doing this is to understand what's going on under the covers

You should work through the book Rebuilding Rails if this is your goal.

[Serow225]

Would Heroku be an OK path for the OP, to remove some of the barriers to entry?

[IceSentry]

If you already know java for the backend then just use that. Or if you want to learn something new pick one language. You don't need to learn all of them.

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.

[sdenton4]

It's worthwhile to think about what the minimum viable product might be... I had a similar problem with a book club, which we solved with a google drive spreadsheet (collecting ranked votes) and an ipython/ jupyter notebook (performing the run off).

[criddell]

You know, I never thought about scripting and Google Docs...

[arcbyte]

Not sure exactly all the requirements, but it sounds fairly simple. Use AWS S3 or Azure Blob to store and retrieve a static webpage and json "database" and wrote the whole thing in JavaScript and html

[criddell]

I like working with Python. Do you think Google's Cloud Platform should be considered?

I really just need to stop considering...

[konamicode]

This can work well if you are in an environment like the Google Summer of Code program. It's much harder to do this if you don't have a mentor or two who would be able to spot your mistakes and guide you in the right direction. For many engineers out there they would not have the same set up. Someday I would love to help out somebody with something ambitious but I feel like I need to learn a ton before I am in that position.

[brrt]

Indeed, I owe a debt of gratitude to a lot of people.

[swsieber]

Indeed. Mostly, it just takes time and getting familiar with whatever idea you're tackling.

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.

[criddell]

I find DSLs and FSMs are the most satisfying things to develop. Getting a DSL right is like a magic turbo button and a FSM with the right states and transitions can help clarify really ugly problems.

[Serow225]

That's awesome, congrats!

[brrt]

Thank you.

I should add I have had support of more people than I can name :-)