On the long term I recommend degree. It is good for better career progression, and mandatory in many higher positions.
If you're good enough, and you have a body of work to prove it, you don't need a degree.
1. Develop a consistent coding style. Indentation, variable naming, commenting. There are many schools of thought. If you're writing in a language with a large community, pick a widely represented style convention. If you diverge from that, do so consistently. Space-users aren't going to pass on you for tabs, and vice versa, but nobody's going to be impressed if you mix them willy-nilly.
2. This is the next step up. For the languages you use, understand the conventional ways language features and standard libraries are used. Use them in the appropriate context, don't show your ignorance by not using them where appropriate, use them in a way that shows you understand the performance tradeoffs involved. What makes sense in one language may raise red flags in another (e.g. using lots of exceptions in Python versus using lots of exceptions in C++).
3. Organize the overall project in a way that makes sense. Is the organization of the project in line with the conventions for the language you've chosen? Is it clear how to build and distribute the project?
4. Write something that looks like somebody would actually want to use it. If it's a library, it should have an API without obvious footguns. If it's a CLI program, its arguments shouldn't clash with each other, they should be well-documented and unsurprising in their behavior, and you shouldn't spam the console with status information unless the user has activated a verbose flag. If it's a GUI program or website, value clarity and simplicity over graphical flourishes. You're looking for a job as a programmer, not a designer. Also, make sure the thing you wrote looks like it's actually useful to somebody, even if it's a really specialized audience.
I've only indirectly referred to stuff that gets taught in a traditional CS curriculum, and only in point (2) about performance tradeoffs and appropriate context. But there's a world of important stuff there. Choose a dictionary when you need a linked list, or a linked list when you could use an array, and you showcase your ignorance. Know what these structures are, how to implement toy versions yourself, and when you should use them. (But don't use your toy versions in your portfolio!) Also learn enough about graphs to know one when you're looking at it.
Best of luck!