Relearning to Code
This is a response to someone who now has medication to treat their ADHD. They essentially asked about how to approach programming and problem solve.
Three years ago covid did a number on me. I got the brain fog they talked about. A lot of my programming knowledge and specific understanding of Ruby on Rails (what I use) was wiped out. I’ve been relearning it for the last six months or so.
I have ADHD (non-medicated) but I’m also autistic so I have a need to plan things. Basically, I whiteboard (or write on paper) the problem. What are you trying to solve / build? Break it down into parts / steps. Break those parts / steps down into more parts until you have individual parts / discreet steps. In college we learned this by having to write out instructions to make a paper airplane. Sounds simple at first, but when your teacher follows your instructions exactly it is pretty involved. We wrote “fold the paper in half” and she’d fold the long edge down in half. So we had to adjust to say “fold the paper in half so that the long edges touch.” And on and on. It took like 30 detailed steps. It’s the same for programming. Break down the problem into parts.
Example: create a user profile page. Each user needs an account to have a profile page. Each user must sign up for an account (separate task to create sign up process). Each user has their own profile. Each user can edit their own profile. The user needs to be logged in to edit their profile (separate task to create sign in process). Users cannot edit another user’s profile. Check that the user is requesting to edit their own profile. If they are not, display error message and redirect to their profile. If they are requesting to edit their own profile display the user’s profile in an editable form. Accept the user’s updated profile information. Confirm that they are updating their profile page by matching the logged in user with the profile id. If it matches store it in database and redisplay the user’s profile. If it does not match discard the updates and redisplay the user’s profile.
As for making memories of codebase, take notes. I prefer to hand write my notes then type them up as comments in the codebase. Draw flow diagrams. Keep track of decisions made and why they were made. “We explored two options to solve this. We chose the first solution because …” These notes are invaluable two weeks or two years in the future when you’re trying to remember why the code was written a certain way.
Go back again and ask your coworkers if you have any about the code. Ask for an overview of the system, any design / technical decisions they made and why. Add those to the notes / comments. You said the codebase is pretty big. Start with sections you need to work on and document it. Then work from the beginning up to where you are working so that you have an understanding of what happened and how the program got to the part you’re working on. Then continue through the rest of the code starting with the sections closest to your work.
Ask your coworkers to document their work as well. It doesn’t help you or future them if they don’t document decisions and reasons.
Good luck!
Three years ago covid did a number on me. I got the brain fog they talked about. A lot of my programming knowledge and specific understanding of Ruby on Rails (what I use) was wiped out. I’ve been relearning it for the last six months or so.
I have ADHD (non-medicated) but I’m also autistic so I have a need to plan things. Basically, I whiteboard (or write on paper) the problem. What are you trying to solve / build? Break it down into parts / steps. Break those parts / steps down into more parts until you have individual parts / discreet steps. In college we learned this by having to write out instructions to make a paper airplane. Sounds simple at first, but when your teacher follows your instructions exactly it is pretty involved. We wrote “fold the paper in half” and she’d fold the long edge down in half. So we had to adjust to say “fold the paper in half so that the long edges touch.” And on and on. It took like 30 detailed steps. It’s the same for programming. Break down the problem into parts.
Example: create a user profile page. Each user needs an account to have a profile page. Each user must sign up for an account (separate task to create sign up process). Each user has their own profile. Each user can edit their own profile. The user needs to be logged in to edit their profile (separate task to create sign in process). Users cannot edit another user’s profile. Check that the user is requesting to edit their own profile. If they are not, display error message and redirect to their profile. If they are requesting to edit their own profile display the user’s profile in an editable form. Accept the user’s updated profile information. Confirm that they are updating their profile page by matching the logged in user with the profile id. If it matches store it in database and redisplay the user’s profile. If it does not match discard the updates and redisplay the user’s profile.
As for making memories of codebase, take notes. I prefer to hand write my notes then type them up as comments in the codebase. Draw flow diagrams. Keep track of decisions made and why they were made. “We explored two options to solve this. We chose the first solution because …” These notes are invaluable two weeks or two years in the future when you’re trying to remember why the code was written a certain way.
Go back again and ask your coworkers if you have any about the code. Ask for an overview of the system, any design / technical decisions they made and why. Add those to the notes / comments. You said the codebase is pretty big. Start with sections you need to work on and document it. Then work from the beginning up to where you are working so that you have an understanding of what happened and how the program got to the part you’re working on. Then continue through the rest of the code starting with the sections closest to your work.
Ask your coworkers to document their work as well. It doesn’t help you or future them if they don’t document decisions and reasons.
Good luck!