About Engineering

Welcome

Welcome to Engineering Handbook!

• This page is the main page of the Engineering Handbook. And it is expected to provide all the answers you are want to get. If not, please feel free to submit an issue.
• Want to learn more about the sub-teams? Refering here to get more informations.

Mission

• Research and develop the company's basic platform and framework, so as to improve the efficiency of project development and form the company's technology accumulation and technical reserve
• Research and development of new product design, as far as possible in the fastest time to make the best software, software development control also need to be done in a timely manner, at the same time to prepare all kinds of technical documents, and then distributed to business departments
• To the person in charge of software quality management, do a good job in the supervision of software development process, at the same time, do a good job in the measurement of software development, unqualified products should be controlled in a range, reduce unnecessary losses
• Responsible for technical error correction of quality problems, timely audit and inspection of daily management work in quality management, so as to find and correct errors anytime and anywhere
• According to the situation of the enterprise, we should constantly research and upgrade the products of the enterprise, keep up with the development requirements of the enterprise, take the initiative to formulate relevant plans and put forward new development direction! For the enterprise's technology development, make advance planning!

Engineering Team

Our teams:

• Frontend Team
• 3D Engine Team
• Backend Team
• Algorithm Team
• Dev Sub Team
• UX Team
• Enablement Sub Team
• Fulfillment Sub Team
• Growth Sub Team
• Ops Sub Team
• Protect Sub Team
• Secure Sub Team
• Incubation Engineering Team
• Infrastructure Team
• Quality Team
• Development Team

Prioritizing technical decisions

Despite the high priority of velocity to our project and our company, there is one set of things we must prioritize over it: availability & security. Neither we, nor our users, can run a service if we are willing to risk users' productivity and data.

For security, we prioritize it more highly by having strict SLAs around priorities labels with security issues. This shows a security first mindset as these issues take precedence in a given timeframe.

The Importance of Reliability

Availability/Reliability, Quality, Security, and Performance are the pillars for building reliable software. Reliability is our contract with our customers that say you can count on us to deliver an available and dependable product. Everyone in the organization has a role to play.

Engineers, Product Managers, and Designers have the most direct influence over the reliability of the code through either planning, implementation, monitoring, or prioritization of the work. Product and Engineering management monitors (e.g. Error Budgets) and measures the reliability of features and makes recommendations if necessary. Our focus on learning and development will also ensure that teams have the tools and training required to build reliable software. The Infrastructure, Application Security, Database and Quality teams are the Subject Matter Experts supporting product development teams.

The Importance of Velocity

• Companies tend to slow down as they grow. It takes deliberate effort to prevent this, so it must always be top of mind.
• Once you slow down, it is incredibly painful to speed back up again.

Incremental Velocity and Measurement

Our velocity should be incremental in nature. It's derived from our MVC-based approach, which encourages "delivering the smallest possible solution that offers value to our users". This could be a small new feature, but also includes code improvements, bug fixes, etc.

To measure this, we count and define the target here: Development Department Narrow MR Rate which is a goal for managers and not ICs.

For example, an MR rate of 11 translates to roughly one MR every 1½ business days with time for overhead. To attain this, Product Development Engineers are encouraged to:

• Fix small problems they see in the codebase without an issue resulting in incremental improvements. Small here translates to ½ day or less.
• Fix small bugs (particularly bug::transient type bugs). Small here translates to 1/2 day or less.
• For feature issues, break the issue into several smaller MRs that are delivered incrementally. Small here translates to less than two days.
• Help dogfood a GitLab feature by using it to fix an issue identified within the codebase. As examples, fix code climate issue for one file OR SAST scanner potential errors found.
• Raise concerns for issues where our incremental philosophy does not work and the issue cannot be broken down further.
• Raise concerns for issues that Product Development Engineers do not feel fit the MVC definition.

Follow Established Processes

All team members are expected to follow documented processes. We develop and document processes (for example: Feature flag usage, Code Review Guidelines) through constant iteration and refinement.

