When planning out your code how do you work?

1

Hi,

Beginner coder here

I am in the early stages of writing my HTML/CSS for The Odin Project’s Google Homepage and it’s all feeling like a mammoth project. I have broken it down and even drawn a rough box sketch on paper planning out divs and navs etc.

I just wanted to ask the more experienced among the community, and even beginners like me - when you are planning a big project (this google clone feels like one to me :stuck_out_tongue: ) how do you plan out and execute your project?

At this point I don’t feel like I can just start writing in the editor because i would get lost in all the other structure of my code as I am perfecting different parts of the structure.

Would love some input from others:

  • Do you break the task down and write it in chunks? In separate windows on your code editor and then amalgamate/test?
  • Do you ever write anything down on paper? lol
  • What’s your strategy for add/commit on GitHub? Do you commit regularly or at the ‘end of the day’?
  • When there are a ton of elements how do you prevent yourself from getting lost in it all?

I know everyone is different in the way they work and approach tasks but i’d be really interested to get a sense from others. I’m learning and studying alone and can sometimes feel like I’m not getting anything right…

1 Like
2

Yes, I break it down. In fact, at work we are supposed to write our tasks as the smallest scope of work that can be added individually to the project. The second question here I’m not sure I understand but I think is a “no”. I break it down and then I work on one piece at a time. I do have multiple editor widows open, but that’s because every change I make requires changing multiple files.

Yes! You can save so much time by making your plans on paper. This is the correct place to organize your thoughts, identify your requirements, design your logic flow, etc.

I use these as “save points”. If I have the core functionality working, but it still looks like a hot mess I will create commit. If everything is done except the tests, I make a commit. If I’m about to change some things that I’m afraid could break the work I’ve already done, I make a commit.

Consistent organization, clear names, familiarity.

2 Likes
3

Thank you so much for your input. This was very helpful!!

4

I’d actually not start with the code at all. You’d want to be able to know at least some of what you’d need to tackle/learn/understand with a given project, and understand its scope. If you want to build a “google clone” then you can have a few different levels of “depth” you can go into.

  • You could build a front-end only version with a few entries. More as a learning experience than anything practical.
  • You could build a simplistic database driven one where you have a list of some stuff you set yourself in a database. Maybe a way to add new entries. Nothing thats going to actually blow any search engine out of the water, but again a good learning experience
  • You could go full on machine learning+web scraping version that actually is a “search engine”. This would be in-line with how an actual search engine would work. It might be super slow compared to an actual one, but it would “tic the boxes” of how a search engine would work.

Either of these approaches requires a different approach, knowledge, depth, tools, goals etc etc. You’d want to roughly know what your getting into before you get into anything, otherwise you end up blinding building stuff without understanding the big picture.

I personally usually write out the task at hand somewhere. To break down the "flow before I actually do anything. If you want to build “a google clone”, you’ll need a front-end, potentially a back-end, and some supporting tooling probably. I’d start setting that stuff up. Go from there for each smaller feature you need to do, you don’t need to know exactly what you need to do, just the high level work.

Commit often when you have any sensible, noticeable work done or just want to save a “point in time” of work. Commits are where you can “jump” back to, so the more you do it, the more options you end up with in the future.

I usually use a tool (like github issues or similar to keep track of what needs to be done in general. Over time you will find more and more work that needs to be done, you might not need to do all of it now, but you should be able to “save” what you find somewhere so you don’t forget it. After that, just keep chugging along as best you can.

It might seem overwhelming how much you need to learn, and do, but all you have to do is just start. Keep working bit by bit, feature by feature, learning a little thing here and there. You only get where you need to go by taking things step by step, before you know it you’ve climbed a mountain.

Good luck, keep learning, keep building!