A Few Screenshots of the “August Prototype”
As I have done for the last few months (June and July) I wanted to continue to share a few more updated screenshots of what I’m putting together so you all can continue to get a sense of the momentum that’s being built behind-the-scenes.
And as I survey even the last few months it’s fascinating to review the changes myself as it becomes even more obvious how much work has been done and how much more exciting the project is becoming.
What you won’t see (but perhaps I’ll spend a bit more time talking about it soon) is what’s going on in addition to building product; believe me, there’s a ton.
For instance, I’ve spent the last few months on the phone, in person, on Google Hangouts and Skype having regular interviews and conversations with folks that I trust and respect about developer tools, the concepts around a “LinkedIn for Developers” and “Developer Graphs” and generally just building better software and the questions I’m trying to ask (and solve for).
Slight tangent: At this point in time I’ve probably used most of the screensharing and video-conferencing tools available at my disposal and if I were to abandon this project entirely I’d say there is a very clear and large opportunity to get video conferencing right — every tool is terrible and is so spotty they are generally untrustworthy.
But back to the point: There are 1,000 things that I want to do but only a few things that I can do when you start putting a new project and venture together. A good friend of mine (Jeff Haynie) reminded me of this “Startup Survival Rules” chart which I find to be quite useful:
Originally inspired by Paul Graham’s “Startups in 13 Sentences” it highlights some of the essentials when business building.
The first 4 are crucial and what I’m doing now is making sure that I can not only launch fast but also understand the (potential) users as quickly as possible. In summary, building fast and talking to a lot of people. As a natural consequence the idea will evolve into something that people will pay for (or at least that’s the hope).
Are we there yet? Of course not; there’s much more to be done, but by ensuring that those few things are “locked” will ensure a greater chance of not only survival but success. And I’m hoping to have that latter part accomplished in a big, big way.
So, what have we been putting together this month? Well, in gist, what I’m trying to do is surface data that can be useful to engineers, engineering teams, and the business as a whole. As you have already been able to see, I’m ingesting a bunch of GitHub data and showcasing that data in a myriad of ways.
In the last few weeks I’ve been taking a look at active repos and projects along with profiles. Take for instance thaJeztah (Sebastiaan van Stijn) who is very active in the Docker project:
I’ve taken his profile and been able to review his work in a slightly different profile page that I’ve put together:
Okay, so that’s not a super big deal. I understand. But, what if you were then able to see now just what Sebastiaan has been working on at a high-level but also a much smaller and revealing metrics? Take a look at this Metrics Dashboard:
Feel free to click the image for a larger view. You can begin to see interesting things that are time-bound and time-related, like his contribution levels related to New Lines of Code, Commits, Refactors, Deleted, and by programming languages and distribution of activity.
This is just the start, of course. And, this is for just one profile for one team member and contributor to a project! You can begin to see the potential and power that an effective dashboard can bring to provide better transparency and visibility into an engineer’s work and productivity.
And, the beautiful thing is that it’s not speculative but real — it’s real data on a real project with real commits (and not just an estimation tool or function).
Expanding this out to the team level or the much larger project and then the entire engineering organization is really, really exciting. Imagine the data that you’ll have to be able to compare and contrast as well as triangulate releases with work and everything in between.
The point of all this transparency is so that teams can build better software. Full stop. And, if I can continue to provide better clarity around the work that’s being done without qualifying if the said work is necessarily good or bad (creating loosely-bound judgement calls) then we have something really useful on our hands.
I can, of course, track all of the public projects for Global Docker and you can begin to get metrics around these types of things as well:
- Most Active Repos
- Most Active Developers
- Top Languages
- Average Release Durations
- Repos with the Most Contributors
- The Average Developer Lines of Code Impact
- Etc… Etc… Etc…
What I want to do over the course of the next few weeks is continue to poll and ask the hard questions to potential users and customers about what would be truly useful for their teams, projects, and organizations so I can continue to refine the offering smartly.
Why? So this startup can survive… and then thrive. Much more to come soon!
Originally published at Building Better Software.