Hi, everyone. Thanks so much for joining our session. We'll go ahead and start now. Um Today we'll be presenting on building new features as junior engineers. I'm Cameron. I'm a web web engineer on the purchase team here at Seat Geek.I've been here for about 10 months and in my free time you'll find me reading and on road

trips, everyone. I'm Jenny. I'm an, is engineer in the purchase team and I've been at seek for a little under two years. Um In my free time, you'll find me exploring museums and restaurants with friends and a little bit background about the purchase team at CG. Um that we're both on, we deal with the checkout portion of the app. So that would be buying tickets. It would also include logging in and selling tickets.

So before we get started, what is CGC geek is a place for fans to buy and sell tickets to live events. We support I Os and Android apps as well as desktop and mobile web. Um And here's an example event page with our custom map of red rocks. So during our presentation, we'll share with you our learnings about planning including ways to get organized and prepared to tackle a big project. Um We'll talk about working with multiple stakeholders and communication and we'll finish up with talking about integrating a third party feature.

So let's dive into planning as many of, you know, starting a big projects can be the most overwhelming part. Um Figuring out where and how to start can be really challenging. But it is a good way to set yourself up for success. A good way to start a technical project is by writing up a technical specifications document. Uh This document should lay out products requirements and provide a general overview of the work that is needed for our most recent projects on the purchase team. Um One of our teammates took on this task and wrote up our business and product requirements as well as details on the changes that he would be making to the API to support the new feature and how the clients would interact with it. This document helps the team start to understand the project and ask really important questions. Our team follows an agile works style. So once we had a better idea of the work that was required, we used a planning board to break down the project into the smallest tasks we could think of. We used a tool called fig jam to do this. And here is an example board that you see, we split the board by platform and laid out the tasks along with estimates for each of the items. And they generally fell into three distinct categories.

Um setting up and connecting the external code through a script or SDK, um connecting the clients with the new back ends and hitting new uh api end points, creating new user interface pieces and testing the future. Our team likes to include planning spikes in our sprints which are tasks that give us a few days to dive into unfamiliar territory and get a better understanding of the work needed before starting something new. A really important part of planning is estimating how long a piece of work will take. It's a skill that takes a while to become comfortable with and takes even more time to become accurate with your estimates. Uh So this can be tough for more junior engineers like ourselves and like maybe some of you watching um from going through this process, we learned that buffering estimates is generally better than setting very ambitious timelines and increasing the likelihood that you'll miss a deadline.

So some tips that we've learned from this is to maybe double your engineers estimates or assign your estimates, a level of confidence and propose multiple strategies. Um or you could add buffer time for reviews, bugs and design changes because those come up pretty often

after you estimated your work. Um you, it's great to organize your tickets and file them in a project organization website. So for us, we use Jira and there were three fields that we found very helpful. The first one was the platform, second one was the tentative fixed version and the third one was the epic link. So for the platform um this to categorize what devices we're working on. So I OS Android web and back end and it helped categorize our work for the tentative fixed version. This was I OS specific um and it helped us keep track of the incremental work that was included in each release. Since the feature we're working on, it was going to be done over a period and there was going to be a few I OS releases before it was completed. Of course, all of this was hidden behind a feature flag finally for the Epic Link. Um This was the name of the feature. So there were multiple projects going on on the purchase team and therefore the Epic link associated with the project name. So we would um give an Epic link to each project we're working on. And then through this, when we're working on Jared Bar, it was very easy to filter out um the different projects we're having and also just to see the progress on all the projects across the board.

So all of this overall like creating Jira tickets and also using the three fields really helped us keep our project organized and it was really easy to find tickets too because we were able to filter by platform or by the epic link after we filed the tickets in Jira, um we thought about paralyzing work.

So this is important because it can help your team meet deadlines and it also lowers the barrier of entry for people on your team to jump in and help. Um So you might start off with one engineer originally, but if you need more assistance, um paralyzing work first allows for a second engineer to jump on and take on certain tasks. So when you're deciding which work can be paralyzed, there's two questions that I found really helpful.

