Engineer (Eng)

"Do the best work of your life, and enjoy it. If either of these is not happening, bring an axe to work and start swinging."

• Provide the Activity Lead (usually a PM) with realistic timelines and estimates. Remember that a AL cannot dictate a timeline onto you. Revisit your estimates when you get wiser.
• Keep your commitments regarding timeline. Warn the AL early if there is a possibility that you may not make it.
• When doing a code review, take it seriously or refuse to do it at all. Sometimes we don't have time, that's fine.
• Openly voice your opinions and concerns with regard to your tasks. Does something conflict with your moral code? Speak up.
• When specs are unclear, flag this to the AL.
• Send holiday request to the Activity Leads for all the Squads you're on with at least 2 weeks notice.
• Send requests for conference and educational budget to the CTO.
• Keep an eye on your bug:feature ratio.
• Be careful not to accumulate too much code debt. You should negotiate with the AL on this.
• You are responsible for ensuring that what you implement fulfils the requirements. If you are unsure what the requirements are, then talk to the AL before you start implementing. If you see a better way, then talk to the AL. You are not a code monkey, work together with the AL.
• Test your work before you send it to the AL for review. Yes, do this. Seriously. If you don't, you will cause the AL a lot of grief.
• Don't automatically assume that all customers are idiots, they may not be software devs but they generally do know a thing or two about their particular domain. Be prepared to learn from them. Be open to widening your horizons.
• Follow the code style and conventions of the project that you are joining. There should only ever be a single codestyle in a project. If you think that there is a better one, then discuss this with the Tech Lead and broader Squad, but don't just dive in and start writing code in your own style like a wild coyote.
• Adhere the Engineering Manifesto, and suggest improvements to the CTO. You can use your 1::1s for this.
• Inform ALs when their plans are unrealistic.
• Inform ALs when they have gotten brainwashed by the customer and are asking for stupid things.
• Remind ALs that they cannot expect overtime or other heroics from you.
• Inform HoP when you feel exhausted and when you need some recovery time. Recovery time could mean: easier projects, a "new tech" experiment, a holiday etc--there is no prescription what recovery is, but we all know when we need it and it's up to you to voice your needs, which you undoubtedly deserve.
• Make the case to the CTO when you feel like we are not using state of the art tools, and there are better things out there.
• Don't be a code monkey. The PM does not outrank you, neither does the Tech Lead. Negotiate and fight for what you believe is right. The PM is there to represent the customer and facilitate discussions. The Tech Lead is there to maintain technical consistency. Demand discussions.
• Suggest to the CTO that we evaluate promising new technologies, e.g. a new language, framework, technique, etc.
• Know when to use Java and when to use Rust. Know that there is a time and a place for each. The point being that old boring tools are sometimes the right choice.
• Suggest improvements in our process to the CTO.
• Give PMs the opportunity to earn your respect. While you're not expected to give your respect easily, but you are expected to give the PM a chance.
• Ask ALs to fill you in when you feel like you're missing the big picture.
• If you want to, participate in customer facing meetings.
• Never violate your own moral code. Or the company values for that matter.
• If you feel like 9Y is a great place to work, refer your friends to join. If you feel it is not, start kicking and screaming immediately: first to your Team and School Leader. If change does not happen fast, go to the CEO. You are also welcome to use the Feedback System channels.
• Talk to whomever you want to talk to. If you feel like the official channels and company structures are getting in your way of doing good work, let Management know. It's fine if you don't have an immediate solution yourself, just the information that there is a problem is already extremely valuable.
• Remember that you're the one creating most of the value. Unfortunately we need a management structure to keep things organised. But if you feel like the management structure is getting in the way of you doing a great job, then it's your duty to surface that. There are many channels at your disposal and you can choose whichever you are most comfortable with. See Feedback System.
• Organise an immediate strike when the coffee machine is broken.