Over the past two years I've been learning and writing about .NET Core, which has lead to me starting a podcast all about it. But all of that learning has been in my own time. I'm incredibly lucky where I work, in that management have allowed me the time (during my day-to-day work time) to learn how to use things like docker, Azure, and other tools.
But I'm left wondering "how can I make sure that the knowledge and experience that I've collected can be spread amongst my work peers?" We already have a culture of lightning talks (which are informal, not-compulsory, and mostly "here is a thing that I have done/used"), pair programming, and wiki entries
So my question to you all is how would you want knowledge from a colleague to be shared with you? Brown-bag lunches? Lightning talks? Wiki entries?
Top comments (13)
I recently started at new employer and have been the beneficiary of co-workers who are more than willing to go above and beyond, to sit with me and answer question about what I'm trying to figure out as well as showing me tips and giving suggestions.
A big part of it is their positive attitude. I'm never left feeling inferior for having asked a question.
So I have committed myself to doing the same.
Happily helping anyone and encouraging them to ask me more.
Just my thoughts, might work for you.
This is absolutely amazing, and I'm really glad that you have such fantastic colleagues.
I know that, early in my career, I found that colleagues who weren't willing to share tended to foster an environment of elitism and it really fuelled my impostor syndrome. "Clearly they'd be willing to help me out, if I was meant to be here!" and similar thoughts would repeat on a daily basis.
But it sounds like the culture surrounding your colleagues wouldn't allow for that to happen.
I think it is important to understand that not everyone is interested in active continual learning. They might change strategies or learn something new if there is a demonstrated benefit, or in response to problems that arise. But in general, they are happier to keep the status quo. There's nothing intrinsically wrong with that, especially if their role fits these traits.
So my advice is to learn to recognize this distinction to save yourself some disappointment. For people who are continual learners, the format probably won't matter as much... they will be interested anyway! Personally, I am more inclined toward content (of any kind) that I can consume on my own time (docs, podcasts, videos) rather than scheduled events (lunches, demo meetings). But other people will have different prefs.
This is the most important part, I think. And one which I hadn't even considered. II'll have to go back to the drawing board and re-think what I'd actually like to achieve, and how I could approach it with the thought that "not everyone will want to be involved," in mind.
Everything that is persistent (recorded talks, articles/wikis). Some of the peers may be missing or not even hired.
Post mortems and incident reports I heard are awesome, but takes time to fill them, so the management has to agree on them.
Also if you are an early adopter you have to take into account the time to help others that will try to adopt them, and ran into troubles.
I really like the points that you raise, and they've made me stop to think about how different developers could implement them.
We don't tend to record any internal talks that are given, but we do share slide decks and resources discussed.
I've only done post mortems in the form of personal blog posts for open source applications. But I like this idea, perhaps they could be included in sprint burndowns/retrospectives, as most of the issues that one solves can easily present for other teams.
My team does a weekly "tech meeting" and we're supposed to use that time (alternating people each week) to bring an issue to debug, a problem to bounce off multiple brains, or something cool we learned recently. Lately we haven't been having the meeting as there hasn't been much productive to share from any of us. I should start thinking about how I can use my week to practice lightning talks on something awesome I learned.
This sounds amazing. You should totally see whether you can use the time to do something like a lightning talk. Even if the thing you talk about isn't necessarily related to the work you're doing, simply exposing yourself to it helps you to grow as a developer/engineer. At least, in my opinion.
I think you're right, especially since public speaking is one of those things I forced myself to be better at by simply "faking it" and putting myself in situations where I had to do it. I need to keep practicing to keep leveling up!
I joined a team 10 months ago with a hope of learning a lot from the other devs who've been doing this a lot longer. But the work all happens in a very silo-ed manner, so the only team I get to see any output from anyone else in the team is during peer review, which usually needs to be done in a timeframe that doesn't facilitate learning.
In order to try and get at the knowledge in the other developers heads I've been trying to organize monthly lunches (sponsored by the boss) to discuss topics much like in your lightning talks. We're up to number 6 now and so far I've presented 4.5 of them, but at least people are still showing up!
This is fantastic! And it can be a great way of spreading experience of knowledge of a very specific thing.
I ran a lightning talk on the three major .NET IDEs recently (VS, VS Code and Rider), and I feel like it went down pretty well.
Grant Maki tells a story of how you can incrementally start trying something new with your team and that builds the culture of trying something new. It's okay to start learning something and throw it out quickly if it didn't work as well as it could for your projects.
I'm watching this talk and having a good laugh.