1 2 3 Previous Next 69 Replies Latest reply on Nov 4, 2013 12:20 PM by mikebeargie

    Good developers . . . .

    jbrown

      Hey all,

      I have a strong interest in becoming a good developer. I've read books, spent 100s of hours working with a system. However, as is normal, the more I learn, the more I realize what I don't know. So I'm curious, what do good developers do? I've seen posts here and there about what people do. A few that I've seen are:

      1. Commenting heavily in the script

      2. Error capturing

       

       

      What else? I'm wondering about things that they don't talk about on Lynda.com or in any book out there. What standard practices should I be doing? I am reading on the filemaker standard practices website, but would love to hear from YOU as well.

       

      Thanks

      jb

        • 1. Re: Good developers . . . .
          beverly
          • I run DDR and print (to PDF) all those places that I can, frequently.

          • Also, rule one: backup, move the backup to a safe place before doing anything radical.

           

          I don't know if that makes me "good", I just need to cover my *** mostly!

          Beverly

          • 2. Re: Good developers . . . .
            DavidJondreau

            Don't write code that will break if you change field, table, or layout names.

            -Basically, never put name inside quotes.

             

            Write robust code that you will be able to update easily.

            -For example, using a New Window Handler script instead of a New Window script step. If your New Window process changes (using a modal, moving it off screen, aborting triggers, etc), then you only need to update a single script and not 100.

             

            Commenting layouts, fields, and the relationship graph.

            • 3. Re: Good developers . . . .
              briancrockett

              Make copious notes, not just comments. I list scripts that may be of interest, scripts I've changed and what I did to them and new scripts. I list all TOC's, fields that I may have added or changed. To me a project can be a small update to an existing solution. Most development work is maintenance of existing solutions so it helpful to have something to refer to when you go back a couple years later to make a change. This saves you from having to re-learn the solution all over again. 

               

              I've started using Evernote to make notes on each project that I do, no matter how small.  Evernote makes it easy to search for projects or something in a project. You can insert screen shots or add attachments. Also Evernote is always with you. If you forget your laptop you can login in to the web page.  I keep templates for new projects and paste them into Evernote as required.

               

              Having notes to refer to makes me a hero. If there's a bug or a small change to be made I just look through my notes and I can jump right to the area that needs attention.

              • 4. Re: Good developers . . . .
                TimDietrich

                Here are a few things that I try to keep in mind...

                 

                • Keep things simple, or as simple as you possibly can. That includes the relationship graph, layouts, etc.
                • Don't try to force FileMaker to be something that it isn't. It is a platform designed to help people manage information. Nothing more, nothing less.
                • It's okay to say "no" - to projects, to clients, etc. (And it's especially okay to say "no" if someone is trying to get you to do something that FileMaker is intended for.)
                • Document as much as you can. I'm a firm believer that you can never "over-comment" things. You'll thank yourself for all of those comments later.
                • Get involved in the community (user groups, TechNet, etc). Whether you're learning something or teaching something, it's a win-win either way.

                 

                -- Tim

                • 5. Re: Good developers . . . .
                  TimDietrich

                  Brian --

                   

                  It's nice to hear that another FM developer is an Evernote fan. Like yourself, I use it to store project notes and screen shots. I'm also using it to store PHP code snippets, client notes, meeting notes, ideas....

                   

                  I can't live without it - and hopefully I won't ever have to!

                   

                  -- Tim

                  • 6. Re: Good developers . . . .
                    briancrockett

                    I've learned a few tricks to Evernote like editing the HTML so I can make custom tables.

                    • 7. Re: Good developers . . . .
                      Stephen Huston

                      One concept that I rarely see mentioned on TechNet has been really important in my FM work:

                      • Figure out at least 2 ways to solve a problem before  implementing a solution. (Three ways is even better.)
                      • One simply can't chose the better or best way of doing something if  only  one method is known, and FileMaker  affords multiple ways of implementing almost everything.

                      This  also forces one to master more techniques in FileMaker, which allows one to make better choices regarding data structure and process efficiency throughout one's work.

                       

                      [ I know, I know... we all come here for quick answers, or to solve an urgent problem, so quick and easy answers do have their attractions. ]

                      • 8. Re: Good developers . . . .
                        LyndsayHowarth

                        - get a good designer

                        - have a photographic memory

                        - limit scripting & use relationships effectively instead

                        - and as Beverly says "backup" -neurotically.

                         

                        There are many ways to do the same thing... all of which you may use depending circumstances. Get to know which ones you prefer and use the most appropriate for that bit of the job.

                         

                        Let us know when you are up to multiple thousands of hours.... And hundreds of projects...

                         

                        - Lyndsay

                        • 9. Re: Good developers . . . .
                          Mike_Mitchell
                          • get to know their clients
                          • listen to their clients' needs
                          • understand their clients' workflow
                          • advise their clients on the best way to accomplish their business goals (but only after steps 1, 2, and 3)
                          • 10. Re: Good developers . . . .
                            BeatriceBeaubien

                            Hi Jeremy,

                             

                            1. To expand on Bev's last point, working on a local copy is sometimes a good (note, not "best". It depends on the circumstances) practice. If you do, close the file and make backups at every point you would really dislike having to repeat everything you've just done. This is particularly true for seeing if looping scripts work the way you thought they should, and for changes to the schema. I do it at ~20 minute intervals, and always before I test a looping script.

                             

                            If you are working on a file on a server, close the file at regular intervals to make sure all your changes are written to the hosted file before you discover you have lost connection. Also, on a served file, get used to making ad hoc backups during your development day so you can backtrack if you realise you went up the wrong alley.

                             

                            2. Don't be afraid to experiment and fail. And if something doesn't work, test all your assumptions before you ask for help. As flybynight so aptly put it a few weeks ago, we learn the most when we get into the weeds. And getting ourselves out of the weeds is worth a lot more than advice.

                             

                            3. Not only be willing to fail, but stress-test hard before you decide a feature is done. Geoff Coffey summed up one of the principles of any development effort in one of his DevCon presentations. "Fail often and fail early." Don't wait for your users to tell you about it.

                             

                            All the best,

                             

                            Beatrice Beaubien, PhD

                            i2eye, Toronto, Canada

                             

                            FileMaker Business Alliance

                            FileMaker 12 Certified Developer

                            Knowledge Translation Certified Professional

                             

                            On Oct 24, 2013, at 13:52, Beverly Voth wrote

                             

                             

                            created by Beverly Voth in General - View the full discussion

                                 • I run DDR and print (to PDF) all those places that I can, frequently.

                             

                                 • Also, rule one: backup, move the backup to a safe place before doing anything radical.

                             

                             

                            I don't know if that makes me "good", I just need to cover my *** mostly!

                             

                            Beverly

                             

                            • 11. Re: Good developers . . . .
                              jbrown

                              I love your ideas. Thanks for the list.  Any more?

                              • 12. Re: Good developers . . . .
                                Malcolm

                                on a served file, get used to making ad hoc backups during your development day so you can backtrack if you realise you went up the wrong alley.

                                 

                                Or create a schedule that runs frequently while you are working.

                                 

                                Malcolm

                                • 13. Re: Good developers . . . .
                                  wimdecorte

                                  Lyndsay Howarth wrote:

                                   

                                   

                                  - limit scripting & use relationships effectively instead

                                   

                                   

                                  Hy Lyndsay, can you expand on this one, I don't think I understand the &amp reference

                                  • 14. Re: Good developers . . . .
                                    wimdecorte

                                    don't use implicit coding that relies on FM interpreting what you really mean.  Use explicit coding

                                     

                                    So no:

                                    if[ get( founcount )]

                                     

                                    But

                                    if[ get(foundcount) > 0 ]    (or whatever it was you had in mind)

                                    1 2 3 Previous Next