Lunr Management Model and Employee Handbook
  • 👋Welcome to LUNR!
  • About us
    • 🚀Vision, Mission & Focus
      • Vision
      • Mission
      • Pillars
  • How We Make Decisions
    • 🚀Strategy
      • Context, not control
      • Strategic management
      • Culture code
    • 🏹Leadership
      • Managers
      • Tech leads
      • Traits of leadership
      • Leaders Performance
    • 👭Team management
      • Team Structure Designed for Success
      • Embracing Effective Ceremonies
      • Strategic Sessions: Empowering Innovation
  • How we build processes and a great product
    • ⚙️Operations and roles
      • How We Navigate Growth and Complexity
      • Our Responsibility Assignment Matrixes: RACI & CODE-KS
    • 📚Knowledge management
      • Knowledge Categories
      • Knowledge Accountability Index
      • Confluence
      • Learning day
      • Company Knowledge Centricity Level
      • Realms
    • 👨‍💻Engineering culture
      • Engineering culture
      • Team culture
      • Engineering Process and Roles
      • Team Events and Processes
        • Scrum Events
        • Ongoing Meetings
        • Concepts
  • How we ensure people’s growth
    • 📈Performance
      • Paths
        • Individual Contributors Path
          • Individual Contributors Levels - Software Engineering
          • Individual Contributors Steps
        • Management Path
          • Level 1 - Our Pace setters
          • Level 2 - Our Coaches
          • Level 3 – Our visionaries and servant leaders
          • Level 4 – Our transformational leaders
          • Key concepts
      • Performance evaluation
      • 360 Evaluation Matrix
      • K-POC
      • CAP
      • Management Model Golden Rules
    • 💰Compensation
      • IC Frameworks
        • 👨‍💻Android Development
        • 📱Android OS Development
        • 🔐Assets security
        • 👨‍💼Business Development
        • 📧Digital marketing
        • 💻Front-end web development
        • ⌨️Full Stack Web Development
        • 🏢Facility cleaning
        • 🔑Information security
        • ↗️Marketing automation
        • 🐞QA automation
        • 👾Quality assurance
        • 🧍Recruiting Operations
        • 📖Technical Training
        • 🤦Technical recruitment
        • 🤖WordPress Developers
        • 👩‍🎨UX/UI
      • MGT Frameworks
        • 👨‍💻Application support management
        • ➗Accounting&Finance Management
        • 👯HR Operations Management
        • 🔒Information Security Management
        • 📧Marketing Management
        • 📞NOC&Support management
        • 🚵Operations management (logistics)
        • 🤦‍♀️Operations management (administration)
        • 🖥️Product owner
        • 🔩Product Engineering Management
        • 🤝Product Marketing Management
        • 👨‍💼Project Management (Business)
        • 👨‍💻Project Management (Software)
        • 🛒Sales Management
        • 📳Software Engineering Management
        • 🌟Strategic Business Development Management
        • 💟Strategic Human Resources Management
        • 🚟Supply Chain Management
        • 👌Technical Account Management
        • ☎️Technical Support Management
        • 📜Technical Training Management
    • 🌟Empowering Growth through Transparent Management: Your Path to Success
  • Policies
    • 🎹Internal rules
      • Employee Probationary Period
      • Employee Code of Conduct
      • Physical Access Control
      • Cybersecurity and digital devices
        • Internet usage
        • Cellphone
        • Corporate e-mail
        • Social media
        • Conflict of interest
        • Workplace measures
        • Employee relations
        • Solicitation and Distribution
      • Substance Abuse and Drug Testing Policy
      • Employee Attendance and Working Hours Policy
      • Shiftwork Policy
      • Overtime policy
      • Employee Time Off Policy
      • Remote office policy
      • Smoke-free office policy
      • Employee Referral Program Policy
      • Moonlighting Policy
      • Anti-discrimination Policy
      • Violence In The Workplace Policy
      • Workplace Harassment Policy
      • Source Code Policy
      • Data Protection and Privacy Policy
      • Employee Confidentiality Policy
      • Business Trips Policy Policy
      • Company Equipment Policy
      • Event Participation Policy
      • Training Benefit Policy
      • Termination of Employment Policy
      • Disciplinary Action Policy
      • Corrective Action Plan (CAP) Policy
    • 💵Salaries
    • 📖LUNR knowledge
    • 🧙Sources
    • 📑Glossary
  • ©️License
