Digital Identity is Under Attack: FIDO Paris Seminar.pptx
Notes de l'éditeur
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
My name is Seb Ruiz, and I am a Team Lead on the FishEye and Crucible products.\n
As a team lead, I deal very closely with developers to create and deliver stellar features. I myself have roots as a software developer, and only recently transitioned into team leadership which brought about a few new responsibilities in my day to day activities. I love my job and my team, but I am constantly trying to find ways to reduce the new overheads and get back to coding. I have discovered that “getting back to coding” is actually also applicable to developers. I like it that my team plays hard, but instead of working hard, I prefer them to work efficiently.\n\nLet me show you how the Atlassian dev tools have revolutionised my life and helped me and my team get back to coding.\n
Developers have always been our focus - they are the backbone of our worlds. Atlassian helps developers do their jobs, but also people like myself, understand what is happening in the bigger picture. I find that it is really important that my team are involved in the planning of the work that they will be participating in for the next few months. Group buy-in and involvement makes a huge impact on the quality of the work which is produced at the end, and lets us code towards a common goal.\n\n
Miscommunication is the mother of all screw ups - if we don’t have a common goal and we don’t communicate effectively, then we are doomed from day 1 and shouldn’t even be coding\n
GreenHopper and JIRA is that communication medium that we need to coordinate and plan our work. By discussing our features and problems up front, we can try to reduce the number of unexpected issues from arising later.\n\nApart from creating and managing the work for my team, I see my job as a composition of two other main roles: 1) ensuring that the developers on my team are producing excellent results, and 2) to allow and enable those developers to write code.\n\n
Both as a team lead and as a developer, I've always found it crucial to know what has been going on in my repository. We are part of the ecosystem of a code repository and to keep it alive it is important to know how it is evolving.\n\n
This is how I used to monitor my code: trawling through commit logs over the command line. Can you read this on the screen? I can't and I'm standing next to it! One of the biggest gains I have ever had in my code monitoring was to have these commits emailed to me as they happened.\n
Emailed commits allow me to receive an email on any check-in that is made to the repository and thus I can keep track of the changes that are made by my team at my own leisure. No need to worry about missing a beat as everything is logged conveniently in my email client.\n\nIs this overkill? This may seem like a lot of micro-management and you may not have the time nor inclination to follow every commit. I use commit emails to be able to give myself a cursory confirmation that the developers really are working on the issues they have been assigned to, rather than become distracted on a tangent. If I am looking for some clarification, it is trivial to reply to the author via email or to click through and leave a comment on the change set.\n\nFor example, when I am interested in looking at  specific work then I will click straight through to his user profile which will show me all the work that he has been doing in a reverse chronological view. No need to interrupt him or dig through logs of my repository.\n\nThe important part here is that I'm easily able to filter out the information that I don't need. This is crucial in allowing me and my team to find the information we are looking for and what we need.\n\n
One of the challenges both as a team lead or as a developer is being able to find the information that we need. We are constantly trying and needing to diagnose, understand and look into a historical view of our code. We simply aren't capable of storing all the information in our heads, so we need tooling that can do the hard work for us. FishEye allows me and my team to solve these problems.\n\nA couple of weeks ago, I very quickly asked a few Atlassians why they used FishEye. Some of those responses were:\n
\n
As you can see, each of these developers have different opinions of their favourite use cases for a tool which enables them to access the information they need at the time they need it.\n\n
My favourite quote however was the following: "It gets people out of my face". This sums up what allows us to get back to coding and away from the hassles and distractions around us. If your team isn’t able to find the information that they are looking for, then they are likely to be distracting other colleagues from their tasks.\n\n
Also you will notice that a lot of those previous use cases are about understanding why a change was made. We issue code reviews for all our changes - but not these reviews where you sit around a table and talk about the "big issues" - because they rarely turn out productive.\n\n
This is what we are trying to avoid - hair pulling, tussles and all out gang warfare. Doing code reviews online is another way that we as a team are able to allocate our time appropriately, as there is no necessity to look at the changes immediately.\n\n
With a distributed team, being on code reviews is so imperative that we cannot imagine a world without them. My team is able to interact and collaborate over code, and we find and fix lots of defects thanks to code review. The collaboration facilitates reduction of the learning curve when we hit the ground running in new code, as well as reducing the risk of information silos in teams.\n
In order to ensure that nobody becomes a bottleneck for reviews to be completed, we have instated "Crucible inbox 0" days on Tuesdays and Thursdays. These small processes allow us to run a steadier ship and reduce the hassling and intervention required from my team.\n\nCode reviews provide additional audit trails for coding decisions, which allows me and my team to be able to determine answers to problems we would otherwise need to speak to either current or ex colleagues about. This lets us code more, with greater confidence and with a higher velocity.\n
Too many teams are afraid of changing their status quo - they are afraid of the disruptions that they cause. You should take DRASTIC measures to fix them!\n
We identified that towards the end of a release there was a much greater necessity to do quality and technical review on our hardening backlog, so we implemented the following process changes:\nAll changes must be on a feature branch\nAll changes must be reviewed\nAll reviews must trigger a build that passes\nTo aid this, we wrote a plugin to run builds against a particular commit or branch for every code review. This added some overhead, but we have become much more confident in the software that we are releasing.\n\n
