| Good question! - Transparency about the work.
(Communicate progress without being prompted. Share screenshots & be excited about what you develop!) - Don't be a hero. (If something is difficult, collaborate with the team and don't go it alone.) - Be minimal. (Development is an additive process, and it's easy to "chrome plate" a development story. Be minimal and discuss above & beyond opportunities with the team before working on them [or just create a ticket for later discussion].) - Don't compromise quality. (It's easy to want to skip tests or refactor later, but that carries invisible costs & churn during PRs.) - Refactor as you go, but don't over do it. (Nobody likes a 1000 line PR. A major refactor means large code change [risk], large review, churn on correcting the PR, long time before feature is merged, ...) - Solicit feedback when you do want to cut corners. (Explain what the cost is in a quick implementation and why it's a good idea to implement minimally at this phase. Identify ways to mitigate risk / make refactor simple later.) - Don't overwork. (Developers tend to work harder in off hours and burn themselves out. What they don't realize is that their total contributions to the team go down significantly when they overwork.) - Be honest. (In a team development setting, some folks will communicate that they're further along on a story than they actually are, with the intention of making up the development effort. This causes overwork -- and the rest of the team can pick up on the dishonesty. I would rather have a member of my team say that they're having an issue with solving a problem [or there are external life factors] than feeling like they have to go it alone.) - Ask for what you need. (Organizations can easily pull developers into meetings and monopolize their time. Push back and ask for focus blocks.) - Be candid in retrospectives. (It's the one venue where management is literally asking you what could be better. So many times, people are waiting for someone else to speak before they voice their opinions. Have a conversation with a team member before retro to validate your opinions if you are self-conscious about them.) - Be candid in 1:1s with your management. (Typical management will lose the developer perspective and rely on feedback to be able to adjust team policies. If there's no feedback, then problems fester.) -- I get that this list leans on being extroverted -- and that some folks are introverted. It's totally a vulnerable position to put your hard work / opinions out in front of a team for review. It's even more intimidating (impostor syndrome) when you're working with really smart people. A good manager will mentor their staff on how to follow through on these expectations, and will also actively work to make the team environment a safe space for constructive conversation. There's a lot more micro nuance depending on the team and business environment, but generally, I believe this is a good starting point. |