Summary
Hello there! I'm Vitor Britto, a Senior Software Engineer based in Brazil with over 15 years of experience in the software industry. I'm passionate about improving skills, learning new technologies, enjoy influencing others and always advocate for technical excellence while being open to change. I have strong experience building SaaS applications and developing software products.
🚀 Feel free to visit my personal website: https://vitorbritto.dev
- A personal Framework with approaches and methods that I use to delivery high-quality softwares.
- Tools that makes my Workflow easy.
- My own code conventions, which is inspired by what is popular within the community and flavored with some personal opinions.
- Major dependencies that I use.
-
Apply rules and be based on a principle and methodology of process which could maintain the structure of my standards.
-
Not only have a code style guide, but relevant informations about my Workflow. Thus I always keep the same logic process and can initiate the development of my projects without any questions when making a scaffolding, building process, automation rotines, unit testing and others tasks.
You can find a complete list of applications, utilities, DevOps and Business Tools here:
This is a simple table with approaches and methods that I use at my Workflow lifecycle.
| Plan | Design | Develop |
|---|---|---|
| Research | Concepting | Scaffolding |
| Observe | Prototype | Coding |
| Understand | Refine | Build |
| Analyze | Style Guide | QA |
| Timeline | Approval | Deploy |
- Obsidian - To take notes of everything
- Trello - Task Management for projects
- Linear - For Issues tracking, Roadmaps and more
- Google Meet - Business Conferences and Chats
- Slack - Team Messaging
- Whimsical - For ideas, mindmaps and more
- Figma - Prototyping and Layouts Presentations
- Miro - Used for System Design Diagrams and Flows
Check the Kickstarts organization where I organize and setup my stacks for every kind of project. It's a initial structure and configuration where I can start coding in a few minutes.
| Frameworks | Libraries | Tests | DevOps | Css | Others |
|---|---|---|---|---|---|
| React Native | React | Jest | AWS | Sass | Typescript |
| NextJS | Mocha | Docker | PostCSS | Parcel | |
| ExpressJS | Cypress | Serverless | Tailwind | Webpack | |
| NestJS | Appium | Styled Components | Rest API | ||
| GraphQL |
... and much more!
For web projects in which I work from planning to delivery, I use the guides below. If I am on a team that already has established guides, I'll follow the rules already adopted.already adopted. No bullshit, just follow the rules.
- [STRATEGY]: Kanban and/or Scrum method.
- [DEVELOPMENT]: Clean architecture, Clean Code and The Twelve-factor app
Be Consistent
The point of having style guidelines is to have a common vocabulary of coding so people can concentrate on what you're saying rather than on how you're saying it. We present global style rules here so people know the vocabulary, but local style is also important. If code you add to a file looks drastically different from the existing code around it, it throws readers out of their rhythm when they go to read it. Avoid this.
MIT License © Vitor Britto