Um When I asked myself. So the first one was which tasks are relevant to the visuals and functionality of the future. And the second question is which tasks involve coordinating between different teams to complete. So for the first part about irrelevancy between the visuals and functionality, um these tasks tend to be lower impact, they have less code conflict and they can also be completed at the end of the project while the future is being tested. Uh So an example of this would be creating the A B test, um an A B test controls when the feature is shown or hidden. So it's great to keep, keep it at the end of the project and it doesn't touch any U I or functionality. So it's a really good piece to just give to a different engineer to work on. The second question um that I tend to ask myself which is related to coordinate between different teams in which tasks involve. That um these tasks tend to involve a lot of communication between teams, they tend to be more involved. And therefore it's a big chunk of work. So the second engineer is able to take on that work and help out that can definitely um speed up the process of getting the project out the door.

So an example of a task that involves a lot of coordinating between different teams would be implementing the tracker actions, which in our case was analytics. Um So deciding seeing like when users like click on certain buttons, like those tracker actions and then also addressing designer feedback.

So that would involve a lot of coordinations with the design team. So they choose to ask because they were pretty heavily involved in communicating with different teams and it did take up a big chunk of time. So it was nice to just break that down into a second engineer's task and knowing, asking these two questions and taking a look at example, tests on the image on the left. Um You can see an example of how we would break them down to two engineers work. So the first engineer would take on creating the future role um and also implementing the AERO states and also create A B test while the second engineer would take on implementing the tracker actions and addressing the design review feedback. Um The last three were the ones that we talked about could be. Yeah, so now that you paralyze your work, another thing that we found helpful was thinking about the order of the task. Um So thinking about like the order matters and if you look at engineer two on the left, um in this case, the two tasks, three tasks, they have um the order matters for the very last which is create the A B test to implement tracker actions and address design feedback can be done in any order.

One can be done before the other. But the create A B test needs to be done last because as I mentioned before, it controls when the feature is shown. So ideally, you would want to have that as the last task for engineer ones task um create the future role and implement air states. So the future role would need to be completed first because that would be building the U I for the, the um project that we have and then the Air States can be implemented after the U I is built. So that order does matter. Um After determining that order, we also thought about how to ship our project. Um ideally, we would want to be able to ship in increments and we thought about which tasking to be shipped together versus separately. So for engineer ones task, um because the feature row and the air states are closely tied together and they have a lot of overlapping code. It is strong. We prefer that they would be shipped together if they were shipped uh separately, there might be a lot of code conflicts. Um So it's best to have one engineer work on it and also ship it together. However, for engineer two tasks, um the tasks are pretty separate.

So addressing design feedback and track actions would touch different parts of the code, there would be less code conflicts and therefore they could be separately. Yeah. So let's move on to the third portion of our talk um which is working with multiple stakeholders. One key tip that we have for everyone which everyone already knows is to communicate frequently. Um This is, this is so important in our project. Uh We had to communicate frequently with design other developers and our project manager. Um This way everyone stayed in sync on how the product functions and discrepancies between platforms are also found earlier. So there were three ways that we communicated frequently with our stakeholders. The first one was through stock channels. Uh The second one was through meetings and the third one was through self reflections while we were working on the project. So for the slack channels, uh we created a few with appropriate stakeholders so we could address any questions they had asynchronously. Um This was important because um each channel shared specific information. So users wouldn't get spam by joining one big channel. Uh For example, we had the internal team and the future DEV team. So DEV team itself was the is web um and backend engineers while the internal team was an expansion of other relate teams on c who would be impacted by work. So this would include customer service, finance and commerce and as for the meetings, um we had two types.

