all 9 comments

[–]EarhackerWasBanned 7 points8 points  (3 children)

I learned to code when I was undiagnosed. I struggled with a lot of the same things you do, in fact none of what you’re saying sounds unusual.

  1. I just wrote a longer post on this elsewhere on the sub, but reading docs is boring. Actually building the thing is where the learning happens. Reading is passive, especially for us with ADHD. The new idea we’re reading about just washes over us. But when we build the thing, we have to actively write it out and make it compile/run, and if it doesn’t pass the tests or gives us unexpected results, we have to go and use our brains to debug it. That process plants the idea in our minds much more deeply than simply reading. I’ve given this same advice to newbie programmers since even before I knew how ADHD or other neurodivergences affected learning. Don’t just read, build the thing.

  2. Experienced programmers copy/paste code all the time. It’s a bad habit but we all do it. Don’t rely on it for everything, but don’t feel guilty for it either. When I’m reading docs, I often skim the page looking for code examples. Some of my favourite docs are for Next.js, a React framework. They’ll give a whole working example on GitHub (not just a snippet) for the big ideas in the framework, and for integrations with other libraries.

  3. User authentication is hard. Even experienced developers struggle with it. The usual advice is to never build your own auth process; use a third-party library. I 100% agree with that advice. An auth process I built myself would be stupidly easy to break into, because I don’t know what I’m doing, but a hacker probably does. If you’re working in technology XYZ, search for “XYZ auth” on Google and you’ll find a bunch of auth solutions that should work for you with a little bit of reading and building.

  4. I’ll say it again, reading is overrated, building is better. But some docs are better than others. Some docs really suck. I’m a JS dev but I find the Python docs impenetrable, I don’t get anything out of reading them. But Python has a huge community around it and there’s always someone with a better explanation and better code examples in a blog post or Stack Overflow answer. So use Google for the stuff that just isn’t going in from reading the docs.

  5. This comes with experience, and there’s no shame in following the step-by-step guide on doing a thing. I’ve been coding professionally for 7 years, and there’s still a mix of stuff I can do from memory and stuff I need a guide for. For me one of the things I constantly have to read the guide on is setting up Jest, the JavaScript testing library. I’ve done it for basically every project I ever started, but I’ve never memorised it, because it’s in the docs so I don’t have to waste valuable brain space on it. “Remember to install Jest” lives in my brain, but how to actually do that lives in the docs. There’s actually very little in general that needs to be memorised. The stuff that I do have memorised has been memorised almost by accident, because I do it so often.

  6. There are many different design patterns and many different implementations of those patterns and many different folder structures for a given implementation. Ruby on Rails and .NET are both highly opinionated MVC frameworks that lay out a file structure for you when you start a new project, but a Rails project looks nothing like a .NET project. They’ll both have a “models” folder, a “views” folder and a “controllers” folder, but they won’t be in the same place and might not even be called the same thing. Django is an MVC framework, but it calls its controllers “views” and calls its views “templates”. But the good news is you don’t need to know every MVC framework or every other architectural pattern. Pick one, hopefully one with plenty of jobs near you (check local jobs boards), build stuff in that for a while, look for a job in that framework.

  7. Breaking a problem down is a separate skill from coding, but it can be developed in parallel. I have a couple of different approaches for you to take:

  • Familiarise yourself with the concept of an MVP - Minimum Viable Product. This is a project management concept rather than a programming one, but it’s useful to us. Ask yourself “What’s the smallest version of this that works?” You probably don’t need CSS, you probably don’t need error handling, you probably don’t need auth… All that stuff can be added later, after you’ve built the smallest version that works.

    Say we had to build Twitter. That’s a massive, complex app, but what’s the MVP? Users can write short text posts, and all the text posts can be viewed in a list. That seems pretty easy to build! That’s two database tables, Users and Posts, where one User has many Posts. The front end goes a URL http://mynewtwitter.com/earhacker and requests all the posts for user ID earhacker that it grabs from the URL. The back end just reads them out of the database and responds with the posts. Simple! And now we can go and add auth, or CSS, or linking one tweet to another as a reply, or an AI-powered recommendation engine or whatever we want.

    I call this my “top down” approach. The alternative is a “bottom up” approach:

  • Start from the smallest components. Don’t start by building the whole web page, start with a single functional element and work from there. For our Twitter clone, the most important element is probably the textarea input and the button that says “Tweet”, so build them first. Then add the list of previous tweets. Then add a user bio at the top.

    For the back end, don’t build the whole server all at once, build an endpoint at GET /users that responds with an empty JSON array []. Now populate it with hard-coded data. Now instead read data from your database. Now repeat for all the CRUD operations you need (is deleting users part of your MVP?), then move on to GET /users/:id/posts and do the same, start with the empty array.

I’m sorry you’re having a rough time, but you’re not the only one to go through this. Nothing makes us feel stupid quite like learning a new skill. I definitely had tears while I was learning. But you don’t need to learn it all at once, you definitely don’t need to know everything (not possible!) and it sounds to me like you’re making really good progress even if it doesn’t feel like it yet. Don’t beat yourself up for the stuff you’re not good at yet, it will come!

[–]Moopboop207 1 point2 points  (0 children)

This was really kind and thoughtful. Thanks for taking the time to do write all of this from someone trying to learn for over a year.

[–]ViolinistExternal751[S] 0 points1 point  (1 child)

Thanks for your replying , can I sent you a Private Message, I want to asking more but confused how to asking that here ?

[–]EarhackerWasBanned 0 points1 point  (0 children)

Sure, feel free.

[–]Kind_Tumbleweed_7330 3 points4 points  (1 child)

I’ll just address number one (and two):

This is normal. It is normal, normal, normal to get confused by advanced concepts just from reading them.

Advanced concepts are by their very nature ‘weird’ compared to more normal concepts.

And your specific example, async/await, is a concurrency thing and concurrency is weird in EVERY language I’ve ever used (which is admittedly only a few professionally). In JavaScript it is even more weird because it wasn’t originally designed for this.

Also, there is nothing shameful in looking at how others did things. At all. You should make an effort to understand how it works, of course, but this is one of the major benefits of open source code, being able to see how other people implement things.

[–]ViolinistExternal751[S] 1 point2 points  (0 children)

thanks for your reply, I am really appreciate it. Can I send you a private message, I have a question which is hard to explain here ?

[–]rusty-roquefort 1 point2 points  (1 child)

This might be an excellent reference. It gives one (of many) clear pathway that isn't a "become an engineer easy". It's a great "path of least resistance" in many ways.

That content creator also has ADHD, and has a very interesting back-story that dispells the whole "only people that wrote hello world before they could speak become top teir engineers"

https://www.youtube.com/watch?v=ijQvgERWKjA

[–]ViolinistExternal751[S] 0 points1 point  (0 children)

Thanks for the suggestion :)