Expectations of an engineer === ###### tags: `beginner` Writing code is not the only task of a good engineer. An awesome engineer has two types of skills. 1) Core skills (often referred to as "soft" skills): self-management, proactivity, interpersonal communication and problem-solving/unblocking. 2) Technical skills: knowledge, speed and expericence in specific technologies and practices. Here is a collection of key elements that defines what being an "Awesome Engineer" means in MonstarLab. ## Quality is... **... you deliver something that is done** In order to be effective and to deliver projects of high quality to our clients, it is important that a ticket is in fact done when it gets marked as done. This means, ensuring that it works (doing a bit more testing than a quick happy-path test), that it is implemented according to the user story and acceptance criterias and the provided UI design. Finally automated testing and documentation has been considered as well. **... you follow the platform standards** Each platform spend time on improving the work they do each year by looking at their tools, processes and standards. It is important to learn from our experiences and to align with the standards and processes that has been set forward on the platform (e.g. code modes). Following the standards will make it easier to work on projects across offices and make it easier to help improving the standards moving on. **... you develop as a professional** Being a professional developer is not only about being able to solve complex challenges for a project. It is also about making sure that you write proper and meaningful commit messages, that you follow our branching strategy and that you are able to make meaningful release notes. Another thing to avoid is to have unprofessional comments in the code and using test data that is inappropriate. **... you document your work** Documentation might not always be the most exciting part of being a developer and it can feel a bit pointless at times. However once a codebase is being handed over to a client or if another Nodes developer is being onboarded, proper documentation can be a great help. Write the needed documentation for the project and make sure to get the time allocated that is needed in order to do so. **... you test your work** Writing the amount of tests that is fitting and expected for the project can be central in order to deliver a successful project within the given timeline. It is also a great way to spot regressions after the project has gone live and it makes refactoring a lot easier. ## Ask for... **... help** **Asking for help is encouraged.** We’re a big team of many skilled developers, designers, QA-ers and more, so don’t be scared to ask. Make use of the team (#android, #ios..) or general (#developers) channels, write people directly or just come in person. There is no shame in asking. **... clarification** **Assumptions create misunderstandings** - ask for clarification whenever you’re unsure. An informed decision makes everyone’s life easier and ensures that expectations are met. Utilize people involved in your project or more experienced colleagues, both developers and consultants. **... more time** Don’t be afraid if you can’t meet an estimation - it is an estimation after all. Over-promising or sugar coating will only put more stress on you and the project. Being honest and open is the way to go. When you know or think there won’t be enough time to finish something make sure to tell the project manager as soon as possible (e.g. at the standup). ## Say when.. **... you want to pair program** Unsure about how to implement a feature? Never done something you’ve been assigned? Want to validate your logic? Go to your teammates and ask them to pair program with you on the task. The amount of time saved and knowledge gained is always worth the extra time. **... things are not right** If there’s something wrong, the best way to fix it is to say something. Speak to the project manager, the head of your platform and/or your manager. It doesn’t matter if it’s a technical issue or a personal one - when things are not right it’s important that we fix them. **... you’re given a task out of your skillset** It’s entirely fair to admit that a task is not within your skills or responsibilities and that you believe it should be assigned to someone else. ## Considerations **Keep confidential information confidential** On some of the amazing projects we work on we are required to keep the information confidential at least for some period of time. Make sure to check with the project manager/consultant first before you share any project specific information that could be confidential. **When and who to ask** Asking is encouraged, but it is also important that you understand who to ask and when. Before asking, think about if the person you’re asking is the one who could have an answer and also take into account how busy they are. If a question could be considered as not being time critical, then consider for example writing on Slack or through an email. ## Part of a project **Keeping yourself occupied** Even though we spend a lot of time trying to clarify, validate and prepare a project to be executed by the project team, there will be times where you are blocked by someone else. It’s important that you’re able to focus on other project-related tasks in those cases. These tasks could be working on the CI, going through the design, setting up NStack or working on other modules for the project.