I'm a developer team lead. Part of that job is onboarding and mentoring new developers. To save my keystrokes, I'll document here the expectations I have for the fellow members on our team. These include tips for collaborating, career path, and skills. Welcome to the team!
The most important thing to remember while on the team is that software is written for people, by people. Success comes from interactions with people, not writing code. Yes, writing good code is very important. There is a Skills section below dedicated to that. But it is not as important as building good relationships with your team members and other partners.
Be respectful to your team members.
Everyone on the team is working toward the betterment of the product and the company. There will be days when you feel like you are the only one. You'll feel that you are the only one that can see the big picture. It will feel like others are blocking or sabotaging you. However, that is not the case. Understand why you feel blocked or unsupported. Work with others to get at the root of the issue. Find a path forward where all team members can contribute moving in the same direction.
You don't need to agree with everyone's decision, but you do need to support the team decisions that are made. Although you might not agree entirely with the decision, you should be able to describe the pros of why that decision was made. Don't try to undo and revert that decision at every opportunity.
You don't need to like everyone on the team, but you do need to respect them. There is a natural bias towards liking the people that always agree with you. That bias often hurts innovation. Separate personalities and the product/design decisions. Encourage diversity and respect.
Be respectful of other people's time. Everyone is busy and it is everyone's responsibility to assist other team members. Before interrupting your team members, try asking a rubber duck first. When you do go to your team members, bring good questions that can be quickly answered, and get you back to working independently as quickly as possible. Communicate the decisions that you have made. Take time to listen; don't cut people off. If people are going off on tangents, politely get them focused on actionable items to move forward.
Having said that, note that I'm not trying to get you in and out as quickly as possible. I'm not trying to minimize interactions with team members. I support Pair and Mob Programming and would like to increase the amount I do each week. If any of my actions are confusing, I want to explain them to you. There are reasons for everything I do, and I'm open to change.
There needs to be balance in respecting people's time.
Going hand-in-hand with being respectful is having empathy towards others. Even if the people that made the decisions are no longer part of the team, still try to be empathetic to why they made the decisions they did at that time.
If you don't understand why the system works the way it does, ask why that is the case. Almost always, it is because of constraints that existed at the time. The development team usually knows what needs to be done, but the constraints imposed at the time prevented that from happening. Software development is often about compromises. Recognize that if you were working under the same constraints, you probably would have made the same decisions.
Practice answering the question “why was it done that way?”. Form the answer in a way that is empathetic and respectful to the development team at the time. Even if you made the changes and you were ordered to do it that way, never respond to that question with “I was just following orders”. Understand the motivations of those that made that decision. Be able to answer that question in the same way the original decision maker did. Grok it.
Almost never is the reason that those people were incompetent. Maybe they simply didn't understand the problem at the time. One the of the great axioms of software development is that you don't understand the problem that was asked to be solved until the project is over. If they were able to do it over again (another constraint), they might have done it differently. They are learning. Learning is a critical part of an effective software team.
Expecting that they should have known better is disrespectful and creates a blame culture. Don't try to assign blame. Figure out what the problem is, create a small actionable work item to address it, and move on. Encourage a Learning, Agile environment.
Be curious. Learn how the existing system works. Read the code and existing design documentation. Don't be afraid to work with the code. Go ahead and make small refactoring changes to make the code better. Software only becomes flexible if you flex it.
Trust no one. Ask the same question to multiple people separately and see if you get the same answer. Verify that documentation is up to date. Search for alternate ways things could be done, don't always rely on being told how it is done here. When you see gaps, work to close them.
Jump in and contribute. Everyone is busy. Everyone has a list of things that they wish they could get to, but don't have enough time for. Don't limit yourself or your opportunities by saying “that's not my job”. Identify what needs to be done (or perhaps what has been missed) and do it.
When mentoring members on the team there will be (and should be) pressure to “level up”, to advance on your career path. This will go smoother if you remain mindful of your career goals. Your options are always open, but generally junior developers will be progressing toward a senior developer position. From there on to a technical path or a management path.
I'll work under the assumption that you're working to become the best senior developer you can. That is my role, and most of my advice is in that area. If that isn't your goal, that's fine. Just be honest with what your direction is. I'll try to be as supportive as a can in whatever path you choose.
The junior developer's role is quite simple in scope. Do the assigned coding tasks using the methodologies prescribed. But after a few weeks of that, the expectation is to start stretching towards a senior developer role. Let me outline what those responsibilities are.
It does start with a mastery of junior developer tasks. A senior developer should be able to write high quality code.
There are a lot of technologies out there to learn. It is not possible for a single person, even a senior developer, to master all of them. The idea of a “Full Stack” is somewhat of a myth. A senior developer should know what they know and know what they don't know. They should be capable of learning what they need to learn, when they need to learn it. They need to defer and collaborate with other experts when they need to.
Collaborating with different people with different areas of expertise is the heart of the senior developer position. Senior developers discuss solutions with product owners, customers, and other generally non-technical people. They then must take those same ideas, translate them into a very detailed technical specification and communicate those to junior developers. Translating between these groups is a large part of the job.
During these discussions, the senior developer must vet suggestions against sound software engineering principles. They must ensure that the suggestions from customers, product owners, and junior developers will yield a good software design. They shouldn't let anyone shoot themselves in the foot. Obviously, knowledge of those software engineering principles is key.
Another aspect is leadership. Senior developers need to make sure that all parties are working toward the same goal. Not all goals can be achieved in a single step. Most goals have several steppingstones that are required to be hit along the journey. Some of those are temporary and will be thrown away at later stages. Keeping everyone aware of what that path is and working towards that common goal is the responsibility of the team leads. The senior developer needs to make sure that the work of the juniors is delivering value to the customers throughout technical transitions and the path of the product is following a solid design.
Lastly, developers on the team need to build mastery over their craft. This includes coding skills, software design, operations, managing software projects, and many other aspects. Coding skills are a very foundational element to a developer's skill set. Start with focusing on that.
Early on the journey to mastering code programing the question must be asked, "What is good software/code?". It is an important question to answer for yourself, but also to make sure that your answer is consistent with the team.
Having this consistency between yourself and all other team members fosters joint ownership of the code base. This allows for collaboration. Quite often the definition of “good code” is that I wrote is good and I know how to maintain it, and the code everyone else wrote is crap and needs to be rewritten. This is why having a conversation with your team on what good code is, is so critical.
Good Software... works and is expressive.
It should not necessarily chase trends, nor be the cheapest solution possible.
If you've read my blog, you know the definition I have for “good code” is code that follows Kent Beck's 4 rules of simple design. In order of priority, code should 1) work, 2) have a single source of truth (no duplication), 3) be expressive, and 4) be small.
Working software should be able to compile and ship easily. This is why Automated Build Pipelines and Continuous Integration and Delivery (CI/CD) are so important. Being able to ship software quickly and often speaks to having your software in a working, easy to maintain state.
Once Continuous Delivery is in place (or significant strides made in that area) the obvious bottleneck or pushback on this goal is making sure that the code works. It isn't enough that the code compiles, it also must meet the required behaviour of the system. This leads to unit and automated testing.
Writing good unit tests is not an easy skill to master. It often takes years. Although unit tests are focusing on the first rule of “working software”, the unit test suite must be written well and follow all 4 rules. The unit tests must be expressive to focus on the behaviour required from the system, not on the technical details. The technical details are more fragile. They should be open to change, refactoring, and perhaps even changing technology stacks.
Code needs to be expressive. This is not only true in the unit test suite, but also in the production code. There needs to be layers in the code. The high-level layer must express the high-level business concepts that the software system supports. The low-level layer implements the technical details. The boundaries between these need to be separated. This gives freedom for the technical details of the system to change. It makes the software more flexible. As the expressiveness in the system is implemented, duplication is removed and the system becomes smaller (read more…).
Be sure to adopt technologies that support the design you need for the system. Beware of those that define “good code” as that which uses the latest frameworks or buzz words. Today's buzz words tend to become tomorrow's antipatterns. That happens when technology is adopted without consideration of the impact on the design. Learn about new technologies and adopt those that can support good design. Always be learning.
Be mindful of the cost of development. Follow principles like YAGNI and delivering an MVP. Avoid gold plating. Software Engineering, like any other engineering discipline, delivers a sound design at the lowest possible cost. However, be sure to always follow sound software engineering principles. How you do anything is how you do everything. Follow the boy scout rule and always leave the campground (code base) cleaner than you found it. There will always be compromises, but don't fall into the trap of taking shortcuts thinking that you'll just fix it later when there is more time. There will never be more time, usually because to are too busy wrestling with software that isn't designed well. Be aware of what the vision for the future design is, and keep taking small steps towards that, never back.
Additional Resources
- Clean Code, Robert C. Martin
- Test-Driven Development: By Example, Kent Beck
- Refactoring, Martin Fowler
- Design Patterns. This Head First edition is easier to read than the original Gang of Four book.
- Domain Driven Design, Eric Evans