Rules of Dev

These are the rules that I use while developing and creating tools, I have them written and kept updating them throughout my years of developing since 1997. I want to document them and remind myself of them every now and then.
Rules of developing tools I follow as time and budget permits:

Wearing multiple hats

Does not conflict with "Go Deeper" rule, when you wear multiple hats, you can solve lots of problems faster, its all about the balance between those two rules.

Mar 5th'24

Go deeper when you specialize

The more specialized you become, the deeper you can delve, much like a nail piercing a wall.

Mar 4th'24

Storage is not memory

If device remembers it after you wake it up from restart (or after turning off or remove battery), then it is saved in storage drive, not temporary memory, which means you can access when device is offline.

Feb 3rd'24

Rush = Twice

If you rush it, you will have to do it twice. Going side by side with rule 'Only perfect is good', or something like this post Bathroom twice.

Jan 24th'24

Worst user = Best App

Give me the most frustrated user to test my application (The hardest to please), worst user, I give you the best application.

Dec 29th'23

It is locally saved

If you see it on screen, then it is saved locally in your device. Sometimes the simple rule is the one that is always overlooked.

Dec 16th'23

Smaller targets = Keep developing

Sometimes, if you keep trying to make tool better, you will not deliver. Make tool smaller to deliver sooner. Keep develop other features after delivery and have plans for more versions.

Dec 6th'23

Separate tool from Data

Did not think I need to add this one, but looks like lots and lots of developers are not considering this, it might be because most of current tools are inheritance of Access-DB-Based tools, where you have the data and the tool in one location. Anyways, SEPARATE.

Nov 4th'23

Microsoft Own Best Practices

Found a page about this exact subject Excel VBA Performance Coding Best Practices.

Feb 23rd'23

Programmer ≠ Tester

If you program, do not test; if you test, do not program. Yes, programmer does need to test their code, but that testing is not a replacement of user testing.

Jan 13th'23

User 1st

Seek what is best for user not Programmer. Programmer does need to go the extra mile to make user's life easier. Hate to see those programmers who chose to do certain things the easy way, because it was easier for them.

Feb 25th'22

User-driven UI

User is the final judge, the tool has to be organized, or structured from user perspective, not developer perspective. (more on that later)

Feb 7th'20

Min hardcoded

Minimum hard-coded variables, try to use settings table to allow user to change when needed.

Feb 22nd'22

Only perfect is good

If it is not 100% perfect, it is not acceptable. Only the best solution is good enough.

Feb 7th'20

Smaller = better

Use smaller subroutines or functions, the smaller the better. long subs means bad coding.

Jan 29th'22

Always-Subs

If need to use code more than once, then move it to function or another sub, do not have more than one place for same code.

Feb 7th'20

Always-Variables

If a string or number needed to be used more than once, the use variable, or constant.

Feb 7th'20

Tab = 3

Tab used in alignment is 3 spaces tab

Dec 6th'20

Align, align, align

Alignments to show flow of loops, ifs, withs, etc..

Feb 7th'20

25 spaces

In a statement of LET make sure you had the equal sign at character 25 (mainly in Notepad++ ASP language)

Dec 6th'20


From /Assets/Page-RulesofDev.txt