Powered by GitBook
On this page
  • Coding Standartds
  • Code Reviews
  • Architecture
  • Programming Language
  • Testing
  • Build vs. Buy
  • Security and Data Privacy
  1. How we build processes and a great product
  2. Engineering culture

Engineering culture

PreviousEngineering cultureNextTeam culture

Last updated 10 months ago

Engineering Culture values derive from Company culture and Agile Software Development values. We believe they complement each other in the right way and enable us to create innovative mobile devices that people love while ensuring the highest standards of privacy and data protection. We seek to push the boundaries of mobile technology to achieve new and exciting advancements. We automate and continuously integrate to make our products great.

In Agile way of working, we value:

  • Individuals and interactions over processes and tools

  • Working software over comprehensive documentation

  • Customer collaboration over contract negotiation

  • Responding to change over following a plan

That is, while there is value in the items on the right, we value the things on the left more. You can find more information about the twelve principles of the Agile Manifesto (written above) . In Software Engineering there are two teams: Quality Assurance and Software Development. The Development Department is divided in two teams that need to deliver features every release cycle - Feature OS Team and Apps Team. We use the Scrum Framework for the Apps Team. It is a framework within which people can address complex adaptive problems, while productively and creatively delivering products of the highest possible value. The essence of Scrum is a small team of people - Apps Team - Scrum, and their associated roles, events, artifacts, and rules. The team is highly flexible, adaptive, and collaborative. Our talented engineers are at the cutting edge of driving our business forward with advancing technology. Building great software is as much about behavior as it is about coding. Our engineers are responsible for more than just coding. To create excellence requires a commitment to and ownership of the development processes. By committing to this Engineering Culture, we can perform better and achieve so much more together.

Coding Standartds

  • We follow the general Android coding style (default for Android Studio which is listed in the )

  • We follow the Android Naming convention and naming conventions provided by Java/Kotlin coding standards.

  • We format code and file structure using "ctrl + alt + L" everywhere so that the code remains consistent and easy to understand.

  • Commit naming – the name must contain the task number, and it should briefly explain the implementation or problem it fixes.

Code Reviews

  • At least two other developers must review each commit before it is tested.

  • If the scope of the review is too big, we estimate additional time.

  • During the code review, all Unit tests should be passing. They are automatically run by Bamboo, and prevent in Bitbucket a pull request to be merged.

  • Each review should focus on evaluating code quality. If you are reviewing a fixed bug, the solution should be the simplest one.

  • If a bug requires refactoring or a change in design and architecture, it should be planned separately as an improvement.

  • If feature implementation is reviewed, the reviewer should make sure he/she knows the implementation logic. Check it covers all the acceptance criteria.

  • Code reviews are done at the start of each working day to avoid disrupting other daily activities. Items should spend the minimum possible time in the "In Review" stage.

Architecture

  • We aim for scalable, easy to explain and support, design of architecture without implying over-engineering.

  • We follow SOLID principles and Clean Architecture patterns. We meet and present the new plan, and if it has any team dependency, the team is asked to join.

  • Everyone is welcome to share an opinion regardless of seniority.

Programming Language

  • We prefer to use known and proven languages.

  • We explore new options but only implement them if the benefit is confirmed and if maturity is high enough.

Testing

  • We follow TDD, so each new feature must be tested. Our goal is 100% test coverage of new features so each merge request goes through QA.

  • Everyone is responsible for the quality, and this starts from the planning stage, goes through development, and ends up with testing.

  • Each team member tests their work before handing it over. This way we can ensure no time is wasted on small defects caused by underlooking a ticket.

Build vs. Buy

  • We prefer to build most of our environment and tools.

  • Buying sometimes requires a higher investment than just the price of the tool.

  • A key concern is our customers' privacy, and we cannot rely on others to protect that.

Security and Data Privacy

  • User privacy is a core goal.

  • We do not store private information or take information without first requesting it.

  • When we need user data, we have to request permission first to the user and bring awareness to him/her of the need behind this request.

👨‍💻
here
Android website