Software patterns for productive teams
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 |
| |
| Subtitle |
| |
| Title of Series | ||
| Number of Parts | 118 | |
| Author | ||
| 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/44804 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
| |
| Keywords |
EuroPython 201967 / 118
2
7
8
15
20
30
33
36
39
40
45
49
51
55
57
58
63
64
66
68
69
71
74
77
78
80
82
96
98
105
107
108
110
113
115
00:00
SoftwareGoogolPoint cloudSystems engineeringContext awarenessHacker (term)Perspective (visual)Stress (mechanics)Product (business)Multiplication signInternet service providerProcess (computing)Linear regressionDifferent (Kate Ryan album)Confidence intervalTask (computing)Product (business)SoftwareStability theoryOrder (biology)Client (computing)Perspective (visual)Software testingFlow separationSoftware developerContext awarenessPoint (geometry)2 (number)Stress (mechanics)State of matterDataflowBitMoment (mathematics)Sheaf (mathematics)Independence (probability theory)Figurate numberSlide ruleLevel (video gaming)MereologyDisk read-and-write headBookmark (World Wide Web)Hydraulic jumpResolvent formalismComputer animationLecture/ConferenceXML
06:53
Process (computing)Arithmetic meanMoment (mathematics)Lecture/ConferenceMeeting/Interview
07:28
Level (video gaming)Order (biology)SoftwarePresentation of a groupCodeConfidence intervalIntegrated development environmentClient (computing)MathematicsCode refactoringProjective planeProof theoryProper mapSoftware testingProduct (business)Linear regressionCASE <Informatik>Multiplication signSoftware developerContinuous integrationVolume (thermodynamics)Computer animation
10:14
Software testingWritingPublic domainModul <Datentyp>Computer fileSoftware testingGoodness of fitLine (geometry)CodeComputer fileRevision controlService (economics)Text editorModule (mathematics)CASE <Informatik>Integrated development environmentFormal languageDifferent (Kate Ryan album)Latent heatComputer architectureLogicMereologyFlow separationProjective planeDiagramTheory of everythingPublic domainSinc functionAbstractionType theoryMobile appProduct (business)Heegaard splittingSound effectComputer animation
12:53
Local ringKey (cryptography)HoaxEmailService (economics)Menu (computing)Scripting languageSoftware testingSoftware developerSoftwareData structureKey (cryptography)Virtual machineFrustrationIntegrated development environmentProcess (computing)SpreadsheetSoftware testingScripting languageMaxima and minimaMultiplication signLevel (video gaming)Disk read-and-write headDifferent (Kate Ryan album)Set (mathematics)Link (knot theory)WordOrder (biology)NeuroinformatikVariable (mathematics)Projective planeWhiteboardPhysical systemFlock (web browser)CodeMoving averageDrop (liquid)Computer programSign (mathematics)Service-oriented architectureBootstrap aggregatingLecture/ConferenceMeeting/Interview
17:28
Software testingSuite (music)Software testingAdaptive behaviorGoodness of fitScripting languageFeedbackLoop (music)Lecture/ConferenceComputer animation
18:53
Software testingError messageState observerContext awarenessSuite (music)Entire functionMathematical optimizationLecture/Conference
19:27
Web pageAbstractionDependent and independent variablesError messageDiagramAbstractionClient (computing)PlastikkarteMultiplication signBitData conversionOrder (biology)Software developerEntire functionWeb pageState of matterOpen sourceDescriptive statisticsNegative numberSoftwareMereologySoftware bugRevision controlGastropod shellProjective planeDecision tree learningCodeProduct (business)Process (computing)Scaling (geometry)Computer programControl flowView (database)DataflowSoftware testingHidden Markov modelComputer animation
27:44
Rule of inferenceWritingAerodynamicsReliefSystem callPerspective (visual)Coding theoryReading (process)Digital rights managementProjective planeData structureDataflowDecision theoryWeb pageFlow separationDisk read-and-write headDependent and independent variablesArithmetic meanRule of inferenceRotationRevision controlGoodness of fitSoftware frameworkExistential quantificationCurvatureTelecommunicationBitChaos (cosmogony)Perspective (visual)Functional (mathematics)Machine visionDifferenz <Mathematik>Multiplication signSoftware developerCode refactoringBuildingPosition operatorProcess (computing)ResultantExpected valueLine (geometry)Latent heatWritingSurfaceDifferent (Kate Ryan album)CASE <Informatik>State observerControl flowCombinational logicSlide ruleXML
36:00
Reading (process)Digital rights managementData structureData managementPosition operatorChannel capacityChaos (cosmogony)Spectrum (functional analysis)Line (geometry)Computer programmingRotationMedianDependent and independent variablesCASE <Informatik>Reading (process)Goodness of fitAdaptive behaviorLecture/ConferenceComputer animation
38:09
Electric currentSoftware developerPoint (geometry)Process (computing)Game theorySoftware developerPoint (geometry)MereologySoftware frameworkResultantLecture/Conference
40:06
Multiplication signPerformance appraisalData structureAnalytic continuationRotationPosition operatorGoodness of fit2 (number)Lecture/ConferenceMeeting/Interview
41:00
Point (geometry)Right angleWeightProcess (computing)
41:39
Position operatorRotationRevision controlPattern languageSoftware developerLine (geometry)Level (video gaming)Set (mathematics)Integrated development environmentGroup actionDifferent (Kate Ryan album)State observerSystems engineeringStack (abstract data type)SoftwarePrincipal idealHierarchySoftware engineeringFigurate numberMeeting/Interview
42:54
Different (Kate Ryan album)RotationPosition operatorMultiplication signHierarchyFigurate number
Transcript: English(auto-generated)
00:02
Thank you everyone. I'm Radislav, I'm coming from Sofia, Bulgaria, all the way to Switzerland. And this is my third EuroPython and also this is my third time speaking at EuroPython. And I'm really happy and I'm really grateful for having this opportunity. So thanks for having me and I hope this will be a good talk for you.
00:24
The goal of this talk, as always I want to be really practical, really pragmatic and I want to provide value for you. So you have 40 minutes spent really well here in this room. And actually the thing that I'm looking for is this aha moment, let's use this from this guy's talk, from this very particular slide.
00:46
So this is my end goal. So if at least a couple of people have this aha moment, then I'm going to be happy because I have provided value for someone. So, context. I'm the CEO of HackSoft, this is a software development company and we develop software for our clients.
01:04
And usually our clients rely with their businesses on the software that we develop. We develop this software in teams of course. And in order to have a stable software and happy clients, we need to have a pretty good team. We need to have productive teams that can ship quality software and not break production every day.
01:23
This is very important because otherwise clients are losing money. And this is how to say, it's a very important thing. I will provide some cherry picked examples from the last six years, from being a team lead on several different teams.
01:42
And I hope this will be valuable for you. The agenda. We'll jump straight into the topic. I will talk a little bit more about the team leader's perspective. For me as a team leader, what I care for and what I optimize for. After this I'm going to talk a little bit about software development and what kind of problems we can have there.
02:03
And how can we solve those problems. After this we're going to talk about features because after all we create new features for our clients. And in the end we're going to finish in a Pythonic way with a section called explicit is better than implicit. Because after all we are at EuroPython.
02:22
So, team leader's perspective. Aside from being the CEO of the company, my day to day job involves developing with Python, with Django and with JavaScript. And I'm a team lead of several teams at the company working for different clients. So, I've developed this perspective because at some point I said to myself, okay, I have a team, things are going well.
02:47
But I have no formal education for this and I have no idea how I'm actually running the team. I have to formalize, I have to write this down because if I want to transfer my knowledge to someone else then I really can't do it.
03:01
Because it's all in my head. So, those are kind of the seven things that I care for and that I optimize for when I'm running a team. And this is what we're going to cover. We're going to have problems that impact on those seven things and we're going to try to solve those problems. So, first of all, productivity. This is very important.
03:23
We have to ship software to the clients. We have to have something working, used by end users, being on production. I think we can all agree this is very important. We need to ship software. So, first of all, productivity. Second of all, I want my team to ship features with confidence.
03:43
Because if we have a pretty unstable production, and I believe you've seen this, people will be hesitant to merge pull requests and to deploy to production because they know they have to fix other things, regressions, you know, constant regressions.
04:01
And we want to eliminate this. We want to have higher confidence because this will make the team better and they will enjoy the work they do. Also, we want to have independence in the team. As a team lead, I don't want to be the bottleneck of everyone. Everyone asking me questions. Or rather, should I do this or should I do that? I don't know, figure it out.
04:21
Run several tests and you can pick the better solution. So, this is quite important. We want our team to be as independent as possible. Also, well-being. If you're working on a stressful project and you're stressing your team more than needed, they will burn out.
04:42
And when your team burns out, then you as a team leader, you're also going to burn out. And when you as a team leader burns out, then the software is going to burn down. Software doesn't burn out, it burns down. Everything is going to crash. So, this is quite important to have a healthy team because if you push your team too far, everything will eventually crash because software is created by humans.
05:05
And humans need to be in an okay state to do this. Also, something very important for me. Less context switching. Being a developer, it's very important to be in this flow state. We all know the flow state. We're working on something. We are in it.
05:21
We are wired in. Couple days in the future and we're feeling pretty good. And suddenly, people start asking us different questions on topics that are not related with what we do. And if this is happening constantly, then we will be constantly breaking people's flow, which means they will be less productive, less happy, and this will increase the stress level.
05:43
So, my philosophy for context switching is that the team leader should handle most of the context switches. This is part of the job and that's why it's a hard job. And you should reduce the context switches in the team. There will be some, of course. But you should try to reduce them because then people will be productive and they will carry on the tasks they have to do.
06:07
Also, someone being blocked. This is my favorite. You know, you have a team of five. Two people are working like crazy. The other three are just, what should we do? You have a task, but we are waiting for the client. Have you asked questions?
06:21
No. Stuff like this, you know. You have to observe people being blocked and not working. You have to make sure everyone has a good knowledge on what they're working on and there's nothing blocking them. Or if it's something blocking them, resolve it immediately. Otherwise, there will be people working like crazy and people just idling around, making coffee.
06:41
And of course, the last thing, which is really hard to quantify, but it's the team morale. You know, this is the general feeling of the team. Are you going to work every day and you feel the team is like, there are better things that we can do? Especially that right now it's summer in Bulgaria. Or the team is like, we're shipping something quite interesting, users are going to use it.
07:05
We want to do this. We kind of enjoy, we find meaning in what we do, we kind of enjoy our job. So, this is something that is, again, really hard to quantify, but as a team lead, you can get a feeling of the team morale. And it's really important to keep that up.
07:22
So, I will go one by one, cherry-picked examples, going for the aha moment, this makes sense. And I guess we'll have questions, we'll have time for Q&A at the end. And the first thing that usually happens when we're developing software in a team environment and it's a low-hanging fruit are the constant regressions.
07:44
You know, constant regressions, what do I mean by that? This is production going down every hour, every day, something breaking, you create a new feature that breaks several other features. And the reason for that most often is because you have a client and the client says, all right, let's do a quick proof of concept for two weeks.
08:05
We just want to see if this is viable. You do the quick proof of concept, of course, and then the client is happy. And without telling you, the client is now onboarding on your dev environment, actual users. Your dev environment becomes production environment and the client starts pushing you for new features or complete rewrite of everything.
08:26
Because for the clients, when they see something working, they want to be like new feature, change thing, new feature, change thing. They want to be like snap and have the code base changes. You know, this is how clients think about software and we all know this is not the case.
08:43
So usually fixing constant regressions involves, and as I said, this is a low hanging fruit, those things. Stop all feature development. This is really working. You know, you say to the client, all right, we are stopping for, I don't know, a day, two days, a week. And we want to stabilize things because we cannot develop like this.
09:02
We need to make this proof of concept, a proper production setup, add some tests, refactor some of the code. Because we've been cutting corners in order to make it for the two weeks because you have a presentation at some conference. But now let's make it stable. And if you explain this well enough to the client, it usually works.
09:21
Also, it sounds strange, but add a continuous integration and please have tests. Because you may say, well, every software development project has tests. And I will say to you, no. We are constantly having requests for, can you take a look at this seven years old Django code base?
09:41
That's huge project that's running mission critical stuff for the business and has zero tests. Oh, and the developers, by the way, they just left us. So we need someone to figure this out. So this is very important. So let's say you have a continuous integration, have tests, we'll talk about tests later, and add a staging environment where you can safely test and break without a problem.
10:03
And this is fine. Now we have higher confidence because we have staging, we have tests, we have CI. Then all things are going well. You start working on different features. And this is a case that I observe very often. For example, we have Ivan and Maria and some other folks working on...
10:24
Ivan is working on a specific feature. Maria is working on a different feature. Those features have nothing in common. And let's say we're running in a Django environment where we have an app and we have our services PY file where we put our business logic. And this is just one Python module. And since Ivan and Maria need to write something related to this app, which is a new feature, they're going to write it in the services PY file.
10:47
And because we've started small, we also have a simple test services PY module where all the tests are for the different services. And meanwhile, to spice things up, other folks are fixing existing services. And guess what happens in the two yellow boxes?
11:04
Constant merge conflicts. Constant merge conflicts because we're trying to, after all, be productive and move fast, move quickly, shift features. And this can be very, very frustrating. And it's very easy to do something about it.
11:21
And since we're working in a Python environment with Python language, if we have a services PY module, we just make it a module that's a folder with submodules inside and split by domain, split by features. The thing that we try to do is to isolate different people working on different features in their own files.
11:40
This gives effect and it's a nice way to kind of separate people not stepping on their toes. And diagram-wise, it looks like this. We just split the services in different features. We do the same thing for the tests because I usually see people splitting the features but not splitting the tests and adding up with test
12:01
files with two, three, four thousand lines of code that you need to split because first it's slow in the editor to load all of this. And then it's really hard to fix merge conflicts that spans two different test cases for two different things. Sometimes get this funky. So with this, when you see it, you can optimize it.
12:25
We usually do it when it's needed. We don't start with let's create an architecture for this because this project is going to take five years to make. We don't know this. But when we identify we are running in some merge conflicts in some part of the code base, we try to split things around, we try to figure out abstractions so this is not happening.
12:45
All right. And then we continue. Local setup. This is a specific type of hell and I love it. If your local setup is not okay, your developers can't even start working on their features.
13:02
This is like maximum level frustration. You have to do something. This something is required by the end of the week. It's easy, you know what to do, but you can't get your local environment running and it's really, really, really, really frustrating. So my job as a team lead is just to sit down and make sure everyone, for example, has accounts for altered parties that we're using.
13:27
Zero, Go Cardless, AWS, whatever. Keys, accounts. I want to know that everyone on my team has the proper access to whatever is needed. So when they need it, and I did this before, it's needed because when they need it, it's already there and they won't be pinging me.
13:45
I have to go out of context and create this for them. And the thing that really helps is organizing, keeping a spreadsheet. If something is really hard to do in your head, if I'm running a team of two people, I don't need a spreadsheet because it's two people.
14:02
Everyone has access. But if your team grows bigger, it's really hard to manage it in your head and then you have to start managing it somewhere else. And this is like a really important key takeaway for software development, for team leadership, or whatever work you have to do. If things get too big and you cannot fit them in your head and you're going to forget about things because this is what we do as humans, we forget.
14:29
Just add a spreadsheet, add a Trello board, something, write this thing down so you have it as a reference after this. And then you have accounts for everyone, but I don't know how to start a project.
14:43
It looks like Django, but has several different... I need an InfluxDB running locally on my machine. This is the first time I'm hearing about this. I need a salary broker, stuff like... I don't know how to run it. And in order to unblock your people to be able to work and to develop locally without problems, you have to document relentlessly.
15:05
And I mean relentlessly. Everything should be written down. And not only written down, because what usually happens is team lead says, person x, please create a documentation because you know how to set up everything. Person x creates it, but because everything's running okay on his computer or her computer, they can miss a step.
15:25
So you have to then take the documentation, test it yourself, and give it to someone else so they can test it. And if you achieve a running local environment, then the documentation is okay. And actually this is... I love this because when you onboard new people to the team, this is a great test how well structured your team is.
15:45
Can you provide a set of links and documents to the new onboard, to the new hire, so they can get up and running within a few hours and start actually working? If you can do this, then perhaps you've done a good job with the structure of the team. And that's why just relentlessly document. I know this is... what's the word in English for this?
16:06
Cumbersome or not very pleasant. People don't like to document or document local setup, but you have to do it in order for your team to feel better. Not to have, I cannot run this. I cannot develop because I cannot run this. And on top of this, because we are programmers, if we have a good documentation, we can then create scripts to automate most of the setup.
16:29
Usually in all of our projects, we have something called Bootstrap, which just creates a local environment that's ready to go. And for example, if we have like an additional zero dependency that's not required for the majority of the system,
16:43
we have a script that's set of zero or sets up Go cardless, or we have a script called everything that sets up, as you can guess, everything. Which may take a few minutes, but you know, after you run the script, it's going to say you're missing X, Y, Z as dependencies or environment variables or keys.
17:02
And once you do this, you're ready to go and you can start working on your local dev with all dependencies set up. It's worthwhile investing time in this because we end up doing quite a lot of bootstraps, quite a lot of, okay, we did something, let's bootstrap, let's start clean. And this is actually helping us a lot.
17:25
And next, speed of tests. Very important and often overlooked. Imagine you're working in a team where you have to do small PRs, merge often, and deploy often. And your test script takes 10 minutes to run on CI. You're not, 10 minutes is liberal, you know, you can be 15, 20 and more.
17:50
You won't be feeling very productive. And you know what? Humans adapt. But if you want your team to make short commits and commit often, and also your tests take 10 minutes, they won't do short commits.
18:03
Because instead of doing five commits and taking an hour, I will just bunch things into one commit because I know tests take a while. And this is something that is very often overlooked, but really, really, really important. You need this quick feedback loop from the test. It's not a trivial problem to solve.
18:24
There were plenty of good talks at EuroPython about this. You have to just figure it out because people adapt and their work style will adapt to the speed of the tests, which is strange, but it happens. For me, the solution of the problem was to install pytest xdist, just say minus m4, and from 10 minutes it went to five minutes.
18:48
I felt really good because let's try this and let's see if it's working, and it's working. And after further test optimization, we managed to get it down even further. And this paid off because people now started working in smaller commits because tests were running faster.
19:05
But you have to figure it out for your own context. And minus x means fail on the first error because sometimes you don't want your entire test suite running on CI if there is an error.
19:20
It helps out. Optimize your test, it pays out. It really pays out. It was a strange observation that people adjust to the speed of the CI, but it is. All right. Working with clients. They request stuff. We call this stuff features.
19:42
Sounds better. Instead of working on stuff, I'm working on features. And features can be a source of a lot of problems, and make sure everyone's on the same page with this. First thing that can be really problematic are feature descriptions.
20:01
No matter if you're using Jira or Trello or whatever you like or whatever your team is using, there is usually a client or a product owner that says let's do this. And they will either provide you a card with some description or let's do this, and you have to create the card with some description.
20:22
And if this description is not correct or if you have not understood as team lead, for example, what needs to be done, people will be working on the wrong thing. And after a week, you will find out when the client is testing or the PO is testing, and they say, hmm, we were expecting something else.
20:43
This is not what we were expecting. And this can be quite detrimental to the team morale and to the productivity because you just do work that's going to be undone and redone again. And sadly, sometimes it happens, sometimes you do something that's not going to make it, but if you do this for every feature, it's bad.
21:05
And the thing that I usually try to do is to ask a lot of questions. That's why clients don't like me very much because I ask a lot of questions, and they have to think and they have to answer those questions. But once this is ready and we know what we are actually doing first, we may
21:22
save some over-engineering that's not needed currently because when the client says I want something, we as programmers start to expand and inflate and cover all the cases and make it backwards compatible and make it production-ready for millions of business as usual for us.
21:43
But after some questions and after some talking, you can scope down the feature, you can write it, you can create diagrams, and you can leave it in a good state because then you don't have to repeat the entire conversation. It's like, can you please read the card and say something that's not okay according to the client?
22:04
And then you can safely give this card to the team, to the developers. And another very important thing, make sure they read the entire card because you've just spent an hour or two writing down a good description, creating diagrams, then a developer takes the card, reads it diagonally, and still creates something else.
22:25
And still there's work to be undone and stuff like this. So it's very important to have some kind of planning, don't overdo it, but some kind of planning so everyone's on the same page. At least from my experience, this is very important.
22:40
Saves a lot of headaches and you will not have all the negative impacts of work being undone. So, Ivan and Maria, they're briefed, they know what needs to be done for two specific features, and they start working on those features.
23:02
But feature A and feature B, although different, they rely on common piece of software that can be either there or yet to be implemented. And again, since we're working in team, we have to synchronize this because what can happen? Ivan and Maria, if, for example, this common piece of abstraction is not implemented, they will implement it themselves.
23:26
And after this, we will have to undo some of the work or all of the work because they haven't synchronized between them that they need this common piece of software. Or there can be abstraction and Ivan adjusts the abstraction for his needs. Maria does the same thing for her needs, and in the end, we have incompatible abstraction in the middle.
23:46
And this happens quite often, and the way to solve it is to first identify it, and then have them pair on the common part so they're on the same page. They know their requirements, they know that this abstraction is going to be
24:01
okay for both features, or create the abstraction so it's okay for both features. And then they're going to do their job and you won't be undoing work again. Undoing work can be very detrimental to the team morale. We kind of attach ourselves to the code emotionally, and when this code is deleted,
24:23
people take it negatively, like they've done something bad, and sometimes it's not like this. So this is very important. Make calls conflicts. All right. Okay. I'm okay with the time. I can slow down a bit. And those were some cherry-picked examples from, you know, day-to-day software development and how
24:44
to solve problems that are happening quite regularly and to keep your team happy, keep your team productive. And now the part that I call explicit is better than implicit because we're at the Python conference. This is a favorite scenario. There's a bug. You know, sentry error in a Slack channel.
25:05
We have a team of four, they're happily developing features, communicating, everything's fine, but suddenly there's a sentry error. And what usually happens is that the sentry error lofts attention and it gets the attention from all the developers because there's notification in a channel that's dedicated to sentry errors.
25:25
And what usually happens? Everyone starts looking at the error. Everyone starts running some shell to check things around. Everyone starts looking at the code. If they synchronize, someone will make a fix. If they don't synchronize, several people can make a fix. Then they have to synchronize which fix should go to production.
25:46
Two hours have passed and it's lunchtime. And, you know, this is, at least for me, a really bad way to break the flow of your entire team. You have four people and suddenly you have one person who's four people acting like one to fix a sentry error.
26:09
And if this happens once a week, it's okay. It's bearable. You know, it may be a really bad production error that requires the attention of everyone. But if this is like a really small error that's quite easy to fix, it's bad to break the flow of your entire team.
26:25
And this is team of four. It can happen the same for team of seven. Because if there's an error and people care about the project, because if you have a team that does not care about the project, then nobody will break attention. But nobody will fix the error, which is also bad. For me, this is quite bad.
26:43
And it was happening quite often at different teams. So we decided to do something that's, you know, like a standard approach. Have a dedicated, explicit firefighter for the week. This is the developer who's going to
27:01
be the first responder to one or many like a team, depends on your scale. This is going to be the first responder to an error. Nobody else looks at the error because they know there's someone explicitly dedicated this week to fix errors. And only if the error requires the attention of someone else, then ping. Then take the attention of the other people.
27:25
And this helps a lot. This increase the productivity and increase and reduce this panicking times where, oh, there's error, there's error. And everyone's running around contributing, you know, making it seem worse than it is. And this explicit firefighter, you rotate it every week so everyone goes on that duty.
27:46
And it works really well. And while we're at explicitness, there's one more team rotation after this. While we're at explicitness, something that's, again, a low hanging fruit, but I've seen problems with this.
28:05
Your team should know very well the way that you're working with Git and GitHub. Because I've seen teams where several people are using Gitflow and several people are using GitHubflow on the same project. And they're happy, but it's not compatible inside the same project. So make sure you have written explicit rules for how you use GitHub.
28:29
This is the flow that we use. This is how we do pull requests. You can have pull request templates, issue templates, all the good stuff that's provided, for example, from GitHub. And perhaps Bitbucket and GitLab. So everyone's on the same page for how you're using Git and how you're using GitHub.
28:45
Otherwise, there's going to be chaos. My fixes are in develop. What's develop? We're merging master, you know. So no matter what you use, it's really important to have this. Those slides should have been before the previous slide, but no worries.
29:02
And another thing that I've observed and it pays off really well is to separate refactoring from feature development, especially on big projects. Because sometimes you want to do a small bit of refactoring and also introduce a feature with this. And what happens when you do this is you have a very unreadable pull
29:23
request because you may hide new feature or new functionality in the refactoring diff. Because the diff is going to be this was removed, this was added. But it's not the same remove and the same added with different name. We have two more lines in the middle. And people can overlook this at pull request reviews. And those two lines can actually break.
29:47
So it's really hard to read. And the other thing is if this pull request breaks something, now you don't know was it the refactoring? Was it the new feature? Was it the combination of both things? So refactoring should be just refactoring.
30:01
And then after this, make a new feature pull request because it's going to be much easier to read. Mostly new lines. You don't have pull requests where you have 200 new lines, 200 removed lines. And it's beautiful, you know, red and green, but it's really hard to read. And while we're at the explicit thing, writing down how you do pull
30:25
requests and writing down how you do, you know, refactoring PRs versus feature PRs. It's a good idea to have something that we call team rules, to write everything that's implicitly known in the team down.
30:43
Everything that's, this is how we do things here, because when you go to a new team and you ask, why is this like that? And someone answers, this is how we've always done it. It's a good idea to sit and write down all those implicit rules and make them explicit and have them at one place.
31:01
Because first, you can spot strange things that are no longer valid and you can fix them. Second, everyone on the team can be on the same page. You kind of establish a framework for everyone and you say, if you want to be on the team, this is the framework that we follow. This is how we do things in this team. It may not be optimal for every case, but this is how we do things here.
31:24
This is very important for people, for coherent teams, to have coherent teams. And also, again, onboarding new people, this is great, because when you onboard a new person and everything's implicit in the team, this new person has to navigate those implicit rules.
31:44
Ask questions, understand from observations. While it's much better to provide him a document or her document and say, you know, this is the framework of the team, read it, ask questions if something's not clear enough, and let's go with it.
32:02
So very important and actually yields good benefits, those team rules. Again, make it explicit instead of implicit. And while we are at the explicit and implicit, that's something else that we've observed and it's very important, at least for me. Have an explicit leader. You know, there are teams with flat structure and there's an implicit leader.
32:27
There's this person that everyone listens to and everyone kind of knows that's the person that makes the final decisions. And it's, again, a good idea, as everything else, to make this person explicit, to say, this is the team lead, he yields, he's responsible.
32:47
If something goes wrong, he's responsible. The leader is responsible for this. And he also, or she also makes the final decision. If there are people arguing, then the team lead makes the final decision.
33:01
And it's really good to have this, otherwise there's going to be implicit one and politics will be involved, sadly. And again, know who the leader is. And something that I was leading a team at HackSoft and then I gave this team to someone else who's now the new team lead and he did something very, very smart.
33:25
He said, let's rotate every week the team lead. Because when you are a team lead, you have a different perspective. And not always developers will know what's in your head or will know what's it like to be a team lead.
33:42
And when you start rotating them, first they start understanding way more things and they start understanding why such things are like they are. And then they have more responsibility, they're more involved, they find more meaning in the job they do.
34:01
Because this is what, when you are on a leadership position, it's quite different. So this yielded really good results. Break in 10 minutes. And I can highly recommend it to give it a try. Just rotate team leads. Again, have everything explicitly written down.
34:20
Make it easy for someone to step in. And also this will, how to say, this will improve the team with everyone's perspective. Because sometimes when you have a strong leader in a team, he will push his perspective and vision. At the end it will be mostly that.
34:41
But when you rotate people on the team leading position, then you're going to enrich this team perspective and enrich this vision with everyone's vision. And everyone will feel way more involved inside the team. Again, I can highly recommend this. And we'll finish with conflicts, but not merge conflicts, but rather human conflicts.
35:07
This is something unavoidable, at least in my opinion. If there is a team without a conflict, then there is just a conflict waiting for a proper time to surface. And it's really important how you're going to handle the conflict.
35:25
Overcommunication seems like a really, really good general recommendation. Because often times conflicts come from people not communicating enough between each other. Having expectations for someone else. Having expectations, for example, person A has a specific expectation for person B.
35:46
And when person B does not meet those expectations, there's already a conflict. So it's really important to lay down expectations, to over communicate. There will be people that will work. It's going to be hard for them to work together, and you have to identify this.
36:03
And depending on your structure, sometimes it's good to make them work together more. So they can start playing well with each other. Or sometimes it's a good idea to not make them work together for a while. Until they figure out different things that they need to solve for them.
36:22
And I cannot give good recommendations here, because it's a hard topic. But read books on management, read books on leadership. It helps a lot. Practice it. For example, rotation on the team leading position is a very good practice for everyone to have this leadership capacity in themselves.
36:45
And there are always toxic people that no matter what, they will be toxic. And they kind of enjoy chaos and anarchy and bringing things down. You have to identify this. Sometimes it's fixable, sometimes it's not fixable.
37:02
Then you have to let them go. There are people on the other side of the spectrum. There's something called malicious obedience, where they do exactly what they've been told and they don't think. They're kind of dependent on you, and it's like you're telling them step by step like a computer program what to do.
37:20
And they do exactly this and nothing else, which is also not a desired trait inside of a team. So you have to learn to identify those things and somehow work around them, fix them. And firing is really hard, easier said than done. It's really, really, really, really, really hard.
37:40
Because when you have to fire someone, at least for me the first thought is, well, it's my responsibility that this person is not fitting well. I have not done enough things. And it's usually the case. But you have to kind of see where the line is and you say, I've given enough opportunities.
38:01
It's not working. Let's see what we can do about it. And of course, finally, adapt. But if you have processes and you follow them blindly, people will learn to play the game and will be, again, unproductive and ineffective.
38:22
Humans are really good at adapting and they will adapt, they will learn to play the game. So you have to make sure those, at least for me, those seven traits for a team are always met or we are doing something about them. Because if you say, alright, I've invested a week, here are the processes, this is the framework, done.
38:43
I have no longer, I don't have the need to touch it. Just follow the processes blindly, this is not working. You know, things are changing, people are changing, circumstances are different. So you need to adapt. You need to, not constantly, but often, perhaps once a month revisit everything.
39:01
Check if everyone's happy, check what's happening. Be friends with your team and adapt everything. And perhaps the takeaway, ask your developers for pain points and they will tell you. Because if you think there are no pain points in your team, you're just ignoring the problem.
39:22
Just ask them what are the pain problems. Write them down, discuss them. Some of them are not fixable, some of them may be this is part of your job and you have to learn to do it. And some of them are fixable, easily fixable, some of them require more work.
39:40
But it's kind of the process of thinking about your team and thinking about the well-being of your team and trying to do things to improve the well-being of your team if you have good intentions. And this will yield good results, I think. At least this is how we see things at our company.
40:02
So, thank you. This was it for me. Questions? Time for a few questions. Please use the microphones. I think you have to go to the microphone.
40:23
Sorry, I had to come all the way from the back. Two questions about the rotation of the leader of a team lead position. So, we're wondering if it's like a continuous rotation or just try with full rotation once and then settle on the actual team lead? That's a good question.
40:41
Continuous rotation. Very interesting. Well, the second question is, is the team lead also responsible for like personnel stuff like appraisal, sick leave, all those kinds of stuff or just purely like the technical? So, this depends on your company structure. In our company, the team lead, if you have to take a vacation, you ask your team lead, for example.
41:05
And this is a really good question. We separate the like, can I take a leave and so on from this to the original team lead? The other is leading the day-to-day job. But at some point, I guess we'll just make everything go in this team lead rotation.
41:23
This is a good question. We don't want to kind of overburden right now the rotating team lead with paid sick leaves, vacations and so on. But this is coming. We just have to get there. Yeah. Okay. So, that's good to know. Like in our case, those tools are tightly coupled into one position.
41:44
So, then the rotation will be really hard, especially with like ongoing conflicts or growth patterns for developers, stuff like that. All right. Cool. Interesting. Thank you. My question is along the same line as well. I think it works mostly if all the engineers have the same level of expertise.
42:06
So, how does that work on a team where, for example, I lead a group of nine developers. And so, the developers have different sets of expertise. Some are like seasoned system engineers. Some are like front-end engineers.
42:22
Some are like both. I think that works mostly if in an environment where everybody is a full-stack engineer and everybody thinks they're full-stack engineers these days. But I'm not sure how to... How would I even do that when I am like the leading them and we have like a principal software engineer.
42:45
So, I'm not sure how to do that. Yeah. That's a good observation. We are a team of full-stacks and it's working really well. If you have different expertise, then I guess you have to just see your hierarchy inside the team and figure out how many leaders you have.
43:02
Because you might have leaders on the different teams and the leader that leads all of them. And figure out a rotation that works for you. Just give the people opportunity to be in a leadership position to see what it is. But you have to figure it out. Great. Thank you. Thank you.
43:23
I don't think we have time for more questions, but you can grab... I'll be here. Afterwards. Thank you. Let's give him a big hand.