Overloading the User record
New Bubblers almost always try and save as much as possible on the user record - every tiny bit of data that comes to mind, they add a field on the user.
The problems with this:
When you’re maintaining or building on your app, having tens of fields on the user record can be overwhelming, confusing, and can lead to duplicate fields because there are just so many fields to sift through. Every field on the user record downloads to the user’s browser on every page they land on. Typically, you just don’t need all that data in order to operate a page, so but you’ve got it, regardless. This can slow down your app, and potentially create security risks (especially if tight privacy rules aren’t set up). What to do instead:
Create new data types for things that are not actually about the user. For example, “Company Name” shouldn’t live on the user. Companies should have their own data type. Create to store data about the user that’s not “core” stuff. For example, if you want to save “onboarding” details - like what steps they’ve completed, and when they finished - create a “User Onboarding” data type that holds that information. Once they’ve onboarded, you never need that information again - and you especially don’t need it every time a user visits a page - so save it somewhere else. Fear of creating new data types
New Bubblers seem to believe it’s a bad practice to create lots of data types. The root of this thinking isn’t totally off-base - you don’t want to just create random crap in your app. The important thing is to be thoughtful about what you’re creating.
The problem with this:
You end up with monster data types with tonnns of fields that are impossible to keep track of. Because it’s so hard to see what you’ve got, people end up creating duplicate fields and creating dangerous data redundancies in their apps. What to do instead:
Before adding a new field, ask yourself - “Is this field really about the [User/Project/Whatever]?” - of course, it’s probably related, but if it’s not REALLY about that thing. Then consider creating a new data type to hold that information. Know that there is no limit on the number of data types you create, and it’s not bad to have a lot, as long as you’re intentional and thoughtful about what you’re creating. Overuse of Text fields
New Bubblers often save things like statuses, user types, or addresses in text fields.
Why this is a problem:
Text fields are prone to typos. If you want to show a list of projects where the status is “Done” - and you’re looking at a text field for that status, you are bound to have a bunch of mistakes. Especially when you forget in one of your workflows that “Done” is the word and you use “Complete” instead. Sometimes a text field is just the wrong type! Saving an address or a city? That should be a “Geographic Address” field, which pulls from Google’s database. A text field is useless for something like this. What to do instead:
Create an Option Set for reusable values like statuses or user types. It’s impossible to make a typo when you’re selecting from a list! When you’re creating a new field, take a peek at the “Field Type” dropdown and see if there’s a better option. If you’re saving a number, that should be a number field. Dates? Date field. Etc., etc. Using “list” fields to relate two records, instead of “Junction Tables”
There is a big ol’ write-up of one example of this here: . Take a look. Using the record’s Unique ID to create a relationship
This usually happens when a Bubbler is coming from the traditional coding world. If they want to say “This User is the owner of this Project” they add a text field on the Project record and put the User’s unique ID in the field.
Why this is a problem
This is just not how Bubble works. In order to get this to function (close to) properly, you end up running multiple searches, when you might not have needed any. This can cost you way more than you needed to spend, and can significantly impact performance. What to do instead
When you’re creating the field that stores that relationship, look through the “Field Type” dropdown to find the data type (or Table, as they call it in trad code) for the other record you’re relating. Trying to relate a User? Select the “User” field type. Then in the workflow instead of saving the User’s ID, just save the User itself. Random Naming
This isn’t just a thing for new users. Very seasoned developers do this to... They just name stuff without really thinking about it. Often it’ll be vaguely meaningful, or not meaningful at all. Or it will make sense to them in some way, but be totally confusing to anyone else.
Why this is a problem:
Without intentional, thoughtful naming, your app will be totally indecipherable to anyone else. When your app grows beyond you, and you need to bring on a new developer, it’s going to take them SO much longer to get oriented than if you had sensible naming. You’ll forget stuff! This scenario happens all the time: you go looking for something in your app, and you can’t find it because it’s named something weird, and then you create it again. Now you’ve got the data stored in two different places and you don’t know which one is the “source of truth.” If that goes on for long, you can end up with a MAJOR mess to clean up. It’s just slow to build this way. It’s impossible to keep an entire app in your head - you WILL forget things. And when you do, you’ll spend way more time hunting for things that the time it would’ve taken you to think it through when you first added the field or the data type. What to do instead:
Before you add a data type, field, or option, stop and think “Is this naming vague? Could it be confused with something else?” If yes, try again. Also - and this is important! - ask yourself “Would someone else know what this means?” and “Could someone else guess what I’ve named it so they could maybe know where to look to find it?” If you answer “no” to either of those questions, try again. If you’re not sure, ask another Developer to look at your Data Types and fields and tell you what fields or data types are confusing. More about naming conventions here: 
Common Beginner Mistakes
