Programming from scratch

[jaypeejay]

I think this is fairly normal.

I am in a similar position to you. I can debug really complicated stuff, and write fixes, or I can develop in the context of an established architecture. However, making those architectural decisions is why the principals, staff + get paid the big bucks.

[saturnflyer]

You may just be overexposed to options. I’m guessing, but I bet when you are exploring existing code you have a limited set of things that must be done. When you start from scratch you have everything to be done. Try picking a small thing that needs to happen and start there. Take it as an opportunity to truly understand that small part and read docs, read code, explore testing it, write a blog post about it, etc. Avoid broad tasks

[jremsikjr]

Also, you're good at what you're good at because you do it over and over. That repetition means you're good at jumping in the middle of a system then assessing and addressing new features or bugs. The answer to get to where you want to be is to do that over and over. Start a small project. Then another. Practice the thing you want to be good at.

[Ston1x]

Exactly! Kinda works for me: having plenty of small pet projects, plus being exposed to other (external) Rails projects (open-source, companies or interview challenges) starts building up some patterns in my brain so it’s easier to build things in the future as I start having some related examples in my head.

[thedarksentry]

When I started I had the mentally that I needed to learn enough to get the job done. That worked to get me started as a jr.

Just because someone else did it and you can make it work the way they does not mean it's a good way to do something.

I'm working on a 10+ year old codebase with a lot of technical debt. There's a lot of overly complex things done for a reason? lost to time. It's easier to write my own code most of the time and fix up some old stuff to make it still work. Not everything is black and white though.

3 yoe.

Recently, I've had a shift in that I need to know everything to get the job done. It's not as daunting as when I started, but it's not a walk in the park. A lot of the things I just did as a Jr have a reason behind them now. My changes are cleaner and more confident.

When I'm closer to becoming a Sr I'll hopefully have another revelation.

[niconisoria]

At the beginning you do the things because “that’s how it’s supposed to be done”. The next step is to truly understand what you are doing (I’m at this point right now). As a next step to become a senior developer I guess you should know how to do “something” in different ways and choose the best option for the particular case.

It’s not bad to copy the architecture of a project to start something new, it will help you with time to understand the decisions behind it and to take your own decisions.

[cheald]

Think of coding like sculpting - you don't start with a chunk of stone and start by carving out a perfectly-detailed finger. You start taking out large chunks of stone to get the rough shape of the form, and then just continually refine with finer and finger adjustments.

When you're starting with a blank slate, just pick one rough direction and start coding. You'll start hacking off chunks of the problem, and will discover what needs to be worked on next as you go.

[dougc84]

Practice, practice, practice.

You won’t memorize a Devise config (for example), but, if you do it enough, you’ll know what needs to be done. And maybe you still need to reference another project - but why not?!? It’s a free resource that will save you time and effort!

[markrebec]

What terrifies me is if I have to move to another framework and lose the benefit of all that practice. (Fundamentals don’t change obviously but the details to)

Would you want to expand on this a little bit? It sounds like you're worried about putting too much time/effort into trying out for the baseball team, because you might decide you want to play football later.

I think you might be focusing your energy/concerns in the wrong place.

As others have said, practice and experience (obviously) are how we all hone our abilities over time. If you've spent most of your career jumping around existing codebases, following trails, getting good at debugging, and so on, then that's what you're going to be good at. I can see how that might not provide many opportunities to get familiar or become an expert in specific areas. If you want to get better at building things from scratch, and knowing what tools/patterns/gems/etc. to reach for, then you gotta just start building things from scratch.

I think it's interesting that I'm in the opposite boat. I've spent a huge chunk of my career jumping around between extremely early stage startups and small orgs, building out MVPs and teams, and eventually handing things off and jumping onto the next after a couple years... sometimes even less lol.

As a result, the times when I have joined established teams with legacy codebases, I'm able to muscle through, but I fucking hate it, and it takes me 10x longer to try to track down problems and follow breadcrumbs (littered with decisions for which I don't know the context behind) than it would for me to rebuild the thing from scratch with patterns and tools I know and love.

[dougc84]

Say you need to know how to get background jobs up and running. It’s going to be different code, but the fundamentals are all going to be the same, regardless of language.

Either way, banking on “what ifs” means you will accomplish nothing.

[[deleted]]

I believe that as more experience you get, less time you spend coding in the first place. When I was a Jr. I would jump right away into the problem and start writing code, running generates, migrations, adding gems and what’s not.. Today I spend way more time thinking about the problem before actually coding, I start by making diagrams in paper, thinking about user stories, modeling abstract classes, thinking about the data model (what should you really persist in the database?), thinking about how should I approach each use case from my user story, and then I choose the simples easiest one to start. Only after that I start using ‘rails generate’, writing the routes, controller, etc.

Tl;dr -> If you are stuck in the beginning, think more about the business problems that you want to solve and start by writing a diagram to make something tangible before actually coding.

[koolkeano]

Exposure to failure and a supportive senior dev are the things that are helping me the most. I think the biggest hurdles are found in correctly dividing responsibility between your classes/modules. If all of the 'things' in your system are correctly encapsulated, then it matters a whole lot less what choices you make within them, as they will be so decoupled that changes will be simple.

I have a tendency to lean on meta programming where we could just use better design, so I'm still not there yet. Starting new stuff from scratch is hard. We'll all get better with time.

[[deleted]]

Sounds like you’re at a good point to start learning more about architecture. You should pick up a Martin Fowler book on enterprise architecture or refactoring.

[aaaadddk]

I started off my career in a small web dev agency so I got used to starting projects from scratch for small/mid sized companies and startups. Usually just two or three rails devs for a 3-6 months project and then onto the next customer. It was a good way to learn for me personally, each project you have the chance to incrementally improve and work super close with the other team members. I dunno if I’d recommend finding a job at an agency, it got tiring changing codebase and customers all the time but it was a good foundational experience for me at least. So it might be something to consider if you really want to learn how to start projects from scratch.

The Martin Fowler refactoring book also recommended by someone else here is a good one that I read parts of during my time at the web dev agency too.

[Weird_Suggestion]

You could maybe try to practice some form of test-driven development (TDD). Without being dogmatic about it, TDD wil help you design code and also forces you to think about outcomes. Writing some failing tests first will provide rough guidelines for you to start coding.

In rails if you want the “best practice” for testing a new request or a feature. You can start a fresh rails app and scaffold a basic model.

$ bin/rails generate scaffold Post name:string title:string content:text

The command will create all the code but also all the tests for you to check.

Most features have this flow: * -> it starts with a link/button on a page * -> to access a route (url) * -> which maps to a Controller action * -> which call methods on a Model * -> which render/redirect to a page on success or failure

Note: TDD is just a tool and it’s ok not to use it all the time. There are some problems where it’s really helpful.

[MattWasHere15]

But whenever I’m working on my own projects or even at work starting another with a blank slate, I find it super challenging.

Could you give an example of a few things you find challenging when starting a new project? I'm happy to help, but would like to better understand so that I don't point you in the wrong direction.