Company

Remote Working T&C.

Last updated on 14th July 2022.

This is not any kind of legal notice/warning, it is a very friendly note about what we think and believe at “Fusionbit”.

  1. Get paid for hourly*, earn up to 50k per month based on your skills and years of experience on a particular technology and type of project (local/overseas).
  2. Coding time shall be tracked using a time tracking tool called “Wakatime” time tracker** or any other trackers you prefer. Not applicable if following the Agile development process.
  3. Daily commits of code changes on Github/Bitbucket (Without fail).
  4. Weekly reporting via emails. It is always great to summarise what we did and how things are going so that we can realise our own performance and dedication.
  5. Weekly task list sheet filling. We shall share a Google Excel Sheet which will be shared with the developers with editing rights and they must fill the sheet at the end of every week noting down the details of tasks completed in the current week and hours worked accordingly.
  6. Monthly payments***. Invoicing of the prior month shall be submitted within 5 to 10 days of next month. Payments could take up to 10 days for clearance. Only 80% of the amount will be released for a claimed invoice and the remaining 20% will be kept on hold for companies safety purposes and shall be covered in the next invoice consecutively or when a particular developer/company is willing to discontinue working with the entity.
  7. Developers should connect at least once in a week via a video call to give updates on the work they have done, and to show/demo the work completed. (Google meet with screen sharing is preferred [video sharing is not mandatory]).
  8. Developers shall ask questions or shall get help from other developers (if available) in the team on our Slack community, when they get stuck somewhere in the middle of the development.
  9. Learn new things and get in touch with new developers. We strongly believe that communication and sharing your problems or new ideas creates a good bonding with other developers and hence helps in building a great team.
  10. Knowledge sharing sessions on every alternate Saturdays/Sundays. Every developer's perspective is unique in their own way and everyone's coding style is different. There is a lot to learn for a different type of developer with different kinds of mindsets. So it is always a fun to learn new things and share new ideas in the team.
  11. Get the opportunity to work on projects you like. “Fusionbit” offers you an opportunity to work freely and work on things you like or are confident about. So keep exploring, keep asking and you will surely get a chance to work on things you like and make you feel happy and proud.
  12. Always work remotely. In this new era of constantly evolving world and people adopting new changes, we all know that many things have changed after 2020 (COVID-19 pandemic). If you are dedicated enough and keen to work in an ethical way, there is nothing which can stop you from earning a good amount of money. So no matter where you are and where you work from you will always keep earning.

*Developers should only consider the hours they spend on coding or testing while working on a particular task. Any extra hours spent for R&D or Googling things they don't know or don't have knowledge/experience about and have to learn it during the phase of implementation will strictly not be considered as working hours. Also time spent on Calls or Remote Connections/Screensharing for discussing anything will also not be considered.

**We strongly believe in an ethical way of working and keeping transparency between developers and our company (“Fusionbit”). We also believe that personal privacy is humans first right and thus we never ask developers for their proof of work via any screen recordings or screenshot taking tools. Time trackers could be optional in some cases.

***20% of the remaining amount kept on hold shall not be released if any of the company terms or policy is violated. Eg: Developer discontinues working on the project without notice, Developer is not remaining in contact via calls or whatsapp or emails, Developer is not committing the code on time, Developer has delegated the work to someone else and is not working by themselves on the project, Developer has shared the code to some other 3rd party entity, Developer is not responding or out of reach for more than 3 days without notice. In such scenarios policy will be violated and 20% of the amount kept on hold shall not be released and the company shall discontinue working with them without any notice.

Sigma Rule

Developers must write clean code with meaningful variable, function and file names. Proper descriptive commenting should be placed for complex codes/logics so that other developers in the team can understand it. A basic architectural design pattern must be used for whatever framework you choose. And always keep the most important principle of coding in mind that is the KISS Principle (Keep It Simple Stupid). Keep things simple and avoid unnecessary complexity.

Coding Standards

Break functions/methods more than 10 lines of code

Long functions are hard to read and debug, and 10 lines is usually a good point to break the function into smaller parts. Smaller functions are easy to read and review. You might even want to convert a series of functions into a class so you don't need to pass parameters through all of them.

As Steve McConnell and Bob Martin say (two pretty good references on coding best practices), a method should do one thing and only one thing. However many lines of code it takes to do that one thing is how many lines it should have. If that “one thing” can be broken into smaller things, each of those should have a method. Good clues your method is doing more than one thing:

  • More than one level of indentation in a method (indicates too many logic branches to only be doing one thing).
  • “Paragraph Breaks” — whitespace between logical groups of code indicate the method is doing more than one thing.

Commit Messages

Commit messages must follow the conventional commit specifications (conventionalcommits.org).

Code Comments

While we believe that code should be written in a self-explanatory way, comments will go a long way in expressing why the code is written in a particular manner.

We don't expect heavily commented code, but some explanation of what a method does is required. Read this post on why code commenting is important.

{Happy Coding Life} — Connecting the best developers across the globe.