Following established processes ensures that we learn from our mistakes and efficiently deliver high-quality, highly performant, and secure software. We prefer to fail fast and learn quickly. Team members who are not software developers benefit from working more efficiently to deliver their results as well. Regardless of your discipline, processes are the guard rails that ensure we produce desirable and predictable results.

Everyone can contribute by proposing new processes and improving upon existing processes.

Balance refactoring and velocity

When changing an outdated part of our code (e.g. HAML views, jQuery modules), use discretion on whether to refactor or not. For long term maintainability, we are very interested in migrating old code to the consistent and preferred approach (e.g. Vue, GraphQL), but we're also interested in continuously shipping features that our users will love.

Aim to implement new modules or features with the preferred approach, but changing preexisting non-conforming parts is a gray area.

If the weight of refactoring and other constraints (such as time) risk threatening the availability of a feature, then strongly consider refactoring at another time. On the other hand, if the code in question has hurt availability or poses a threat to it, then strongly consider prioritizing refactoring. This is a balancing act and if you're not sure where your change should go (or whether you should do some refactoring before hand), reach out to another Engineer or Maintainer.

If it makes sense to refactor before implementing a new feature or a change, then please:

• Create separate merge requests for the refactoring and change. This aids maintainability and code review.
• Notify your engineering manager and relevant stakeholders (preferably in an issue comment) of the relevant scope increase and rationale.

If it is decided not to refactor at this moment, then please:

• Make sure a descriptive "technical debt" issue exists for this refactoring.
• Notify your engineering manager so that the refactoring issue can be weighted and scheduled.

Engineering Demo Process

Occasionally, it may be useful to set up a demo on a regular cadence to ensure cross-functional iterative alignment. This is helpful for high-impact deliverables that require integration across multiple functional teams. This is in-line with the seventh principle of the Agile Manifesto: "Working Software is the best measure of process".

• Record a video on your computer or via Zoom livestream of the working software
• Upload to the YouTube Channel
• Post the YouTube link to the appropriate Lark channel
• Repeat periodically

This process is required to be used by Single-Engineer Groups to maintain transparency and minimal alignment with the rest of Hyletic.

Grading

For multi-person groups or critical projects, we use a heavier weight grading process:

1. The demo owner identifies the outcome of the demo based on the business criteria. This can be an engineering manager, a product manager or someone who is a business stakeholder of the outcome.
2. The demo owner breaks down the outcome into smaller pieces, aligning with functional areas (tracks) and structured in procedural flow. This will later be captured as demo steps.
3. The demo owner identifies a functional team leader as a DRI for each demo track. The DRI for each track is responsible for demoing each track to completion.
4. The demo owner collaborates with functional team leaders to populate the demo steps in a scorecard.
5. The demo owner schedules a regular meeting cadence with a target end date. The goal is to complete all demo tracks before or on the end date.
6. The demo owner identifies a demo master to hold grading accountability. This can be the demo owner or someone who is familiar with the product domain and customers' usecase. It is important that the demo master is someone who can advocate for the success of our users.
7. The demo gets kicked off and each demo tracks iterate each week on the progress until completion.

The demo master grades each step during the demo meeting. To make it less subjective, we use a scale that is widely understood and communicated. Our scoring definitions are as follows:

Score	Definition
5	Signed off from all Stakeholders
4	Demo'd according to the "definition of done"
3	Demo'd but incomplete and/or has bugs
2	Demo'd in some rudimentary state, work has started
1	Not yet started or cannot be demo'd

Iteration

We always push ourselves to be iterative and make the minimal viable change. The image below provides an example of how we should iterate:

Image Credit: Henrik Kniberg from Crisp

When iterating, our goal is to build something quick and functional. In the example above, we should aim to build something that can transport us from A to B even though it may not have all of the nice-to-have features like an engine, seats, or air conditioning.

