Want to start a larger programming project

Focus on main goals.
Take shortcuts and leave notes.
Don't be afraid of making mistakes, you will anyways.

It's important to have your main goals met, inconveniences can always be solved later.

I'm migrating a huge legacy codebase and I just added some compile-time processing to fix shitty code, when I get the time, I'll fix it for real.

I also was just like that, but I think I managed to overcome this problem with a change in mindset and a few techniques:
-Start your project with two modules: "business rules" and "framework". Take a look at the hexagonal architecture (or the clean architecture by uncle Bob) to understand their relationship with each other. Two layers is simple enough to don't add too much overhead, and flexible enough to grow later.
-Use the most boring and safe tech you can
-Focus on implementing a single use case first, start with the business rules, and then the framework. Be relentless with YAGNI
-Test the use case only on the edges of each module, then refractor what you think is ugly. You shouldn't have to touch the tests
-Deploy that first use case to production
-Repeat

That worked for me. As long as you're following the layered architecture and kee, you're relatively safe from spaghetti, then just get a single use case done and shipped

Write spaghetti then fix it incrementally. You think you're going to come up with some beautifully architected solution before you even understand the problem you're trying to solve?

Prototype what you want to do, and then be ready to fucking ditch the prototype. It's going to be a mess, but you'll learn a bunch of gotchas regarding implementing what you want to do in the process, and you'll be prepared to create a cleaner, leaner design.

also, keep your feature set lean
every additional feature is a hidden hornets nest of complexity that will just start leaking through your codebase

>planning
quit lying to yourself. you're procrastinating

your first version doesn't have to be perfect. In fact, it is guaranteed to be shit. Get it done as soon as possible so you can begin improving it. Software development (and writing in general) is beautiful because you can revise. It doesn't have to be perfect. You can improve it.

So get something started and start improving it. Don't spend all your time writing new code. Put significant effort into refactoring, fixing bugs, and handling // TODO.

UMLv2, faggot.

draw the architecture down before starting

Just fucking start
You'd just end up throwing 90% of the initial plan away once you actually get to solving the problem and realize it was retarded

I never plan anything, I just start and figure it out as I go.
If I decide that something needs changing later I can refactor it.
If you really want, you can create a basic outline, but don't get too obsessed with it. Unless it's going to be some major large-scale project with lots of moving parts it isn't that necessary.

>little advice I got from a professor

professors are often terrible programmers,nearly none needs to put up with their code because it's just academic conceptual shit

Been there, done exactly that. Two things:
First, just start in a corner, don't get everything in at the start. If you want to write an operating system, just start out with getting anything that boots at all, even if it's just "hello world". If you're writing a game, just get a window up that you can draw stuff in. If you're writing a networking service, just start out by being able to connect at all. Then add on similar small things one at a time. That's not to say to not plan at all for what you know you'll be adding on later, but if you're not entirely sure how it'll look in the end, just ignore it for now and get back to it later. You'll probably have a better idea how it should look once you have the underlying things in place anyway.
And that brings up the second thing, don't be afraid to go back and change stuff. That is also arguably the one most important advice for any programmer anyway. Any programmer can write code. Good programmers can change code.

Attached: a.jpg (431x542, 54K)

80% of this thread is advising OP to write spaghetti.
As someone who needs to deal with spaghetti legacy code at work, fuck all of you, you fucking retards, stop being lazy and read about architecture, most importantly start decoupling your code.

Honestly, writing spaghetti code is a good start. It is through writing spaghetti code that you eventually learn how to avoid it.

Just to add to that, that's why it's good if you do so with your own personal projects, so that noone else will have to take it over later.

Getting caught up in the details is how you start writing spaghetti in the first place. I'm going to assume C++ but this applies to most OO languages

Modern C++ has smart compilers that can (generally) tell when something should be generated compile-time, and when something should not. Do not optimise without measuring. Do not be afraid to use RTTI and (static) polymorphism, for RTTI there are some performance quirks but as long as you're aware of them it's the same as using switch blocks only cleaner. Use interfaces liberally. Be accustomed to recursive templates.
And most important: WRITE INTERFACES FIRST. Then write the implementation. Do this for each module.

'Spaghetti code' is often caused by one or more of:
1. cyclic dependencies in classes
2. someone inventing a whole new language using macros (the worst of the four, but rare)
3. too little refactoring
4. too much refactoring

In large projects, minor code smells are hard to avoid and generally not worth 'fixing'. Do not fret about everything. If you plan to have others contribute, make 'code guidelines' with how the source code should be formatted.
I'm hearing people saying to write the implementation first, then 'clean up'. This is a bad way of doing things, since you're essentially doing double the work; if you write the interfaces beforehand, you won't have to worry about the structure of your code.

