{: .center-block}*Gift from Google*
{: .center-block}*Gift from Codefresh*
{::options parse_block_html="false" /}
â¤ď¸ **Thank you Codefresh and Google!** â¤ď¸
{: .alert .alert-gitlab-purple .text-center}
The engineers involved have agreed that this extremely generous gift from Google will be spent on [sponsoring Rails Girls events](https://railsgirlssummerofcode.org/campaign/). But the cookies were obviously eaten by the one who grabbed the pack! đ
Needless to say, some special **thank you** swag is on its way to these amazing people that took the time to come to our boardroom and try to help us feel a bit better.
## GitLab Values
At GitLab we think that the people making the most mistakes frequently correlate with the people doing the most work. I certainly make a lot of mistakes every day. It is important not to double down on them but to acknowledge them and learn from it.
We make mistakes. What's different from person to person, organization to organization, is how to deal with them. What we [value](/handbook/values/) most at GitLab is:
> - _**Transparency**: "Don't be afraid to admit you made a mistake or were wrong. When something went wrong it is a great opportunity to say 'Whatâs the kaizen moment here?' and find a better way without hurt feelings."_
- _**Collaboration**: "Say sorry if you made a mistake apologize. Saying sorry is not a sign of weakness but one of strength. The people that do the most will likely make the most mistakes."_
- _**Behaviour**:_
- _Be truthful and honest._
- _Be dependable, reliable, fair, and respectful._
- _Be committed, creative, inspiring, and passionate._
How could we value transparency if our team members were afraid of assuming their mistakes?
> _It is not our intent to have one of our team members implicated by the transparency. (...) We are very aware of the stress that such a mistake might cause and the rest of the team has been very supportive. (...) We recognize the risk to the company of being transparent, but your values are defined by what you do when it is hard._ [Sid Sijbrandij, CEO](https://news.ycombinator.com/item?id=13622645).
## Team-member-1
While we were putting the fire out, we received this comment:
> _The GitLab engineer (team-member-1) is one of the smartest people he's ever known - in fact, he's actually brilliant. So you can rest assured that the data loss wasn't caused by a an inexperienced kid._ ([HN](https://news.ycombinator.com/item?id=13621016))
And this thoughtful tweet:
Reasons
{: .panel-heading}
_Following what is expected out of a Senior Developer in the [job description](/job-families/engineering/developer/):_
Senior Developers are experienced developers who meet the following criteria:
1. **Technical Skills**
* Are able to write modular, well-tested, and maintainable code _- I think this is out of the question here and we have enough samples_
* Know a domain really well and radiate that knowledge _- He already got a bonus for how he shares his knowledge, he is always raising the bar here._
* Contribute to one or more complementary projects _- His contributions are numerous to all the GitLab ecosystem, including building the whole [performance monitoring metrics](https://dashboards.gitlab.com) system that we use to understand why GitLab is slow. Including projects like [allocations](https://gitlab.com/gitlab-org/allocations) that is used to track low level Ruby metrics_
2. **Leadership**
* Begins to show architectural perspective _- He is involved in [Gitaly](https://gitlab.com/gitlab-org/gitaly) since before it had this name, and architectural paradigm change that will affect GitLab profoundly. He is also heavily involved in [whatever goes near the database](https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/6292)._
* Proposing new ideas, performing feasibility analyses and scoping the work _- This is what he is doing all the time, all of GitLab development community values his input and his opinion is highly valued._
3. **Code quality**
* Leaves code in substantially better shape than before _- Agreed, he does this. Refer to the links provided at the bottom_
* Fixes bugs/regressions quickly _- He has even performed there operations in production itself providing hotfixes._
* Monitors overall code quality/build failures - _[MR](https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/7310)_
* Creates test plans -Â _[MR](https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/8191#note_20300210)_
4. **Communication**
* Provides thorough and timely code feedback for peers - _Refer to code quality section._
* Able to communicate clearly on technical topics - _He created our [performance](http://docs.gitlab.com/ee/development/performance.html) and [sidekiq](http://docs.gitlab.com/ee/development/sidekiq_style_guide.html) style guidelines -Â Both these samples are pushing for improving the quality of GitLab as a whole, way beyond the scope of a single MR._
* Keeps issues up-to-date with progress _- He is a bar raiser here, check any of his issues, they are up to date all the time._
* Helps guide other merge requests to completion - _He does this leading to a [successful](https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/7121) merge and has the capacity to [reject MRs](https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/8044) depending on how they will impact GitLab (another sample on pushing back can be found [here](https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/7067))._
* Helps with recruiting _- He is currently helping me to find a database specialist by reviewing job applications performing the initial filter._
5. **Performance & Scalability**
* Excellent at writing production-ready code with little assistance _- He has been leading the performance effort for the last year, I think this is out of the question - He owned moving to postgres 9.6 on his own, a massive undertaking that was performed without a single glitch._
* Able to write complex code that can scale with a significant number of users _- Same thing as before, he is the one paving the path for the rest of GitLab in this area. Definitely a bar riser._
_A final sample can be found [here](https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/8191/diffs#note_20288482)Â where one of our backend leads asks him for support on how to perform a large migration without causing downtime._Â
_These samples are just the tipping point the work that he has been performing for quite a while already. This work got us to the situation where we can deploy the application with minimum downtime, even adding [automation to detect when a migration will force us to cause downtime](https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/4911), removing human judgment from the equation._
_His work is constantly impacting all the company in both depth and breath, I can find lots of samples on any of the items that are included in the job description, I can even find samples that match to the staff developer. Therefore I think that he has been behaving as a Senior Developer, and I ask that this behavior gets recognized and formalized by GitLab._