Internal SOPs

Management Standard Operating Procedures that keep us running smoothly

Frequent Commits:

It's not good to push code only at the end of full task completion, rather you should keep committing/pushing code in between small changes of your task. For example, in case of a Users CRUD, once you complete its index page with backend controller just push it, then once you complete Create page with backend just push it and so on.

Commit descriptions:

Make your descriptions meaningful. There’s nothing more frustrating than looking for a team members change from 2 weeks ago, and finding it hidden in a commit labelled “minor changes”. Describe what the code change does. Is it UI or Controller? Is it a Model or a Migration?

Include Commands in the description to help team members:

If your commit requires other members of the team to run a new command after pulling your code, help them by adding this at the end of the commit description. Always use square brackets and capitals. Eg. [MIGRATE] or [COMPOSER INSTALL] or [RESEED]

When your team mates pull your new code, they can quickly see what extra steps are required.

Continuous and Real-Time tracking on invoices.larasoft.io:

Keep your time tracking diligently. Make sure you add the task you are working on in the correct Project. Use the Play/Stop buttons at the start and end of the time you have worked on the task. You can manually edit the time if you have accidentally left it running. It’s not good practice to work the full day then add the time manually at the end. It leaves too much scope for errors and inaccuracy. If you need to add lots of time manually, speak to Fahad.

Track in the correct Project:

Projects are sometimes split into “[Name] - Fixed Price” and “[Name] - Per Hour”, so make sure you are clear if the task is billable to the client or it should be included as part of the original specification. In general, if a task was part of the original specification, or is a bug as part of the original specification, it should be included in a Fixed Price. If it is outside the original specification, or is a major change from that specification, then we will agree with the client that it is a “Change Request” and that they will be billed separately for it.

Hours in the Fixed Price = Not billed to the client.

Hours in Per Hour = Billed to the client at the end of each week.

Mark tasks as completed

If you have completed a task, please mark it as competed. This will greatly reduce the steps at the end of the week to generate client’s invoices. It also keeps the project space clean and easy to read.

Detail Detail Detail.

Take care and pay attention to the detail of your work. If a client has made some specification then you must follow it exactly. That includes any UI design that they have given you. The client will be frustrated if you submit work that does not look like the designs they have given you, or if you change something even slightly. If you think there is a better way to handle something, then submit your insight to the client for consideration. You will have lots of experience to provide insight into the best ways to handle something, but if the client is not involved in the decision making, it will look like you have not followed the specification.

British English vs American English

Be aware that there are different customs in British English and American English. They differ very slightly. Be aware of where your client comes from, are they US based, or Europe based? Australia & Europe will generally follow British English customs.

American English has spellings like Color, Humor, Apologize and Customize.

British English has spellings like Colour, Humour, Apologise and Customise.

American English follows date formats like mm/dd/yyyy

British English follows date formats like dd/mm/yyyy

This can be very confusing when presenting a date like 01/02/2020. Is this 2nd Jan or 1st Feb?? It depends which country your client lives in!

API Keys and other Variables

ALWAYS ALWAYS ALWAYS – load API keys from the .env file. There is no exceptions, not even for development. Never hardcode an API key inside a .js file or a component file. One day, you will deploy that application to the client’s Live Server, the application will be large and complex, and you WILL NOT remember where all the API keys are located. You will one day forget an API key, and your demo keys will be mistakenly left on a Live Server… big problems will ensue and many hours of sleep will be lost….

This is why the .env file exists! One simple place to change all the keys from test/development/sandbox accounts, so that your client can use the APIs and third party services without demo restrictions.