So the internal weekly check in and the external ad hoc check-in for the internal weekly check in. I have an example in the following slide. So um we'll talk about it then and finally, for the reflections, these are questions that we would ask ourselves when we find edge cases. Um So every time we found edge case, we would ask ourselves like who else would, would want to know about this change and also who would find it helpful by sharing information. So this really helped us reach out to the right stakeholders when we were finding these uh bugs. So an example of the internal weekly check in we had in the progress, the format of it. Um as you see, there's an image on screen, this is the Excel sheet that we would open up at the beginning of each of our internal weekly check ins. We would start with the progress updates and we would go by platform. So I OS Web and back end we get their updates. Uh then we would discuss any blockers and finally, we would review the project deadline. So we would decide if we could be able to meet the deadline or we had to push it back a little bit. Yeah.

And uh on the text tube is just examples of what you could write. So if we look at the I OS row, um the first meeting we had it was in progress, designs are also updated early. Um And then the second meeting we had an edge case was found. So we need to make a decision for the team to move forward and on the topic of edge cases, um an example of reflecting on your work while you're working on, it was something that the web team did really well on when they found a difference in the error format that was being returned in our project.

So for a little context, the back end was returning a string for the error text. Um but for the other errors on web, they were being returned as an object with a code, a string and other information. So because there was a difference that how the errors are being um returned, they, the first thing they did was sync with the front end team to see how we handled the new error. And when I took a look, it was also similar, the other errors were also being returned in air object while this was being returned in er text. As a result, we were trying to mimic the error object. So we were creating a new error object with that text, adding an error code, et cetera. So it seems like there was duplicate work on the front end team, both front end teams. Um So because of that, we decided to chat with the backend team, which is the next step about updating error format. So they fixed it by, um, returning an object and of a text. Then the front end and back front end teams wouldn't have to like recreate the object so it saves us some time too. Um So after we synced with the backend team, the last thing we did was we confirmed the party of the change.

Uh We talked to the engineering manager and the product manager determined it was a launch block or not. So this is really important in deciding every time that was going to be moved or when we need to address it. And in this case, um it could be addressed post launch because the both front and teams were able to deal with it on their own. First,

we want to emphasize the importance of open communication. Um Maintaining this is crucial for a successful project. Making relevant meetings available to all stakeholders can help keep everybody informed and you can add the broader team as optionals to these meetings to give them the opportunity to listen in and catch up if they want to. Another important line of communication is between engineers and design.

So as you develop new front end features you'll most likely discover more questions about the different states uh that the app or the website could be in as you go. And fig M is a great design tool that allows you to have discussion threads on the designs themselves. So you can ask clear questions. So to the right, we have an example, fig a thread on one of the I OS designs, you can see the screenshot of I OS and then the discussion thread to the side. So you can see exactly what you're asking about. And lastly, when tackling a big project, you'll likely end up with so many documents with tons of important and relevant information and this can easily become overwhelming and difficult to manage. So after finding ourselves in this situation, we made a central document that organized all of the others and linked out to each of them. And this made it so much easier for our team to find the information that we needed much more quickly. So we'll wrap up with talking about integrating a third party feature. So testing external code early on is really important when working with third party code. If you make sure everything is working as expected and returning the data that um you need upfront, then you're giving yourself more time for communications with external partner.

For example, on I OS, there was an issue with the alignment of the text within a U I element that we were getting back from the external partner. Um, and after we brought it up to them, they were able to resolve the issue really quickly and ship the fix with their sck and on web, we noticed some issues with like pop ups and ad blockers because we were working with, uh, the third party was offering like a model. So after bringing this up to them, they told us that this is expected behavior and it's something that they're actually working on improving. So now we know that's ok. Um And it's always good to investigate these issues before bringing them up to the external party to be confident that it's not an issue on your end and they should be able to clarify or resolve anything in this case. So here are some tips and things I've learned from owning my first feature on web. Don't try to get the whole feature out in one functioning piece. Uh This will lead to an enormous merge request that will take a long time to review and it'll take a long time to fix the feedback that you get. So instead you can ship small pieces of the future behind a future flag.

And these pieces don't necessarily have to work on their own and it allows you to get constant review and feedback as you develop the future and writing unit and, and 10 tests in parallel with development will help you catch bugs quicker along the way and tests might be easier to write while the specifics of the functionality are fresh in your mind as you go

