On today’s show we will be talking about knowledge sharing. As developers, we gain knowledge and we try to disperse that knowledge to other people on our teams. Our main concern is that we as developers just want to make sure that we can capture the many different ways that knowledge can be dispersed. As consultants, we find ourselves bouncing from client to client and the first thing that we need to obtain in knowledge sharing is the domain knowledge itself. This includes industry specific buzz words or even vocabulary that is specific to the company. In this episode we dive into the different methods for gathering knowledge, strategies for knowledge sharing, as well as the differences between in-person and remote learning.
Key Points From This Episode:
Transcript for Episode 25. Knowledge Sharing
[0:00:01.9] MN: Hello and welcome to The Rabbit Hole, the definitive developer’s podcast in blustering and raining downtown Manhattan. I’m your host, Michael Nunez. Our panelists today are:
[0:00:09.8] DA: Dave Anderson.
[0:00:10.8] CQ: Charles Quirin.
[0:00:13.7] EG: Emanuel Genard.
[0:00:15.6] MN: And today we’ll be talking about knowledge sharing. As developers, we gain knowledge and we try to disperse said knowledge to other people on the team and we just want to make sure that we can capture the many different ways that us as developers and developers out there can share said knowledge.
As consultants, we find ourselves bouncing from client to client and I imagine the first thing that we need to obtain in knowledge sharing is the domain knowledge itself, you could come from finance and pick up buzz words from finance and then go to the music industry which has completely different vocabulary. Could you elaborate on some of the ways you find yourself picking up domain knowledge?
[0:00:58.4] EG: Yeah, recently, I’ve had experience at a client where I came in with no domain knowledge at all of what the project was about. I found myself being able to sort of read the code and to understand that this method called that method and this class, you know, that this or maybe this class needed these arguments to work but what it meant and why it might need it was really foggy to me. I mean, I couldn’t really understand the why behind everything.
One of the things I really had to do was ask a lot of questions about, you know, what this code does, why this class name is one thing versus something else. Also, frankly, do a lot of reading because it was something that one is actually pretty important in our field which is you know, dev ops stuff.
[0:01:55.0] MN: Okay.
[0:01:55.7] EG: It’s not something I’ve had any practice in at all. I’ve never really had to do it. I’ve used Heroku all the time and so now, you have to actually do what Heroku is doing.
[0:02:08.4] MN: Yeah.
[0:02:09.4] EG: Four years, by yourself.
[0:02:11.5] DA: Emmanuel is Heroku.
[0:02:13.3] EG: Yes.
[0:02:13.5] DA: You are Heroku now.
[0:02:16.6] EG: These are two couple of specific things that I did. I kind of decided that I was going to kind of pursue, I was going to get an AWS certification, I would then understand a lot of the words that the clients were using and the reasons we’re using them. Also, learn a lot by just pairing with people who did have this experience. Client devs and a more senior dev from Stride and I would just, especially the one from Strider.
The Strider, I asked that dev tons of questions and sometimes I would just – I was really lucky because he was willing to just sit and explain something to me like in the middle of working on a story for like 20 minutes which was really helpful. Also, frankly, just working on it almost every day, every week day for almost six months now.
[0:03:10.6] CQ: Okay.
[0:03:12.0] EG: You know, the client understood that I didn’t have any experience in this and they were really accommodating. I had time to learn it. To sum up really, I would say that the pairing and taking the time to study about the domain and also the third approach which is being around people who work in the domain and it’s hard to really be specific about how that helped but listening to the words every day.
Listening to the conversations they were having, they were very obscure when I first started but now, they’re less obscured. Once in a while, they’re still very obscured. But they are much less obscured than they were when I first began.
This communication that happens between people and their team is really something that we at Stride really value and try to work towards but also, I think any team needs to do so that everyone can understand what we’re all doing here you know? Why we’re all doing it too.
[0:04:12.4] DA: So, for this particular domain, I guess the law of the language that you’re trying to figure out was around like servers and networking and that kind of thing? Yeah.
[0:04:23.9] EG: Servers, networking, there is a lot of vocabulary really and each of the cloud providers have their own vocabulary for sometimes the same thing, sometimes different things.
[0:04:35.3] MN: Right.
[0:04:36.3] DA: I guess learning the vocabulary for Heroku even like, you know what Heroku calls it and underneath all of that, underneath all this hierarchies of different layers. It’s really this one thing. If you had like a room filled with computers with wires connecting all of them, then you know exactly what to call it. Could be right there.
[0:04:59.9] EG: It’s really, yeah, that’s a really good way of describing it. It’s sort of like going into, you know what? At the client Iman, they still have server rooms, right? It will be like going to the server room with all the racks of computers and the wires and the wires upon wires and the blinking lights.
[0:05:22.3] DA: Right.
[0:05:22.9] MN: I have a question, how would you feel that experience would be if you were working at the client remotely? Like, not being able to, you know, be in the same room with overhearing the conversation and stuff like that. Do you think that it’s more difficult for a remote individual versus someone who is actually there?
[0:05:39.1] EG: That would be very difficult. I’ve done some remote pair programming and it was always about something very specific in where we both knew what we were doing. If I really didn’t understand what I was doing, I couldn’t… I would have to constantly maybe Slack a message to the client dev to ask him, “What does this mean,” instead of maybe just kind of popping my head over and saying, “Hey, what is this thing right here? Oh okay, thanks.”
If I can have lunch with the client dev and if maybe while working, let’s say, I don’t know, I couldn’t pair remotely and I had to - I’m stuck on something. I’ve noticed that a lot of things that – enough things I should say, enough things I get stuck on while programming are sometimes very silly, simple things that I just for some reason don’t understand.
It’s not a matter of a problem to figure out or some piece of logic to understand. It’s really just like, “Hey, when you’re using this language, you just have to do this instead of that.”
[0:06:39.5] MN: I see.
[0:06:40.3] DA: Right, because they have already made that mistake and they think their heads and they’ve kind of leveled up already.
[0:06:46.7] EG: Yeah, that’s really, you know, if you’re trying to connect the AWS, you have to just include this to it or else they won’t work.
[0:06:53.6] MN: Right, interesting. I think just like the fact that you're there in the same room as a lot of the client devs would allow you to pickup things a lot more quickly then, and it gives you an advantage than doing things remotely and then having to Slack someone. Because I mean, it’s very powerful that you can walk over to someone’s desk and say, “Hey, you got a second? I have this question” and then like, immediate response whether, “Hey, give me one second, I’m in the middle of something” or “I’ll be right with you kind of thing.”
[0:07:24.0] EG: Yeah.
[0:07:25.0] DA: Yeah, I was thinking about this too and I guess like, in terms of domain knowledge, there’s kind of like different kinds of domains like you might have a physical domain where you actually have servers or what have you, but then there’s also like often like process domain where things may be intangible and you may not be able to directly understand it without someone who is like been through it like past clients that I’ve worked at are pretty heavy in like regulation and you know….
They have a layer of like physical product but then there’s also like the government regulation and the rules that they’re following and the different steps that you follow for each of those things. You know, having ubiquitous language and the code helps because then you can look at the method and be like, okay, well, this is called a shipment and you know, it corresponds to these different rules.
This is like a deliver notice or what have you. You know, often that’s not enough and you do need to be there and ask a lot of questions.
[0:08:28.6] MN: Cool. Charles, you had mentioned a different way of knowledge sharing, do you like to chime in on that for a bit?
[0:08:35.7] CQ: I was at a client where they were – if you’re a fan of form of like up from documentation, they called Tech Design and the point of these tech designs was before you were about to take on like a piece of work, kind of sharing within the engineering organization, what you were doing, why you were doing it, in this particular case, we were working a lot with micro services, what end points were involved, what the paths for everything was going to be.
And also, what data stores you have to touch and I found that process, it was really good at kind of getting input from people that were interested but at the same time, that was supposed to be a livable piece of documentation and frequently, those tech designs became outdated by the time whatever was implemented, was intended to be implemented was actually implemented.
The other thing that I noticed was sometimes, developers became extremely focused on this tech design that they would rely upon it as a single source of truth when reality was telling them something else.
Interesting. I did learn a valuable lesson in actually discovering actual truths and I also pat the rights of several of these tech designs myself and I found that when I was writing tech designs, the thing that helped me the most was actually breaking down like approximate stories of what I was going to work on or tickets on things I’m going to work on.
Kind of communicating that as supposed to a very – like some kind of generic process because eventually it would become tickets and stories anyway.
[0:10:32.5] MN: Right. Do you find that those documentation tech designs you called them?
[0:10:36.4] CQ: Yeah, that’s what they were called then.
[0:10:38.8] MN: Do you find them getting outdated very quickly and how does that get managed?
[0:10:42.9] CQ: I think it kind of was like reliant on the team that actually wrote them and some people were really good at keeping them up to date and some people were not so good. I think that if you came across one that was inaccurate, you try to update it but ultimately, there were a couple of other different things that we could rely upon, they had really good tests, for example. Extremely good functional tests and there were a number of people at the organization who were maybe a little bit more specialized in different areas or different domains. There was always someone you can kind of talk to which is also a weakness but it’s also, it’s a strength.
[0:11:22.1] EG: How is that a weakness?
[0:11:23.8] CQ: Well, if the person’s out on paternity leave.
[0:11:26.3] EG: Okay.
[0:11:28.1] MN: That’s the buzz factor.
[0:11:29.5] CQ: Islands of knowledge. Yeah, exactly. You could end up having some islands of knowledge and so, this particular client, they were moving away from an old monolith where there was some testing but not great testing in certain areas and that’s where the islands of knowledge kind of came into play.
[0:11:48.3] DA: So would you guys use any form of automatically generated documentation alongside this or was that kind of the only means that they were using to document.
[0:12:03.5] CQ: Well we did do in line documentation for files and function or method declaration.
[0:12:09.9] DA: Using Sphinx or some document generation.
[0:12:13.7] CQ: Yeah, there were several different – we were using Python, Java Script and PHP. So there’s, depending on the language what I prefer to do is make pretty descriptive tests and so I try to let the test be the documentation and I think most of the teams were really good about doing that because we already had great test coverage. So that was very helpful for me but because there was this micro service architecture, you’re also reliant upon, you were still reliant upon these tech designs that tell you which micro service has to communicate with what other micro service and what table in the data store that several of these micro service maybe sharing, actually is being accessed. So that was the difficult –
[0:13:01.0] DA: It could be a downstream impact.
[0:13:02.4] MN: Yeah, so that was the difficult thing to communicate like you couldn't do that in line with your code. You couldn't really have your tests be your guide. You would have to have maybe the functional tests a little bit but you’d have to have some knowledge of what was going on there.
[0:13:18.5] DA: Yeah, I personally really love it when there’s just a great read me that greets you when you open up a GitRepo. When I can just do a Git Clone and then follow two or three simple instructions to build a task, to deploy it, I am so overjoyed.
[0:13:37.3] CQ: I find that sometimes I am the person who writes the read me or keeps it up to date. So if I started a client frequently, the first couple of days or so you are setting up your environment, you are getting to know people, maybe you are working on a story or two with somebody else but I find that most of the time, it’s like, “Huh no one has set up the environment a little while. Look at these read me steps in the center of the room”.
So I think it’s important to know as a developer if you do have that read me and it does become out of date like just help everyone out.
[0:14:09.9] DA: Yeah, that’s part of leaving it better than you found it. That is an easy win, I’ve done that quite a bit myself where you get everything set up, it works great and then you try and test it and it’s just doesn’t work for whatever reason and it’s like, “Oh there’s this one gotcha that of course you needed to do that, why wouldn’t you know that?” You know everyone has been here for three years or four years knows perfectly well I need to do that.
[0:14:37.3] MN: Yeah, I usually find myself if I was given a Repo to clone and there was documentation, I would definitely look into that if I was unable to speak to anyone. It would either be the documentation and then just try to read the specs and the test to see what I can find out of this code base. If there is any domain knowledge in the test, that’s a start or in the unit test or in the functional test and integration test.
I find myself trying to get knowledge that way but definitely between the documentation that Charles brought up and just being in with other developers and pairing that the men who brought up. Those are top ways to ramp up on a client and on a code base that will definitely help out developers out there who is just starting on this brand new project that they’re on.
[0:15:34.1] CQ: Or even just sharing the knowledge for new people right? Sooner or later hiring is going to happen, the new person comes in and you want to make sure the process is easier for the next person.
[0:15:44.5] DA: Yeah, I definitely love finding system diagrams like showing how all the different data stores and applications are interacting but there’s definitely a light level of extraction that is good to have because if you have too much information then it’s a complete overload and you can’t get anything out of it like I have seen this one diagram that had literally every single server and every single data exchange for a very complicated company of systems.
And that is pretty much impossible to get anything out of except for maybe the guy who created it but if you have the right level of extraction then it’s pretty great to really quickly understand, “Okay well this piece is over here and this piece is over there”.
[0:16:33.4] EG: Yeah.
[0:16:33.9] CQ: I would assume that making some kind of boundaries about specific domains within those pieces of documentation would be helpful as well like rather than having this giant overview, this giant system kind of pulling out into different layers.
[0:16:53.3] DA: Right, these are tightly coupled. So we’ll zoom in and look at this.
[0:16:58.2] MN: Cool, I’m glad everyone was able to share their knowledge and knowledge sharing. I think that in the different avenues that we found, developers out there can leave it better than the way that they saw it before in sharing knowledge and being more efficient in the workplace. Do we have any teach and learns we like to talk about?
[0:17:17.2] EG: Sure, so I have been re-reading or maybe reading the whole way through for the first time.
[0:17:24.6] CQ: Again for the first time.
[0:17:25.8] EG: Again for the first time. Sandi Metz’s book, Practical Object-Oriented Design in Ruby and I ran into these last chapter six and seven which talks about inheritance and sharing behavior through modules and she basically explained that inheritance and including a module is basically a form of automatic message delegation where you know this instance doesn’t have this message but it just goes up or it just finds somewhere in its hierarchy.
They are the class hierarchy or it’s some interesting module or in a Ruby through method missing to find what if this object can respond to this message right? But one of the really interesting things that she mentioned there is using the template method pattern. I probably think it’s interesting because I had a chance to use it at work because I had this huge case statement inside of an abstract class that was checking essentially what the subclasses were but it wasn’t directly checking in but the end point in being that like what are these subclasses.
If you are this subclass do this stuff, if you are this other subclass do this stuff and it’s really a simple thing to do where the abstract super class just implemented why it was coming to all of them and then it merged or it called a class that was only implemented in the subclasses and so then the subclass, all they have to do was implement that method that was specific to them. So let’s say you are taking an order for something and the order class has maybe a price and where it’s going.
And maybe the order for books has a special kind of shipping thing, the order for clothes has a different kind of shipping thing. So in the abstract class you will just do the thing that is common for all of them and then you will write up a method that the super class just takes in at the end of the order and the subclasses implement that method and to make it viable as a template pattern what you have to do is in the superclass., you have to implement that method as well even if it’s empty.
What she suggests doing is putting a raised not implemented error so that if it is not implemented it raises an error saying, “Hey this needs to be in a subclass” because really, only the subclasses ever get created.
[0:19:58.6] MN: Oh okay.
[0:19:59.7] EG: But that, the abstract class is just something that collects stuff that’s coming from all of them.
[0:20:05.0] DA: Yeah, I’ve been using tasty pile up more with Python and it uses that a lot as well. So I was doing my TDD to make a new rest resource and I just kept on bumping into not implemented. I’m like, “Oh yeah, I need to inform that” let me do that.
[0:20:25.8] MN: Cool, I have taught someone something today which was really interesting. In the midst of speaking with someone who is starting up in programming, one of the failures that they’ve mentioned was Git Push Force and I am sure everyone in this room and developers out there may have push force over someone to work.
[0:20:47.9] EG: I have never done that.
[0:20:50.1] MN: Hey, I mean come on.
[0:20:51.2] EG: I would never.
[0:20:52.1] MN: I had mentioned to this person that she look into a force with lease and what Git Push Force with Lease does is it pretty much checks with origin to ensure that there were no changes before you Git Push Force. So if the event that we have a developer, I, Michael was working with let’s say Bobby for example, Bobby has some changes and pushes up and I make a rebase from the developed branch and then decide to push my changes up.
If I Git Push Force it totally erases Bobby’s work and it could have been hours of work and now Bobby hates me and we don’t want that. So if you Git Push Force with Lease, it will at least check to see that everything is okay that there were no changes done by another I believe, commit hash, to check and ensure whether it’s safe to make the changes that had happened between where you were and what the origin head is.
So I definitely would suggest people checking out Git Push Force with Lease and not use Force because then it just erase people’s work that they’ve been working with. I like to thank all the panelist today, thank you guys for coming out. I like to thank all of the developers as well. This is The Rabbit Hole, we’ll see you next time.
Links and Resources:
