Brainscape's Knowledge GenomeTM

Browse over 1 million classes created by top students, professors, publishers, and experts.


See full index

Engineering Management Terms > Engineering Terms > Flashcards

Engineering Terms Flashcards

1
Q

Active Days

A

It represents any day where an engineer contributed code to the project.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
2
Q

Active Reviewers

A

The count of active users who actually reviewed a PR in the selected time period.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
3
Q

Avg. Comments per Reviewer

A

The average number of comments per Reviewer.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
4
Q

Avg. Time Merge from Create

A

The average time from a Pull Request creation to it being merged.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
5
Q

Avg. Time Merge from First Comment

A

The average time from a Pull Request first commit to it being merged.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
6
Q

Avg. Time Merge from First Review

A

The average time from a Pull Request first review to it being merged.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
7
Q

Avg. Time to First Comment

A

The average time between when a Pull Request is opened and the first time an engineer reviews the pull request.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
8
Q

Avg. Time to Issue PR from First Commit

A

The average time from the first commit to creating a PR.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
9
Q

Churn

A

A quantified representation of the event when an engineer re-writes their own code shortly after it has been checked in - less than 3 weeks old. A certain amount of Churn code can be expected for any developer.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
10
Q

Comments Addressed

A

The percentage of Reviewer comments that were responded to with a comment or a code revision.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
11
Q

Commits

A

The amount of commits done by the developer.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
12
Q

Efficiency

A

The percentage of an engineer’s contributed code that’s productive, which generally involves balancing coding output against the code’s longevity. Efficiency is independent of the amount of code written.The higher the efficiency rate, the longer that code is providing business value. A high churn rate reduces it.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
13
Q

Follow-on Commits

A

The number of code revisions once a Pull Request is opened for review.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
14
Q

Help Others

A

It illustrates how much an engineer is replacing another engineer’s new code - less than 3 weeks old.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
15
Q

Impact

A

The metric measuring the amplitude of code changes that are happening in a more complex manner than measuring raw lines of code. Impact attempts to answer the question: ‘Roughly how much cognitive load did the engineer carry when implementing these changes?’ Impact is a measure of work size that takes this into account. Impact takes the following into account:

What percentage of the work is edits to old code,
The surface area of the change (think ‘number of edit locations’),
The number of files affected,
The severity of changes when old code is modified,
How this change compares to others from the project history.

Impact comprises multiple data points that we improve on a monthly basis to provide a metric that translates engineers’ output into both business value and cognitive load.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
16
Q

Influence

A

The ratio of follow-on commits to comments made in PRs.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
17
Q

Involvement

A

The percentage of PRs a reviewer participated in. It’s important to note that this metric is a highly context-based metric. At an individual or team level, “higher” is not necessarily better as it can point to a behavior where people are overly-involved in the review process, but there are certain situations where you’d expect to see Involvement very high, sometimes from a particular person on the team and other times from a group that’s working on a specific project.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
18
Q

Legacy Refactor

A

This metric refers to the process of paying down “technical debt” - and it is, traditionally, challenging to identify. New feature development frequently implies re-working old code, so these activities are not as clear cut as they might seem in Scrum meetings. As code-bases age, some percentage of developer attention is required to maintain the code and keep things current.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
19
Q

Merged Without Rebase

A

The total number of Pull Requests merged without a rebase.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
20
Q

Merged Without Review

A

The total number of Pull Requests merged without a review.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
21
Q

New Work

A

It represents brand new code that does not replace other code.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
22
Q

No. of Comments

A

The total number of comments in all Pull Requests.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
23
Q

No. of Comments Left

A

The total number of comments across all Pull Requests.

24
Q

No. of Reviews

A

The the total number of reviews in all Pull Requests.

25
Q

No. of Reviews Left

A

The total number of reviews across all Pull Requests.

26
Q

PR Comments Addressed

A

The number of comments addressed by an engineer in all pull requests.

27
Q

PR Reviews Addressed

A

The number of reviews addressed by an engineer in all pull requests.

28
Q

Productive Throughput

A

The proportion of code without churn.

29
Q

PRs

A

The number of pull requests created by an engineer.

30
Q

PRs Closed

A

The number of closed pull requests of an engineer.

31
Q

PRs Merged

A

The number of merged pull requests of an engineer.

32
Q

PRs Merged Without Review

A

The number of pull requests merged without review by an engineer.

33
Q

PRs Open

A

The number of open pull requests of an engineer.

34
Q

Pull Request Risk

A

A measure of how likely it is for a particular commit to cause problems. Think of this as a pattern-matching engine, where Waydev is looking for anomalies that might cause problems. Some of the data points for the Pull Request Risk include:

The number of commits,
The size of the commits,
The spread of the changes,
The depth of the changes

35
Q

Reaction Time

A

The average time it took to respond to a comment.

36
Q

Receptiveness

A

The ratio of follow-on commits to comments. It’s important to remember that Receptiveness is a ‘goldilocks’ metric—you’d never expect this metric to go up to 100%, and if you did it’d be indicative of a fairly unhealthy dynamic where every single comment lead to a change.

37
Q

Regular comments

A

Comments that span between 100-200 characters.

38
Q

Responsiveness

A

The average time it takes to respond to a comment with either another comment or a code revision.

39
Q

Review Coverage

A

The percentage of PRs reviewed.

40
Q

Reviewer Comments

A

The number of reviewer comments per Pull Request.

41
Q

Reviewers

A

The number of reviewers per Pull Request.

42
Q

Risk

A

A measure of how likely it is a particular commit will cause problems. Think of this as a pattern-matching engine, where Waydev is looking for anomalies that might cause problems. Here are some of the questions we ask when looking at risk:

How big is this commit?
Are the changes tightly grouped or spread throughout the code base?
How serious are the edits being made — are they trivial edits or deeper, more severe changes to existing code?

43
Q

Robust comments

A

Comments that have a length over 200 characters.

44
Q

Sharing Index

A

It measures how broadly information is being shared amongst a team by looking at who is reviewing whose PRs.

45
Q

Submitters

A

The total number of users who submitted a PR in the selected time period.

46
Q

Technical Debt

A

The amount of refactoring code done by the developer.

47
Q

Throughput

A

The total amount of code of new, churn, help others and refactored code.

48
Q

Time to First Comment

A

The time between when a Pull Request is opened and the time the first engineer comments.

49
Q

Time to Resolve

A

The time it takes to close a Pull Request.

50
Q

Trivial comments

A

Comments that have under 100 characters.

51
Q

tt100

A

The time it takes for an engineer to create 100 productive lines of code (code without churn).

52
Q

Unreviewed PRs

A

The percentage of PRs submitted that had no comments.

53
Q

Without Comments

A

The total number of Pull Requests that have no comments.

54
Q

Without Reviews

A

The total number of Pull Requests that have no reviews.

55
Q

Work Type

A

The highest types of work an engineer is focused on (New Work, Legacy Refactor, Help Others, and Churn).

Engineering Management Terms (1 decks)

Brainscape helps you reach your goals faster, through stronger study habits.
© 2024 Bold Learning Solutions. Terms and Conditions