Different software development teams do things differently, and even within the organization, there are many differences between teams. As a software engineer, it is often exciting to work with new partners and develop new software, and there are many issues to consider. Recently, software engineer Thomas Stringer took a look at this from a technical, collaborative, external, and product perspective.
technology
1. How do I build software locally?
That’s the first thing you should learn. After all, building is the first step in developing and running software!
2. How do I test software locally?
CI Pipeline is very useful for correcting test errors. It also shortens the internal development cycle to ensure smooth testing and check regression. The pipeline should not be the first indication of creating or causing a test to fail.
3. How to set up the development environment?
The team documentation should clearly require this. You also need to know what different tools to use on your development machine in order to be the producer of your team. Setting up your environment to handle 95% of your requirements at one time is much better than encountering errors and Gradle dependencies once you’ve started development.
Where is the source code?
Often, on a new team you will be working from a pre-existing code base. Therefore, you need to know where the code is and how to get it on your local machine.
5. Where is CI/CD Pipeline and how does it work?
Hopefully you will join a team that ensures the quality of the product delivered. One of the most common tools is CI/CD Pipeline. Find out where it is and get a brief idea of how it works, look at some recent runs, and see what steps have been taken.
6. Where is the product backlog?
You’re dealing with the current state of the software, but it’s best to understand its future state first. Take a quick look at the backlog to see some of the priorities for the upcoming product launch.
7. How is pre-production and production testing conducted?
Does the new team have an integrated environment? Does the team use Canary build and deployment for testing? Does the team introduce chaos engineering? You need to understand how the new team will ensure that its production software is kept to a certain standard.
8. What form does the on-call take?
Does this software require on-call? If so, how? What is the frequency of accidents? Is there any non-working time requirement for on-call? How do I get notified when I perform an on-call? Usually you don’t start the on-call rotation right away when you join a new team, so over time you can get some answers before performing the on-call.
9. Where are the internal documents?
Where does the new team maintain internal documentation? Is it the latest edition?
collaboration
10. What is everyone on the team focused on?
Software teams often have multiple engineers, and it’s good to understand the concerns of the different programmers on the team.
11. What is the team’s weekly pace?
Is there a daily stand-up meeting? Do you need weekly check-in? You need to know what a “typical” week for a new team looks like.
12. Who should I ask “beginner” questions to?
When you join a new team, you are often assigned an “on-boarding buddy” — a team elder who knows how things work. This is a very valuable thing to do, especially if you know next to nothing about the new software and ask very rudimentary questions. It’s normal, and there’s no shame in asking beginner questions, even if you’re a senior engineer.
13. Who will drive new features?
Is there a product manager for this product? Are there architects working with engineers on the team? You need to understand the upstream source of feature requests. Even better, take the time to talk to this person (or people) about the near – and long-term prospects of the product.
14. How does the team communicate?
Does the new team use Slack or Teams? Or is most asynchronous communication done by E-mail? Engineers usually spend all day talking about problems or other types of discussions. As a new member of the team, you need to understand these communication channels.
external
15. How to get customer feedback?
Is this open source software on GitHub? Is the GitHubissue our way of getting feedback? Or do you have the sales team acting as an agent from the customer to the product team? Can we collect common customer pain points from different support teams? In other words, you need to understand how the new team gets feedback from users, whether through another platform, an individual, or a team. After all, we write software for users.
16. What support agreements do we have for our customers?
Do we have to comply with the SLA? What user scenarios do we support?
17. Where is the public/customer documentation?
This is an important question. Customer documentation should be accurate and up to date, no matter how good the software. You need to know where to view these documents, how they are kept up to date, and who is responsible (hopefully the answer is “everyone”).
Product focus
18. What are the advanced pain points of software?
You need to know if the software and the team are dealing with big problems. Are some architectural issues causing other problems? Are there exploitable security holes? Are there common customer issues that keep popping up and need to be addressed?
19. What are the concerns of stakeholders?
Are there features of the software that key individuals or other teams want to see? Often, these stakeholders have a significant impact on the short – and long-term roadmap of the software. Understanding their concerns helps you imagine the future path of software.
20. What is the software release cycle?
You also need to understand the frequency and timing of software releases. Is the team continuously deployed multiple times a day? Twice a year? Knowing the software release schedule gives you a good idea of the pace of software development.