Why communication is the best skill you can develop as a programmer
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
| Title |
| |
| Title of Series | ||
| Number of Parts | 131 | |
| Author | ||
| Contributors | ||
| License | CC Attribution - NonCommercial - ShareAlike 3.0 Unported: You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal and non-commercial purpose as long as the work is attributed to the author in the manner specified by the author or licensor and the work or content is shared also in adapted form only under the conditions of this | |
| Identifiers | 10.5446/69520 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
EuroPython 20244 / 131
1
10
12
13
16
19
22
33
48
51
54
56
70
71
84
92
93
95
99
107
111
117
123
00:00
Receiver operating characteristicRouter (computing)Programmer (hardware)Telecommunication40 (number)CodeTime domainConsistencyTelecommunicationProgrammer (hardware)Field (computer science)Form (programming)Multiplication signTask (computing)NeuroinformatikGoodness of fitBitPoint (geometry)Formal languageSubsetVariable (mathematics)SoftwareBuildingFood energyDifferent (Kate Ryan album)Software developerLine (geometry)Data conversionPerspective (visual)Universe (mathematics)Level (video gaming)Machine codeComputer fileMetreReading (process)Context awarenessNumberDecision theoryArithmetic meanIterationCodeInternet service providerLink (knot theory)MathematicsSlide ruleString (computer science)Functional (mathematics)Heegaard splittingLogicSoftware engineeringMultiplicationCross-site scriptingObject (grammar)MereologyDomain nameProduct (business)AreaType theorySystem callPlastikkarteWritingConsistencyComputer animationLecture/Conference
07:51
CodeTime domainConsistencySteady state (chemistry)System of linear equationsMessage passingSicArc (geometry)Variable (mathematics)Online helpTask (computing)Multiplication signForm (programming)Proper mapField (computer science)Mathematics2 (number)Type theoryLink (knot theory)EmailBitDebuggerSoftware testingCodeCASE <Informatik>Message passingLine (geometry)Sign (mathematics)Functional (mathematics)Point (geometry)Virtual machineStack (abstract data type)Buffer overflowError messageoutputTelecommunicationRevision controlRow (database)Web pagePerspective (visual)String (computer science)Greatest elementAddress spaceArithmetic meanComputer animation
15:33
Operations support systemCASE <Informatik>Form (programming)Line (geometry)Field (computer science)HypothesisConfidence intervalImage resolutionMultiplication signWhiteboardCodeFeedbackSoftware developerLevel (video gaming)Right angleBitMathematicsSoftware bugBookmark (World Wide Web)Template (C++)Electronic mailing listGoodness of fitOnline helpFunctional (mathematics)Context awarenessPoint (geometry)Task (computing)Fitness functionProduct (business)Link (knot theory)Endliche ModelltheorieSheaf (mathematics)Axiom of choiceComputer programmingWordSign (mathematics)CASE <Informatik>Message passing2 (number)EmailConstructor (object-oriented programming)Similarity (geometry)Artificial lifeTelecommunicationLimit (category theory)FreewareComputer animation
23:15
CodeTelecommunicationSet (mathematics)Quality of serviceDesign of experimentsAreaObject-oriented analysis and designOctahedronSlide ruleQR codeData conversionMessage passingLevel (video gaming)Commitment schemeWhiteboardLink (knot theory)MathematicsProduct (business)Presentation of a groupData managementRight angleDifferent (Kate Ryan album)Lattice (order)QuicksortSoftware engineeringText editorSearch algorithmInformationBinary codeBranch (computer science)BitGoodness of fitLine (geometry)Traffic reportingInteractive televisionCASE <Informatik>TelecommunicationCodeSoftware bugSoftware developerChemical equationMixed realityProgrammer (hardware)Self-organizationExpert systemHeegaard splittingWritingFrictionComputer animationLecture/Conference
Transcript: English(auto-generated)
00:04
I'm Miriam Fortner, and today I'll be talking about why communication is the best skill to develop as a programmer. So in the vein of good communication, a bit about me. I studied modern languages at university. Maybe that's where my passion for communication began.
00:20
I then worked for two years building technology to be used by the UK government. I then found my passion as a software engineer and have now been working as a Python engineer for about five years. And as you've just heard, I now work at Kraken Technologies based in London. So why communication?
00:41
Of all of the thousands of things I could have been speaking to you about at a Python conference, why did I want to talk to you about communication? So at a very basic level, coding is just communication. We're telling a computer what we want it to do. And if we explain ourselves clearly enough, it'll do it for us. But unless you're working by yourself or building something
01:03
that only you are going to use, we're often writing code with people and for people. So making ourselves understood isn't just an issue between us and our computers. Good communication is what can be the difference between a good software engineer and a great software engineer. After all, what's the point of having great ideas
01:22
if you can't convince anybody why they're great and convince them why you're right? So today we're going to go through the story of two engineers. We've got Sarah, a senior engineer, and John, a junior engineer. And we're going to see some pitfalls that they might come across when carrying out a piece of work and what they can both do to improve their communication with each other.
01:45
So let's start with explaining a piece of work. We have Sarah asking John to carry out a task. Let's say it's to add a new field to an existing form. What should Sarah do to have great communication when giving John the details of this task?
02:02
First of all, she should always explain why the work needs to be done. Whether verbally or written down in a ticket, Sarah should explain why the work she's giving John needs to be done. So if we look at the screenshot here,
02:21
we've got our first iteration of Sarah's ticket. Whilst it is clear a new field needs to be added, it's not really giving us much content about why this field is needed. For example, how will the data be used? Where should this new field appear? Once we include those things in the ticket,
02:40
John, who is picking the ticket up, will have much more context to know whether he's succeeded in his task. We make so many tiny decisions every day when we're writing code. And when someone understands why they're doing something, and even better, who will be using their software, these decisions are much more likely to be successful. Secondly, don't assume prior knowledge or familiarity.
03:03
Something which may seem really simple to Sarah might not be so simple to John. Maybe John has never built a form using Django forms before, or maybe he isn't familiar with how to prevent cross-site scripting when submitting forms, and Sarah shouldn't assume his experience. So if defining this task in a ticket,
03:22
she should err on the side of caution and provide links to documentation or mention where else in the code base John might find similar changes, just like you can see on the slide here. I like to think the task is starting to look much clearer now. And my final point, Sarah should be detailed always.
03:41
So providing acceptance criteria, as you can see here for a piece of work, will help to bring out the specific details of the task. For example, where this new field should appear in the form. And more importantly, it will enable John to deliver what is needed. Overall, spending time thinking about how you're communicating when giving someone a piece of work can save both yourself
04:01
and the person carrying out the task a lot of time in the long run. So next up, John's got his requirements. Now he knows what he needs to build. So how does communication play a part in him writing his code? So whilst writing code is, of course, communication with your computer, it's also communicating with your future self and other future developers who will be reading
04:22
your code down the line. And we could do a whole separate conversation on writing easily readable code in Python, but for now, just consider the following points. So would someone with less experience or domain knowledge understand your code? Basically, use empathy. Try thinking from the perspective of a new colleague
04:40
reading a work. Is it understandable without years of experience on the code base or in the domain area? Or would your past self starting out in your career have understood the code when you started? So let's look at an example. Here we have a variable name. Imagine you've just started working on this code base. It's very fitting using software
05:02
or building software to be used by an energy company. Although you may be able to work out what this variable stands for, it's definitely not immediately obvious. Whereas now, if we call this meter point number, even though it's longer, it's actually much clearer. Using initials and abbreviations often feels like you're saving yourself
05:21
or someone else reading your code time. However, they hide meaning and often assume familiarity with the domain area. So even if it makes your names longer, it's always good to spell things out clearly. Let's look at another example. So here, we're still working at a company building software for energy companies.
05:43
This is a line in a file that collects meter readings. And as you can see, we have various bits of data and we have a meter ID. So we wanna get the actual meter ID out of this string. So as you might know, or hopefully you know, this line will work and we will get the ID
06:01
one, two, three, four, five, but I hope you agree that it's not the most easy to read. Whereas if we split that out, we call it a function, get meter ID from file line. We use nice and clear variables and we're splitting up the logic over multiple lines, even though yes, it is longer. I hope you agree that it's much easier to understand,
06:21
especially as someone who might be new to the energy domain. Next up, ask yourself, are you being consistent? So inconsistency can be the downfall in any communication and the same applies to code. So if you refer to an object as one thing in your code, be consistent and call it that thing throughout all your code.
06:41
Let's say we have a function called get meter reading. We're likely going to be using that function in a lot of places, so we want to be consistent in what we call the return value of this function. And so we could call it reading, we could call it user meter reading, or we could just call it meter reading. It doesn't really matter which one, even though I think meter reading might be the best because it mirrors the function name.
07:01
As long as we call it the same thing throughout our code, we always know what kind of object the phrase meter reading is representing. And my third point is try basing names on what a user would actually call something. This is also a concept in domain-driven development if you want to look into that anymore. But where possible, avoid using overly technical names.
07:23
Just think, what would a user of your product actually call this thing? So here, if you don't need to be specific and use the technical name, for example, for this type of electricity meter, then don't use it. Yes, if you're going to be talking about lots of different types of smart meters, or you need to specify it as a smart meter,
07:41
one, two, three, then great, use that name, but if not, keep it simple, call it what an electricity user would call it, and that's an electricity meter. And my final suggestion on how to communicate better through your code is don't rely on comments to convey meaning. If you find yourself annotating every line or even most lines in your code,
08:01
take a step back and reevaluate the names that you've used for things. Relying on comments when you think that a user or a reader of your code might not understand something can often be a sign that how you've named things isn't totally clear. So let's consider the function we looked at before. Yes, the comments here are all helpful, they're explaining what's going on,
08:22
but I don't know, me reading this, I'm like, there's so much happening, and it'll definitely take you maybe like 30 seconds to go through every line and see what the comments are telling you, or maybe you'll just ignore the comments. Whereas if instead of relying on inline comments, and you utilize docstrings, type hints,
08:40
and more explicitly named variables, as you can see here, by the time we actually get to the code at the bottom, which uses clear names anyway, we're already much more clued up on what to expect, and really usefully, we're also providing an example of the type of input that this function's gonna receive. As you can see, the input's quite unusual,
09:00
so especially in this case, it's really important for someone reading the code to know what that line might look like. Okay, so we've looked at how John can communicate well when writing his code, now he's thinking about how to parcel up his code into nice packages, and a good way of doing that is using commits. So commits have titles and bodies,
09:21
and are a record of why the code is the way it is for future contributors. So when John is writing his code, how can he make sure that his commit messages are communicating what his code does and why to future readers? So firstly, when he writes commit titles, he should always be describing what the code does, not what he did.
09:43
So if we say, added a new form field, yes, it's true, but it's kind of obvious, if you looked at the code, you know that that's what happened, because there's a new form field, whereas if we say something like, allow users to update their email address, which is what the form field is doing, it's much better describing the purpose of the code.
10:03
So yeah. Linked to this is my second point, to start commit titles with a verb in the imperative mood. So let's look at that same example again. If you're starting your commit message in the past tense, straight away, you're not describing what the code is doing, you're describing what you did in the past tense.
10:21
So I added a new form field. If you find yourself starting a commit message with added, removed, or updated, have a think about how better to communicate what your code change does. I like to think of commit messages as an instruction that I'm giving to the code. For example, in this commit, I'm telling the code, allow users to update their email address, so that's like an instruction.
10:44
Finally, whilst commit titles are a headline for what your code change is doing, often more detail might be needed, especially into the why of what you're doing. And that's where commit bodies come in. So as you can see in this example, John can give extra detail to future readers about his change by adding just a couple of sentences
11:01
into the commit body. He says where the new field will appear, the page it will get rendered on, and what this new field is allowing us to do. But beware, in a lot of places, let's say in GitHub or GitLab or any other, I don't know, source control that you might be using, often we do only just see the commit titles.
11:21
So we don't want to overly rely on the body to convey meaning. We want to really give our titles a good think and make sure we pay extra attention to whether they're communicating what our change is. So we're back with John and Sarah. John's been coding away. All his variables are beautifully named. It's great. But now he's stuck on something.
11:40
It happens to everyone. So how can he use now good communication to get an answer when asking for help from Sarah? So first of all, he should explain his problem without assuming that someone has prior knowledge of their task. Yes, Sarah might have given him the task a couple of days ago,
12:01
but a lot of time has passed since then. Sarah's got a lot of stuff going on, and John's task might not be fresh in her mind. So if John asks, hey Sarah, I'm working on my task. I'm not sure why my form data isn't submitting properly. This seems perfectly polite, but as I said, it's been a few days. Sarah's been working on lots of things. She doesn't remember exactly what the task is
12:21
that she gave John. Whereas if he includes a bit more detail, like a link to the ticket that he's working on and just a small summary, the ticket you gave me about adding a new email field to our user form, that means that Sarah is one step closer in being able to help him find a solution because she is just as clued up as he is about what the task is.
12:41
This also goes for if you're asking somebody who hasn't given you the task, which is often the case. Next up, John should definitely say what he's tried already. There's nothing more frustrating than when you're helping someone and you give them some advice about what to do and they say, oh, I already tried that. Oh, I've done that as well.
13:00
It can be quite frustrating. So by stating what you've done to try to fix the problem already, you and the person helping are both starting out from the same place. So as soon as John, we've got John's original message here. As soon as he adds a bit on, so far I've tried using the PyCharm debugger or writing a functional test to check that the data is submitted properly.
13:23
This has saved Sarah lots of time because she was maybe gonna suggest these things anyway. And now she can ask questions, for example, about what he saw when using the debugger or ask for a link to his functional test. So again, they're both starting out from the same point in solving the problem.
13:40
Also, in general, when we're sending somebody details about the code or the code we've written or an error message we're getting, always try to copy and paste this rather than using screenshots. Even though it takes you a second, just to do a screenshot, it seems so easy. If John sends a screenshot of his code to Sarah, she can't easily then try that code on her machine. Equally, if he sends a screenshot of an error,
14:02
she can't just copy that, paste it into Stack Overflow or Google and find out how others have fixed that error in the past. So even though screenshots are easy, try and copy and paste instead. And finally, always remember to be patient and show gratitude with the people you're asking for help from. In all our communication, but especially when asking someone for help,
14:21
we should be respectful of other people's time and input and we should show this through our communication. It sounds simple, but being polite and communicating your gratitude is really gonna make people a lot more keen to help you again, whereas if you're rude, they might not want to help you next time. So we've looked at things from John's perspective and now let's see how Sarah can really
14:42
improve her communication tools when she's providing help to John. So even though John really felt like he asked a clear question, Sarah still isn't 100% sure that she understands the problem. So she should ask for some more clarity. For example, Sarah could say,
15:01
so check I've understood your problem, you're getting X error when you run Y. By trying to explain what she's understood, she'll tease out some nuances of John's issue and it will also mean that they're both starting out, again, on the same place, from the same place when finding solution. Next up, Sarah should ask or find out what John already knows.
15:21
If she doesn't know about his experience, she should ask him and that will help her or help inform the kind of help that she's gonna give him and she'll know how much she needs to explain when she's helping him. There's nothing worse than feeling patronized if somebody is explaining, I don't know, how HTML works, for example, and you're really advanced in your programming
15:41
or the same if somebody just assumes that you know something and you don't know it. So it can go both ways. So if John's task is to add a new form field, she could ask, have you worked with Django forms before? Or talk me through what should happen when a user clicks submit on the form. Especially the second question will really help John solidify his knowledge and he'll be like, okay, so this happens,
16:01
this happens, this happens. And again, it'll help Sarah understand John's level of comprehension of what he's doing. Also, we've got, you could take more of a coaching approach. So Sarah should really try to enable John to find a solution on his own. This isn't always easy. Sometimes you're in a bit of a rush
16:20
and you see that problem straight away and you're like, cool, it's this. But if you've got the time and the patience, it's really good to take this coaching approach. So if John doesn't know why his form data isn't submitting, Sarah could say, oh yeah, I see it. You've forgotten to include your new field in X, Y, Z. Or she could say, what are your hypotheses on why it's not working?
16:41
Or what could cause the new form data to not be submitted? Or talk me through your code and show me where you think the problem could be occurring. So when John finds the solution on his own, it's gonna really help to boost his confidence and skills in problem solving. And it also means that hopefully next time he won't have to ask Sarah for help with the same problem
17:01
because he understands why it's not working. So next up, John's written all his lovely commits. He's got help where he got stuck. And now he's pulling it all together and he's gonna write a pull request. So depending on the context that everybody works in, you may or may not submit changes via pull requests. However, it's good to know or understand their value.
17:22
So if commits represent small code changes, pull requests can often represent a feature or a small bit of a feature. And let's look at how we can communicate well in pull requests. So first of all, you wanna say what the change is that you're making, but also why you're making it. If Sarah or John or anybody else that they're working with
17:41
goes back to this pull request in the future, it's really useful to know why a code change was made. And for example, if there's a bug now, you might be able to debug a little bit faster because you understand the reasoning behind the code. So for example, if John's adding a new favorite flavor of ice cream, he might add this section to the pull request and say that it's needed for our data science team
18:02
because of blah, blah, blah. And before this, they just had to guess what everybody's favorite flavor of ice cream was. Next up, it's really useful if John says why he chose to do something one way instead of another way. Often, a comment you might get in a pull request would be, oh, did you think about doing it like this?
18:20
And it's going to really save time for John and Sarah as the reviewer if you answer those questions up front. And a great way of doing this is just to leave a comment. So you're self-reviewing the PR. And we could say, I chose to use a choice field here rather than a plain character field, so it's to limit incorrect free text entries.
18:41
So immediately, Sarah was going to say, oh, why not use a char field? Now she doesn't have to because she knows about John's reasoning. So next up, we've got always give context. John said why he's making the code. He's saying what the code does, but how does that change fit in with the general priorities maybe of what the product is?
19:01
So more context, in John's case, could be links to documentation or best practice. It could be a reference to a previous pull request, for example, the pull request that added the new model field that corresponds to this email field. Or really importantly as well, a link to the ticket that Sarah wrote from at the beginning. Think about whether someone who is completely new to your code base or new to your work
19:21
would be able to understand what the pull request does and why. If the answer is no, it's probably a sign that you need to give a bit more context. So the other side of the coin, reviewing a pull request. Yeah, this is the last step in our journey. John submitted it. And just like when Sarah was giving John help before,
19:41
she should really think about how she can sensitively and effectively give John feedback on his work. First of all, I keep repeating myself, but she should have empathy. We want to give honest and helpful feedback when we're reviewing our colleague's code. But it's also good to think about how to put this into words in a way that the person receiving the feedback
20:02
will take it on board. That doesn't just mean molly cuddle them and be overly nice. It just means being clear and stopping people basically taking your comments personally. But pull requests aren't only for giving constructive feedback on what can be improved. They can also be a great way of recognizing
20:20
where other developers have done something well. So we should try and say when we like what somebody has done. For example, if feedback to John would give, I really like how you refactor this function, it makes it much clearer. This is obviously going to give John a little boost of serotonin, because it's a nice thing to hear. But also, it tells him that he's doing something right.
20:42
And without this comment, he might not know whether the way he refactored was any good at all. But he's got that feedback, and he knows, great. Next time I'm refactoring some code, I can try doing it in a similar way. Thirdly, just as John explained why his code changes were needed, Sarah should also explain
21:01
if she's making a suggestion, why her suggestion might be better than what John already has. So just saying, I'd actually try to use this line instead. It might be right, and John might just paste it into his code. But he might not really understand why that line is better than what he had before. Whereas if she says, I would use the line below instead,
21:22
as it's easier to read and will render the flavors nicely in the template. That means next time John, I don't know, is writing. At list comprehension, he has good advice from Sarah, and he knows that this is a good way to do things in the future, and most importantly, why it's a good way. And finally, after having reviewed all the code changes
21:42
in John's PR and added all her comments, when Sarah submits her review, it would be really useful for her to add a short summary. So imagining Sarah submitted about five comments, when she submits the review, she can add an extra message and say, looking good so far, John. Your commits were really clear.
22:00
I've left some comments around how your functions could be refactored to be more readable and dry. So that's summarizing her points. It's showing to John, great, you seem to have got a good gist of the task. But yeah, these are why I've suggested these things you could change. Again, we shouldn't mollycoddle people. We should also, as people receiving reviews,
22:21
we should learn to not take things too personally. But just adding this extra kind of human contacts in a review can be really helpful. So we're at the end of our journey. John's release has changed to great applause by all his users. John and Sarah are high-fiving with their giant hands. And let us think, what are the main takeaways
22:41
from John and Sarah's communication, both with each other and through code? Firstly, all roads lead back to empathy. On both sides, Sarah and John thought about the other person's experience, feelings, and time when communicating, and they were much more successful because of that. And secondly, if you're not too much into empathy,
23:01
not everybody is. At least think about yourself. Even if we're not motivated by empathy, the code that we're writing today will be read and used by our future selves. So let's make life as easy as possible for us in the future. And that's everything. Yeah, I've got the QR code that you can scan to download the slides and my GitHub
23:22
and LinkedIn usernames. Thank you. All right, thank you so much for this presentation. If you have any questions, you can move to microphones.
23:40
You can also ask in Discord channel. Thanks for the talk. It was quite informative. So I think this talk was more about communication between two technical people. But more often than not, you have non-technical people
24:02
in the team as well. So how do you have a good balance between, say, in a meeting where there are a blend of people so that you have any tips on that? It's a good question, yeah. And I think that's a really big skill that us as software engineers have to develop. I think when we're in a mixed technical ability meeting,
24:21
it's really important to not go too much into the detail where it's not necessary. If you start getting into, I don't know, lowering the details of why you should be maybe using one class or over another or something like that and your product manager's there, you're just planning, you should say to the other technical person, let's take this offline. We'll have a more in-depth chat later.
24:41
So I think it's really about knowing what the purpose of different meetings or conversations are and, yeah, separating that out. Yes, I have also a question. Quite often, I'm, for example, working on some code. And I try some things, and I make a commit for that.
25:03
And usually, I have in my commit message, try this or that or that. And usually, well, it fails because you need a few tries before it works. Do you have some tips on writing good commit messages for those kinds of commits that are not really a final feature in which it's complete? Yeah, definitely.
25:20
We were actually talking about this in my team a couple of weeks ago. So I think you've got to think about what stage of the work you're at. And I like to think of everything before I'm asking for a review. Those commits are just for me. So yeah, if it's telling you a story of what you did, you're going back and saying, OK, fix this in that commit. Fix this, X, Y, Z. But it's really good to use squashing or fix-ups
25:41
maybe within an interactive rebase and make that commit history kind of beautiful again before asking for a review from someone else. And then I think the next stage after that would be you might get reviews. You might then add small commits along the way. And the next checkpoint is before you actually merge your code, you should then go back,
26:00
rewrite the commit history through whatever tools you prefer and make sure that it's telling the story again. And also about squashing your commits, in the past, I sometimes had to debug some code. So a bug was introduced somewhere along 200 commits. And I used git bisect then to kind of use binary search
26:24
algorithm to, in quite some small steps, to pinpoint the exact commit in which it happens. But if you would use git squash to kind of combine a lot of commits into one, you would lose that kind of friction. Sorry, yes. I meant squashing kind of commits you've used to fix things that were broken
26:40
in previous commits. Yeah, those aren't working anyway. Yeah. I agree that I don't really prefer to squash all commits before merging, for example, into your main branch because you do lose all of that history. So yeah, it's about what tools to use along the journey. Yeah. Great. Thank you. No worries. Well, thanks. Kind of related to the past question,
27:02
we kind of covered it a bit. But I was just wondering on where the good line between sort of detail in the commit body versus detail in the pull request is and sort of especially with commits showing up on mouseover in my code editor, for example,
27:20
and just how you kind of make sure that kind of stuff is easy to find but not repetitive, repeated. Yeah, I get you. I guess, yeah, thinking about where different pieces of information are displayed is important, as you said. Get blame. You'll often maybe just see the title of the commit, maybe the message, and then you can click deeper
27:40
into the pull request. So I'd say most important information to do with that one small code change within that commit should obviously be going in the title and the body. In a lot of cases, a pull request will be multiple commits. So that's kind of telling a story of what those, let's say, five commits, 10 commits, maybe not that many, what all of those code changes are doing together.
28:01
Whereas, I guess, the commit message is just telling the story of that one individual code change. So I guess if you split it up nicely and atomically, then hopefully that's not too much of an issue. Thanks. Yeah, to come back to the two previous questions. So my name is Chris. I wrote a book on communication for engineers.
28:20
So I really love seeing talks like this at a technical conference. So when I watch your suggestions, I've figured out one thing. I've worked at large companies, and often work is orchestrated using tickets. You have feature requests, and you have bug reports. Writing a bug report is another slide that you can do.
28:42
So the tickets are usually the interaction with other people that are not programmers. So there's the explanation of why we do things, and so on. So large organizations realize this. So when you do a commit, you always attach a ticket to the commit. So what are your thoughts on that? Because then I don't have to explain in the commit
29:02
or in the PR why I'm doing this, because I just referred to the document that's already written by the experts on why we're doing the work. So splitting up that work so you can actually focus on the technology rather than the why. Sure, yeah, that's a good question. I think let's say you're in a big organization,
29:20
and you're using Jira to store your tickets. A year down the line, maybe there's a big change from all the product managers rebel, and they want to use Trello instead. Those Jira links aren't going to work anymore. Also, people might lose access to particular boards, for example. I don't know, maybe I'm a user or a developer
29:40
on a different team, and I'm looking at your commit, but I don't actually have access to your team's board. So yeah, I think just using links to describe what a code change is doing can be quite short-term, basically. Whereas great, use them to supplement the detail, but you want to have what's most important written out as well.
30:00
Thank you. We need to stop. You can ask your questions in person. You can reach Maria. Thank you so much for your questions and participation. Thank you so much for your presentation. Thank you. Thank you. Please.