When you adopt a Shift Left approach, and developers start discussing code as they are writing it rather than once they are finished writing it, you can identify potential problems or approaches when changes are both possible and not very painful. What does it take to implement a Shift Left approach?
All Posts by this author
When compared with code reviews using a Pull Request or a Merge Request as the primary driver of collaboration, In-IDE code reviews offer important advantages that result in higher author and reviewer satisfaction.
In Part 1 of this series we touched on the evolution of IDE from a personal, standalone tool to a connected and networked hub of all things code. We explained how connecting your IDE to your teammates’ simplifies communication and collaboration with two specific use cases: Discussing code in general, and performing code reviews right in your IDE, eliminating the context switching and improving knowledge sharing. In this post we will expand this to additional use cases and show how the Connected IDE is the most important step towards team collaboration in a world where we are all remote developers.
Like the standalone PCs of the 1980s, the personal IDE remains an island detached from the opportunity to improve collaboration for the development team and the company as a whole. A new era of connected IDEs is coming that does not require you to leave behind the IDE you love. Using modern plug-in technologies, your IDE can begin to evolve towards a truly Integrated Development Environment that will make collaboration easier while improving code quality.
Why don’t programmers document their code? In an all-remote world, documentation is one more essential tool to sustain team alignment. This is a great moment to revisit how we think of documentation and its value. The good news is that there is a better way.
One way to think of transparency is to consider it a philosophy, or a point of view. It implies openness, communication, and accountability. Transparency is operating in such a way that it is easy for others to see what actions are performed, and how they are performed.
We, as software developers, don’t collaborate enough. In this article, we will begin to look at what drives dev team performance, and how our culture has been resistant to adopting a more collaborative approach for historical and competitive reasons.