One more thing... be careful about the libaries you use and the compilers you support. MSVC for instance does not support inline assembly on x64, and some libraries are difficult to find packages for. Be prepared to learn CMake, it's probably the most useful tool you'll come across when it comes to portable compilation.

My process (using Pen & Paper):
1. Write down your main goal: "Cantonese Meme Generator"
2a. Collect your use cases. What are the workflows you want to support?
2b. What resources do you need, where will your thing be hosted/exectued? Database? Internet?
2c. Rought outline of the biggest components in your program. What is in the components does not matter, what is important is how the components communicate. This is where I define "interfaces", that is objects and what gets send to where.
3. Zoom in into a component, break it further down. Idealy you should end up with programming tasks that are finishable in 15-25 minutes.
4. Think about how to test your stuff.
Repeat 3 and 4 until you feel ready to implement. You can also always return to 3 and 4 after and during implementing.

You’re acting like if only you got over the architecture phase that you would be sailing smooth. In a big project the architecture is the hard part, so don’t try to get around it.

Write as you design and refractor when you need to

Start by planning shit with flowcharts.

literally this

After you get the design done, create a list of tasks for implementing it, then it's easy to just follow it.

Just start writing code, and constantly rewrite everything with the new stuff you learned

Alright then, that sounds like even better advice.

Write spaghetti, see along the way what works and how it should be done, rewrite properly.
It's impossible to give it a good structure from the start unless you have a good deal of experience. Or else you'll only get analysis paralysis.
I learned the hard way.

When pondering choices that seem too similar and you can't decide, just thow a coin or learn to use a pendululm to ask your subconscious.

With these two suggestions you'll clear all the roadblocks that prevent you from getting actual results and experience to do things better and faster.

And remember, not everything has to be an object.
Just because some language feature exists, that doesn't mean you have to use it.
Also don't split functions too much unless it actually helps readability or reusability, you will experience regret if your code becomes labyrinthine for no reason.
You will, you know it. It keeps happening to anyone everywhere.

functional language? start with types
otherwise, have formal spec before starting implementation

Write spaghetti and then refactor later.

You probably haven't implemented 80% of what you want to do elsewhere. Just throw shit at the wall, refactor it as you go along, and scrap it if it goes to shit. Make mistakes and move on with your life. You'll enjoy it much more.

>lol m8 technical debt is cool, don't worry about it
i know this attitude from the foundry, if it weren't for the monopoly, you'd never hear about nuke or mari

Refactor like a motherfucker. Code as naturally as you can, but stop the moment you feel the code is getting too hairy and see if you can make it less hairy using a pattern.

That said, this assumes you at least gave a minimum level of thought to your basic architecture (eg that you're not using a flat array when you're implementing a dictionary). Just don't take too long doing it.

Technical debt is not cool, but building a prototype and later using the experience gained to refactor the software is the best compromise.
The problem with technical debt is that companies are retarded and only think about "going fast" while all they're doing is delving deeper into the mud, just because "refactoring takes too much time".
Unfortunately without experience is just not possible to come up with the perfect architecture, knowing about paradigm and shit doesn't really help until the developer has had the chance to put his knowledge to actual work.
Also, some clever designs only become apparent when squirming deep into the spaghettis.

Have the confidence and skills necessary to actually plan/design something. If you are getting stuck for so long on a design, its because you don't know how to design it. Read more or design something simpler.

Even with experience, it's impossible to come up with perfect architecture. Perfect architecture changis with every new feature or bussiness requirement.
In fintech, we have a team dedicated to "repaying" technical debt. Nothing like that was ever done in vfx, they just dug a deeper and deeper hole and eventually reached the point where a new feature took several thousands of man-hours to implement half-assedly. Bug fixes easily took several releases and there were bugs so intertwined with nuke that it turned out to be impossible to properly fix them at all.
Prototypes should not be ever used in production. It should be used as a learning experience to come up with an architecture that's better suited for the problem domain.
In my experience, using strong statically typed functional language and thinking about architecture in terms of types is the best way to get a robust product out fast.

I'm writing spaghetti until it somehow works and then untiying it.

Largest project so far I ended up completely rewriting, also changed from C to Sepples because OOP was superior for the project (embedded HMI). Don't be scared of refactoring spaghetti code. You WILL rewrite stuff anyway as more pieces fall into place.

What I do to plan is write out all the function and class and whatever declarations ineed, and put empty returns or equivalent. That way Im.actually writing code and planning at the same time without worrying about the implementation prematurely.

Don't think on it as a sculpture, think on it as "the shit that will make the shit a lot easier for me later on".

Just write spaghetti and clean it up every once in a while. While it's in development there will always be spaghetti.