Internal Technology Platform
I’ve been part of the Developer Experience (DevX) team for over three years. As one of the DevX team, our primary goal was to create a developer platform to simplify workflows and make resources like documents and services more visible and accessible. Over time, this developer platform, named Pandora, evolved into a technology platform used by all employees, not just developers.
Many teams collaborated on this platform, which now includes over fifteen frontend plugins and more than twenty backend services, offering thousands of features. As one of the core members of Pandora, I contributed to the majority of these developments.
I gained valuable experience, faced many challenges, and learned things I don’t think I could have in any other project or environment. Our customers were our colleagues, mostly developers, which came with its own difficulties. I want to mention some of the things I experienced and learned.
Collaboration
Collaboration can be one of the most challenging aspects of working on a DevX team.
It’s part of the nature of the role. To make the platform a daily tool and boost user engagement, we had to add more useful and user-requested features. Some of these features required collaboration and coordination with one or more teams to complete. For example, if you want to display a team's services on their team page along with details like key metrics, config management, etc., you need to collaborate with platform teams. Similarly, if you're building a dashboard to display insights about the overall technology department, you'll need to work with multiple teams to ensure accurate data.
In such cases, even if the task or feature is small in technical size and effort, it can take up to five times longer than expected due to collaboration challenges.
Context Switching
The platform covers many different domains, unlike other projects or standard domain teams. Even a documentation plugin is considered a domain on its own. It has so many parts and features that you often have to switch between them. When an error or bug occurs, you need to switch to the relevant domain to fix it. Even if you’re working on a different domain, you have to shift focus to the other domain in order to resolve the issue.
Know-how
Since the platform has a multi-domain structure, you need to learn and focus on many domain-specific areas. If you’ve worked in a domain for a long time, or if you’ve been in the project from the beginning, you have all the technical and business logic that the team should know. As the platform grows, it becomes challenging to share this knowledge and learn from other team members. To prevent this, it's important to pair up with other team members in case you're unavailable when an incident occurs. The real cost of this situation is pair programming.
Pair Programming
Pair programming is incredibly helpful when you're creating, developing, or tackling something challenging. Especially when you're building a project from scratch or developing a complex feature, brainstorming and collaboration are key. In these situations, pairing up is not only okay, but it's often the recommended way to work.
However, there's another type of pairing that’s more about knowledge sharing. You pair because you have to. You might be leaving the team or rotating to another role in the organization, and in this case, it's essential to share your know-how with your pair. This isn't just about one project or a connected series of complex projects – these are often entirely different domains. So, sharing or acquiring all the necessary knowledge can be quite challenging. And of course, it’s difficult to fully understand everything until you actually get involved in the project and start developing.
Creativity
Developing an application or a feature begins with thoughtful planning and a well-defined roadmap. While creating these applications can be relatively straightforward, the challenging part is often sticking to the plan and avoiding scope creep. When we're working on a project, things can get tough due to responsibilities, dependencies on other teams, and priorities that can shift quickly. We often have big discussions with our partners at the beginning of a project to clarify everything. But as time goes on, needs, expectations, and even the plan tend to change rapidly. This is because companies or departments may change their priorities or focus. So, we need to be able to adapt to these changes.
As we adapt to these changes, it directly impacts our creativity. We need to constantly think ahead and consider where the project is headed, so we can adjust our approach accordingly. When creating a plan and roadmap, it's easy to get caught up in thinking that detailed planning will ensure success. However, overplanning may not always be necessary or helpful. Instead of spending too much time on complex planning, I recommend creating a simple plan and then starting development. As you begin building, you'll naturally encounter edge cases and unexpected challenges. This is where iteration comes into play. By keeping your initial plan simple and iterating as needed, you'll avoid wasting valuable time and resources. This approach also helps decision-makers feel more confident about the project and its direction.
Contract
Don’t rely on what someone says; rely on the contract.
Document every decision and detail, big or small, from the start. This ensures you have a clear record of what was agreed upon and can avoid misunderstandings later on. Request For Comments (RFCs) and Architecture Decision Records (ADRs) are excellent tools for documentation, and they'll become your best friends. They are also valuable references and reminders for future reference.
Tech Stack
The tech stack is another significant advantage when working on projects. With it, you can leverage the latest technologies, libraries, and frameworks to develop projects.
If golang fits your project's needs, you can use it. Similarly, if reactjs or tailwind are suitable for your project, you can opt for them.
You're free to benchmark and compare different technologies, ultimately selecting the best fit for your project. Of course, this must align with your company's tech stack rules.
The absence of technology-related restrictions can significantly boost team productivity and motivation. No one will ask which technology you used, at the end of the day, it's all about getting the job done effectively.
It has been an amazing journey gaining these experiences. I'm excited for new challenges ahead.
I'll keep sharing my experiences over time.