for I OS um the feature that we worked on involved integrating SDK. So here's some tips that I found while integrating the SDK. Uh The first one is to factor in additional time to link the code in your codebase if it supports multiple languages. Um So, in our case, our codebase was an objective C and swift. Um But the SDK was an objective C so slight differences of the function signature when you're um using objective C function and swift and also the fact that objective C doesn't have optionals. So those small things like does take a bit of time to work around and also just context switching between different classes and your code based on the different languages since you are working with two languages and coding in them. A second tip um that I found was to create a debug toggle to force the future view for easier testing. Um So at the end of our project, we did have an A B test to control when the future was shown or hidden. In the beginning. When we were developing, it was important to have a debug toggle to hide it and also to force show it um especially when design was doing reviews. So they could easily pull up the view and give us for feedback. And then for us just to test the initial U I the last, the um this was the last step in integrating the first party feature. Um So yeah, last step of any feature that we've been doing was to host testing parties. So we hosted two types.

The first one was an eternal one and the second one was an external one. The external one was with the partner that we were working with for the internal testing party. And this was really important because it helped us think about the holistic flow of our feature. Um So our feature was working on purchasing tickets, but purchasing tickets involves like multiple steps and includes finding the event, buying the ticket, um getting the order confirmation, receiving the ticket, using it to enter the venue and sometimes they're funding the purchase.

So there's a whole flow involved and not just like purchasing the ticket part. Um So having these testing parties and writing test cases really helped us test the end to end flow instead of just the purchasing tickets portion. And this also allowed us to catch any related bugs from what we're implementing. So for the internal testing parties, we had two on iws and web. Um So four in total, the first one was with immediate team and this helped us uh catch a lot more bugs because it was more of a like less production ready build. But with this, we caught a lot of bugs and we were able to address them early. The second build um second testing party we had was uh with a broader team and a production ready build. So in this case, this would be to uh just catch any learning buzz that we might have missed as for the external testing parties, um we had two on a conference call call and this is with the staging and production environment with external team. And uh we also did some asynchronous and and testing after. So as mentioned before, with like the whole flow, purchasing a ticket, there are some steps that come after such as getting email confirmation or refunds.

So after we tested with the external party, we had to do some asynchronously synchronous testing on our own um to make sure that we were receiving those emails and to make sure the text was what the partner expected. Yeah. So I just want to give a big thank you. Um Before we end off to everyone on the purchase team um for the tips and guidance on planning our first project on a new team. Um This was definitely not possible to come up with these slides without their help and their guidance. And it was just really grateful having to support the other project. So I just want to shout out to our team for all their help. Also, there's a few key takeaways um from a presentation um that we have listed here, but it's also on the website, I believe the speaker notes. Um So some things to consider is to just really take your time with planning. So you have to think through your future and then try to come up with like the action plan and test cases to make the development go more smoothly. Um Also communication is key. Um as everyone knows, both for internal, external teams, this will help you resolve questions and issues faster.

And finally, it's important to give yourself the timing to do your work um and do it well, we all want to push out work quickly, but the quality does matter a lot and it is important. It's ok to take your time to get the quality, right? Um And also to uh make sure your estimates reflect that too. I think as junior engineers, it is tempting to say that you can still meet a deadline even though like more features are being added. But um looking back, it was nice that we were able to like step back, um really review the work that was being added and be ok with like pushing the deadline back if it resulted in a higher quality product. Yeah, so thank you everyone for attending our presentation. Um If you have some time after we do have a booth open, so feel free to hop in that. I think you just go to the Expo section and then search the geek. Um Our booth is there, you can ask any additional questions you might have and also we are also gonna be entering everyone a raffle, um, participated in this presentation and also going to the booth. So I believe the reward is something with, uh, maybe promo code to buy tickets. But I want to check on that. Either way, please come check out our booth if you have the time after and we'll be there to answer any additional questions you might have. Thanks everyone.