hi everyone I'm Daniel Roy Scara software engineer here at hiem Technologies and with me is my colleague Sarah hi um yeah I'm Sarah also at hiem Technologies for the last couple of years as a scholar engineer um yeah hi and we're going to be discussing uh pair programming here at high of Mind Technologies we uh we practice extreme programming methodology in our development teams and core component of that is pair programming so to quickly go over what is pair programming to quote Kent Beck's book um which I've got right here extreme programming explained it's uh where two programmers write all production programs together sitting at one machine uh now that's quite a rigorous definition right there uh but he does go on to elaborate later he says you don't have to be permanently sitting next to each other all the time eight hours a day at the office say said people need both companionship and privacy he goes on to say and if you need to work on an idea alone go and do it then come back and check with your team but the key tenant the key thing to remember there is that code is written together as part of a team maybe not even just a pair but with multiple people so that you're checking with each other constantly and uh and yeah so you're not just an isolated uh worker writing all the production code that's going to run uh on your production cluster later it gets reviewed not just again at PR time isn't that right Sarah when you've already written pages and pages of business logic and architecture logic um it gets written gets reviewed more directly as it's being written uh so yeah would you agree with that Sarah yeah that's a really good point actually I haven't thought of because I think it's really important in a team that you have that um sort of Team ownership of code where you typically with the poll requests so you've have obviously you have G blame feature in your IDE but that's just the person who committed it's there there would be like a teen ownership and possibility um that's the key word right there team it's not individual developers working on tasks it's teams working on tasks which is why at hive mind uh although we do use jir with some customers and we do end up having to assign one developer to the ticket as jira says we work in work streams which are small groups of developers so you and I previously worked in a it was a work stream of largely just us two and occasionally a third person but uh still that meant a tasks was assigned to the work stream and we worked on it together and if not 100% of the time but when crucially figuring things out we would go through it together yeah I think even on a smaller project um you should never be by yourself as a developer because you've always got that kind of opportunity then to yeah share the code and we did this someone literally an individual has to commit that code or yeah it's actually kind of why I don't like the name of that thing in GitHub the git blame feature because I I know it was just a cheeky word perhaps by Linus tals because he likes a cheeky joke but uh it is quite an aggressive uh word to use so yeah we certainly wouldn't blame no person I me those processes it is the classic case when you're looking into a bug and it's like who committed this garbage code and it's like who do I blame for this and then oh me that was me quite six months ago me or something that is my fault what was I thinking yeah so yeah that's the kind of idea of pair programming and then typically K Beck suggests no more than four to 5 hours in a day uh although thing you noted that's perhaps even a bit too much for you and I think myself the same perhaps 3ish hours is enough for me because uh it can be quite an intense process because I like to think of it as both of you being your most productive selves together like uh you kind of positively feed each other and you can't really yeah you can't sorry to interrupt switch off um it's very it is intense um so I would say yeah my limit probably a bit less than that yeah so maybe three hours in a day or maybe 15 hours in a typical 38 hour work week uh or however much you're comfortable with some people you might be able to do more and again it might be who you're pairing with as well maybe with someone else you can pair longest others people I I'm thinking as well perhaps especially the bigger the Divide like a junior developer with a principal engineer the junior developer might get tired out a bit quicker because they're the principal engineer might be bringing newer ideas to them and more uh know rigorous programming techniques or something that the junior will have to go away and revise yeah it could well be more tiring I'd like to suggest though that everyone brings something it's not um even a junior yeah to pair programming it is definitely a two-way exactly it's always about different ways of thinking about an idea and you know even Juniors can have fresh perspectives which can benefit principal Engineers a lot and uh and yeah that's another crucial thing with pair programming is it doesn't matter who's pairing with who like there might be a senior or principal engineer need someone to pair with and they might call a junior to come get their perspective and just in that kind of discuss of the problem maybe they come up with a solution themselves but it's still that's kind of the power of pair programming right there yeah and yeah so we already talked on some of the benefits as well so you get the various perspectives um you know from seasoned hands or from fresh young faces fresh young graduates you still get various perspectives and different ways to think of an idea to look at a problem and through that you might find better Solutions quite often I found that a quite often talking with you when we PA on things that I might look at one thing and could only see a single solution and then you would come in and just immediately spot a different way of doing it just because you've got a different perspective yeah and exactly um yeah I think um when I was thinking about it some of the stuff is more abstract as well um there's the particular problem that you're working on um but then there's the morale so you get it might feel weird when you're first in a new team with someone and you've never worked with them before but I think that gets easier and you you're kind of team building um doing it um yeah definitely morale plays a big part especially in our line of work as well because um if you can if you feel unmotivated by not you know getting stuck on a problem then you won't be thinking your best you'll be kind of stuck in a little tunnel and not able to see things so you're just getting the chance to chat with a friendly face and uh you know go through these issues these technical issues you know none of us are experts we're all figuring things out and learning especially new technologies all the time because always a new library or a new technique to learn yeah that's quite good actually when I first um I mean when I was very very inexperienced programmer and started to pair program with someone very experienced um I did feel totally out of my depth and like and it was too intense and too much um but other than that very first few weeks or whatever um I think um I think you do one of the things even if you're more exper you're less experienced than the person you're pairing with it's quite sort of refreshing to see they don't know everything as well they're all kind of like figuring things out I'll just look at the Docks or I'll just you know no one that I know it's just sitting there um coding without any kind of thinking or assistance or that kind of thing so we Lear exactly yeah and we're all learning so they call it knowledge transfer so you avoid the dreaded knowledge silos in your company as well and uh and actually I even have a specific example of this knowledge transfer I had uh uh when we had a a colleague come in just to help us in our project a little bit and uh I was struggling with an issue and uh I asked if uh he could pair with me just so I could talk through the issue I knew he actually didn't know the library that well but I thought if I just talk it through with him then maybe I'll come up with a solution and uh eventually yeah it did it was a very useful like about a 1 hour call going through the code together explaining the problem and everything and eventually came up with the solution and yeah he didn't know that Library well or even the concept that this Library uh it zo layers so he didn't really know zo much at all and he knew even less about layers yeah but he learned a lot from that transferred the knowledge and then after that he went away and studied a bit more and he wrote us an article on Zool layers it's up on our website and it's very extensive and uh very informative so that was a clear benefit that we at hive mind that we gained from just a short pair programming session um I guess knowledge transfer actually I was also thinking of like domain knowledge on the project so um rather than a single developer knowing about this particular aspect of the service or project um that would then be shared so you've got that kind of resilience when someone's away or yeah exactly the domain knowledge is typically much harder to understand especially as we might not have access to a domain expert with a client or something but it's if that knowledge gets into the team and we could spread it out it benefits everyone so if it's you know some Financial kind of domain knowledge or previously other jobs worked in telecoms and Telecom stuff can get very complicated very quickly and yeah it helps helps to really understand even just the task like a new feature understand it better if you understand the domain side of it and what's driving it uh definitely and yeah actually like to talk Talking of previous jobs uh how it compare compares to like a standard uh developer reviewer setup that's kind of more typical in kind of classical programming industry so uh I'm I'm sure you've had it before you come in to work preo times you come to your desk at the office and uh maybe you've got a stand up in the morning and the team lead says right Daniel you've got this J ticket you know you've got two days to do it off you go maybe you know you sit down your desk maybe that task has been refined by the team lead and a domain expert and maybe you know decent description or something maybe some test data I don't know and it just says you know go make it and uh maybe you just end up you write all the code maybe it goes quite well you write all the code and two days later boom you've got a PR up on bit bucket problem is then you've written don't know 200 lines of code and weird logic that you've had to figure out yourself and then your colleague comes to review it and they're like they have no idea what you've written like you know it's not a case of just read the code you understand it is like there's domain logic in there there's business logic that you need to understand and this colleague maybe doesn't get it you know yeah when those poor requests get far too big you just typically get a looks good to me as far as I know approval rather than any real feedback exactly yes so they they haven't been included in the development process maybe at all maybe you could have asked them for help during the time but maybe not there's if there's it's not your company policy they've probably got their own work going on then uh quite often you just fall into this trap where you just even a small feature can balloon out in size quite quickly and and yeah they're just staring at a wall of code that uh they don't understand and they'll just give you the green tick and you merge away and then two weeks later the bug tickets come in and like oh no didn't see that issue and so on uh I mean maybe you'd say oh just write more test cases but again even just thinking out the test cases um can be hard on your own I mean that's what we did before we had a big feature we to come in and we sat down and we wrote out all the test cases first and uh then I went away and wrote the code and at Point writing the code was trivial yeah because we had the test cases and then I came back to add a feature or fix a bug or something and it was simple with that test setup it was a delight exactly that that's again why a hi mind we practice test driven development I feel like it goes hand inand with pair programming because then you can just use the pair programming just to write the test suite and that could be all that's needed really and you cover all the functionalities all the happy paths error cases just for the test cases and then at the end when you want to prove it works just read the test cases make sure it's all there um yeah and actually going back to the old classic way you can if you don't have a policy of pair programming sharing knowledge and empowering each other it can be quite daunting especially if you're a junior developer asking a senior developer for help yeah unless you've got that set up as a sort of default way of working it yeah can very much feel like that exactly similar reasons pair programming can be quite scary and daunting at first so when you very first if you've worked somewhere which is more like how you've just described um and then you come to work at hi mind or somewhere else and um pair program is kind of the norm it can be quite um because you have to sort of um you know it's honest this is what I am this is what I can do this is can be quite sort of um uh quite off-putting quite daunting yeah quite daunting I'd say to start with especially as well personally at previous jobs particularly during your probation period you've just been hired maybe the salary that you feel like you don't deserve and you know you're sitting there trying to prove that you were a good hire to prove that you're going to pass probation and everything like that yeah and then it's like ah if I just ask I can't go and ask my colleague even if they might be your dedicated I don't know your buddy or whatever they might have that kind of system you still feel like but he might think I'm an idiot if I ask him about already and then inferiority complex exactly like I'm doing a even I even had a previous job I was still you know more senior at that point I was already had like six seven years um industry experience but my previous job was the first time I had to work more seriously with cats effect and had one time I had a I I was stuck on something you know something very cats Affy I had an F of a t of a thing in a jig and I needed a t of an F of a thingy and it's like I I I was completely washed I had no idea why the compiler wasn't resolving to the type I wanted so but at this point I was like I just ask for help I I don't feel ashamed about asking for help you know expressing that I don't know a thing I called up uh a senior developer in the team and it was a pretty horrible experience honestly he did not kind of feel like helping me he felt like I should have known this and well he said that explicitly several times he's like oh come on this is simple you should know this and I was like yeah maybe I do but I can't find it right now so can you just poke me into the right direction and after like 20 minutes he said I'll just forget about it just push what you've got and I'll fix it and I think I ended up writing my resignation later letter the same later the same day so that was a classic example of how not to do pair programming he made me he belittled me and made me feel bad oh by the way afterwards I went for a cup of tea back and figured out so so it's like yeah I had the knowledge I just needed a bit of assistance from a a colleague a friendly colleague just to kind of you know help me get down the road or maybe some honesty if he actually didn't if he couldn't help you maybe that too cup of coffee or something could have been that's what that example makes me of could have been you definitely need to have that environment where everyone feels safe to exactly that's very important here it's high of mind that uh it's a safe environment there's no stupid questions sometimes you might have a stupid question and you know the gooey pink thing in behind your eyes just can't find the answer right now that's fine sometimes you just need a bit of a push um even our principal Engineers here sometimes fall into traps and uh you know can't find obvious answers it happens we we can't expect us all to perform perfectly all the time and just having a bit of support from a friendly colleague goes a long way yeah and you end up producing much better code for your for your customers than you and and yeah so another thing to point out at the beginning we said pair programming is about working at one machine but counterintuitively hive mind is a remote first company uh remote first even before the pandemic so since we were founded in 2014 um so we're very very used to working remotely now through zoom and uh often times it pairing just means doing this just doing a zoom call and maybe sharing your screen of your IDE and talking through the code as you go but we've also made use of some plugins so intell j's got the code with me functionality so the other person signs in and it allows them have like a live editor on their intell J so you're looking at the same thing and then you've used a live share Cod Times yeah and um that's a similar kind of plugin that you um copy a link and you can share um share with your colleague um as same as you I'm more I'm more familiar with working with intellig but um yeah assuming both work on the same IDE which is normally pretty um interchangeable that can be good as well but yeah we do tend to share a screen more often than not don't we yeah it's a much more simpler way to do it quite often you're talking through the code anyway so you might not have to write that much or just talking through the tricky Parts quite often yeah we talk more of an higher level abstract level of way of doing things not explicitly like here's the line of code to write here that's yeah most developers can do that on their own if needed it's that high level ideas that need to be worked out first sometimes you need your own space for that anyway as you said like yeah sometimes yeah writing the code can be the easiest but perhaps also the most boring part of it so yeah and you know free up I mean in back in our team like maybe you helped me with something and then once we'd figured out the high level stuff written test cases I would go away write the code the implementation code myself and that free you up to go maybe help someone else out help out another colleague yeah whil both have visibility on that same thing you know it's just um helps um both parties and the team and the project um immensely yeah exactly yeah and it allows us to produce our best work and much faster as well because you know one hour of productive work is worth a lot more than perhaps a whole day of unproductive work of unmotivated work for sure okay right I think that's everything we wanted to discuss today so uh thank you very much for joining me Sarah on this discussion of pair programming thank you enjoyed it excellent and uh yeah to everyone at home we hope you uh interested in hearing more about uh how hive mind technology works so please check out our YouTube channel and our website and uh please feel free to get in touch with us we offer workshops on the fast delivery methodologies as well as other Technologies as kubernetes Flink and large language models so yeah please get in touch if you're interested uh that's all from us for today so thank you and bye-bye thanks hi
2024-02-04