What are some things you wish you knew when starting out with Filemaker?
Is there something you wish somebody would have told you?
Any tips, tricks or just something you found out that you wish you would have known?
(General Discussion)
following from youtube trend, things I wish I knew when I started coding
"I wasn't kidding when I told you to keep things simple."
don't use the TOG for navigation - keep it lean - use it only if no other means get you the data.
also watch the field count - slim tables..
"Don't start until you've drawn it as a picture and can explain it in simple words"
Modelling is such an important part of understanding the problem. Without a clearly defined goal, you working without purpose. Create a plan in advance, it is crucial to good outcomes.
I haven’t seen anyone else say this yet. Document everything. Sit down and describe what you are about to do. That helps you focus. Write a few words on what you have done as you go. Keep track of times too. That helps with billing and in the future with estimates.
A very simple and thorough description of work is a DDR. Make one before you start and one when you finish. The difference is the work you did.
When a user tells you a business rule like "We will only ever do it this way, there will never be an occasion where we need it to work that way", don't believe them. Always build it with the assumption that they are lying and trying to trick you.
You can tell I'm having a fun time with some clients lately.
but how would you know what the "other way" is and if it would be good for the Client?
regards
Kevin
You have to document the business rule, the explicit exclusion, and the apparent limitation. 
Experience usually.
For instance a client says "We want to be able to create a clinic day full of timeslots and they will only ever be between 8:30 and 4:30 on weekdays, that's a guarantee this will NEVER EVER CHANGE" so you create a UI with 5 week days and timeslots in between those times.
A smart man (not me) would think "I bet a year from now they are going to say: 'how come I can't make a saturday clinic that goes from 4:45pm to 6:45pm? It's super crucial and we need it now'"
Something I wish I would have known when I discovered Filemaker in 2013.
This is programming, you will learn the basics and can learn other technologies if you wish. FIrst understand the basics and then see what Filemaker can do !
I see this at Qwasar.io....
Students don't want to join the Claris program because they think its not real coding, or somebody has told them Filemaker is not a programming language....
WISH I WOULDNT HAVE LISTENED TO THE HATERS...
my 2 cents ..
-Drew
If one wants to be very strict, FileMaker does not provide a programming language. It provides a scripting language though. Thing is FileMaker provides to the developer so much behind the scene functionalities, just think about portals, that you can create an app without a single script: that's no coding.
A great lot of people just repeat what they have heard, without ever trying FileMaker. For a long time, FMI/Claris did not understood that they need a good training offer, not books but people that teach the product, people that know the stuff.
Well said, I'm hopeful that is changing.... Through Claris Learning Academy and programs like Qwasar.io....
When debugging scripts written by other developers — especially when dealing with local clients, PSOS, and subscripts — always carefully check the layout and context of each script.
Is the script running locally or via PSOS? Is the focus a layout, a portal, or a line item in the portal?
Don't remember. More than 30 years ago. What I remember: it was big fun to learn Filemaker Plus.
The only important thing I did wrong was, when 7 came out, the correct use of Table Occurrences. It did cost me a complex project to learn to work in blocks instead of an octopus design with 100 arms 
Context is king - everything in FM is all about context. Referencing a field won't cut it by itself; the related context is mandatory to getting correct data represented.
Understanding Table OCCURRENCES and TOGs and relational theory is imperative as well.
This is why I don't take development advice from clients. They can tell me what they want to do, but not how I should do it. Also: one item is a field; two is another table. Always.
watch out for scripts running granted Full Access: Portals might display more lines then the user account supposed to see and the FA script will see them and iterate with its full access all rows' count.
also watch out for data viewer implications when a Let statement involved could set $var or $$var ..
When I finally understood what a Table Occurence is, that was marvelous 
. To sum up, it's a query !
Well, the relationship in a TOG is the actual query, at least until you enter a context of a child table and do a FIND, then all bets are off
Unstored calcs, in most cases, are NOT your friend. They are a great low-code starting point, but are the primary source of performance issues in layouts. Summary fields are another unstored calc, as are HIDE and Conditional Formatting (the latter 2 can be "lighter weight" than data other unstored calcs but not necessarily.
Judicious use of unstored calcs in layouts (seldom in list view), have value, as do certain conditions (an unstored Get (FoundCount) in every table is amazingly useful). There are ways to force trigger an auto-enter on demand, replacing unstored calcs with a far more performant data result.
In recent years - after current self has done much swearing at prior self - I've spent a lot of time unwinding extensive use of unstored field calcs.
Try NOT to incorporate business logic into field level calculations; all attempts should be made to only use field level calculations for data formatting, and data entry management (plus some notable exceptions). Once you start putting business logic in field level calculations, you are starting down the road to maintenance hell.
As each relationship is a query, the more relationships in a TOG, the longer the calculation time will be for FM to evaluate all those queries AND all the field level calculations are are potentially influenced by those relationships. Keep your TOGs small, if you want a performant solution.