The example's upper sequence shows how we should not iterate. The problem with going from a wheel to a wheel base to a frame to a car is that the first few iterations are not functional.

The example's lower sequence shows how we should iterate. Building a skateboard is low complexity and can be assembled in a day while building a car is high complexity and takes thousands of parts and a much longer assembly time. A skateboard is not as fast as a car yet it can still transport a person. Each subsequent iteration provides the person with more speed, more control, and a better aesthetic.

One common misconception of iteration is that there is no waste. Using the example above, the parts of a skateboard can be reused in a scooter, however, they likely cannot be reused in a car. Iteration often requires us to throw away product or code to make way for a better product.

Collaboration

To maintain our rapid cadence, we must keep the barrier low to getting things done. Since our team is distributed around the world and therefore working at different times, we need to work in parallel and asynchronously as much as possible.

That also means that if you are implementing a new feature, you should feel empowered to work on the entire stack if it is most efficient for you to do so.

Nevertheless, there are features whose implementation requires knowledge that is outside the expertise of the developer. For these situations, we'll require the help of an expert in the feature's domain.

In order to figure out how to articulate this help, it is necessary to evaluate first the amount of work the feature will require from the expert.

If the feature only requires the expert's help at an early stage, for example designing and architecting the future solution, the approach will be slightly different. In this case, we would require the help of at least two experts in order to get a consensual agreement about the solution. Besides, they should be informed about the development status before the solution is completed. This way, any discrepancy or architectural issue related to the current solution, will be brought up early.

Code Quality and Standards

We need to maintain code quality and standards. It's very important that you are familiar with the Development Guides in general.

Please remember that the only way to make code flexible is to make it as simple as possible:

A lot of programmers make the mistake of thinking the way you make code flexible is by predicting as many future uses as possible, but this paradoxically leads to less flexible code. The only way to achieve flexibility is to make things as simple and easy to change as you can.

Quality is everyone's responsibility

It is important to remember that quality is everyone's responsibility. Everything you merge to master should be production ready.

Engineering Proposed Initiatives

Engineering is the primary advocate for the performance, availability, and security of the GitLab project. Product Management prioritizes all initiatives, so everyone in the engineering function should participate in the Product Management prioritization process to ensure that our project stays ahead in these areas. The following list should provide some guidelines around the initiatives that each engineering team should advocate for during their release planning:

• Review fixes from our support team. These merge requests are tagged with the Support Team Contributions label.
• Working on high priority issues as a result of issue triaging. This is our commitment to the community and we need to include some capacity to review MRs or work on defects raised by the community.
• Improvements to the performance and scalability of a feature. Again, the Product team should be involved in the definition of these issues but Engineering may lead here by clearly defining the recommended improvements.
• Improvements to our toolchain in order to boost efficiency.

Resources for Development

When using any of the resources listed below, some rules apply:

• Consider the cost and whether anything can be done to reduce the cost.
• You can boot up as many machines as you need.
• It is your responsibility to clean up after yourself; if a machine is not used, remove it.
• If you observe any resource that is running for long periods of time, ask the person responsible whether the machine is still in use.
• Prepend your username to any resource you start. Eg. if your name is Jane Doe, name the resource janedoe-machine-for-testing.

Workflow

In order to ensure the smooth progress of work, reduce unnecessary costs, please follow the Engineering Workflow.

Hiring

The recruitment process is assisted by POG. Please refer to here for details of each part

Weight Rule

Weight Level	Range
1	A simple task is not very difficult on the whole, and it is easy to complete; When the task is many and simple, it can be packaged as a weight; A series of common bug fixes
2	There are some difficult technical problems that need to be solved in a little more time; Although not too difficult, but the workload is relatively large; Major and difficult bug fix
3	At present, there is no good solution, we need to try and solve the problem constantly; Complete the important function update
4	Very difficult technical problems; Complete a whole module, including a series of important functions
5	Need to build a complete system; It's very difficult and takes a lot of time; A very difficult and often problematic system