今日推荐开源项目：《如影随形 SVGImageHover》
今日推荐英文原文：《From the new dev to a code owner》
今日推荐开源项目：《如影随形 SVGImageHover》传送门：GitHub链接
推荐理由：这个项目提供了一个新的灵感思路——在鼠标指向一个链接时，它将会让一张图片跟随鼠标来达到更强大的表达效果。鼠标指向一个链接自然是一个事件，而要用这个事件改变什么则是看各人的思想了，链接、弹出框、亦或是整个页面，在需要创意的时候将已有的事物和可以产生的新事物像这样一一列出也不失为一种用排列组合产生新创意的想法。
今日推荐英文原文：《From the new dev to a code owner》作者：Gabriela Moreira Mafra
原文链接：https://blog.magrathealabs.com/from-the-new-dev-to-a-code-owner-97b84564b63e
推荐理由：如何更好的融入一个新项目团队
From the new dev to a code owner
I believe switching between ongoing projects is a common experience developers have. I had some of them, and my biggest problem with it is the ownership drop. When we are working on the same project for awhile, we know the code, we know the problem, and we are used to make choices involving its priorities. When we are dropped off on a different project, we know nothing. However, if this project is in progress and we have access to the (willing to cooperate) devs that know what we want to know, it’s only a matter of asking the right questions.A new dev is someone who is afraid of touching things and doesn’t feel able to propose changes because, well, “I must be missing something, right? I’ll understand it better and then tell the idea!”. And that makes total sense, since there probably are some unknown factors that will discard the idea. Here are some of my thoughts on how to get to the point where your entries on the project are insightful and aware — which represents, for me, the concept of a code owner.
Communication
So, I want to talk about communication. And I’m sure you have heard a lot about its importance, but I’ll still try to bring some new points here. As I see, the perfect communication is about finding the balance between focus on what matters and not leaving important things unsaid. I’ve recently figured an underrated tool for feedback on this balance: cooperative puzzle games. I’ve played a bunch of those, but only last month had the opportunity to sit back and watch two of my friends play it together.
A puzzle from one player perspective
These games are completely communication based, and while seeing the screens of both players, it’s very easy to tell what one player has to say to the other in order to complete the puzzles. But the games are hard, and there are a lot of points where the puzzle key object is ignored and unimportant things are described with detail. But how is some player supposed to know what to say?
They don’t. Just like the dev working on the ongoing project you just got in doesn’t know what to explain to you first. They understand the project, but they don’t know you, your knowledge or way of thinking. Well, we value so much the feedback cycle in customer communication and deliveries, but we fail to embrace the smallest feedback cycle we have: the dev that is one call/poke away from you.
When I’m talking to a dev, and they start to explain something that is not what I’m looking for, I interrupt them — as nicely as possible. We have the same objectives, so that is the best for both of us. Just like in the game, when the other player starts describing something that clearly doesn’t have anything to do with what I’m seeing. What I try to do is to explain what I’m looking for and don’t let the conversation go out of our control.
Of course, this requires transparency. Cooperative games are much better when played with friends. You have to be able to say what is needed. But this is a very basic communication concept, and a whole other discussion.
Establishment
Landing on a new project, there is a lot of stuff to see. And as much as communication helps getting places, sometimes you have to explore and conquer on your own. You should find your paste and figure out when is time to explore different elements. The aim is to be able to participate in all steps of the development cycle.Focus on what’s newer. Understand the concepts involved in the new demands so you can own new features. If some part of the code base is ready and there are no plans to touch it soon, it’s ok if you don’t get it. After you start to get the minimum comfort required to do some tasks with productivity, is time to understand what everyone else is doing. This is an important thing to know because the project is evolving, and learning what is being changed means learning what the project is.
When I’m confident about something and other dev argues against it, I’m stubborn — I don’t give up on my thought until the reason it is wrong is completely explained and understood by me. Sometimes I think this can be perceived as annoying, but it is really important that I completely understand the reason why I’m wrong or something has to be the way it is. If I let it go, these knowledge holes will only snowball and I’ll whether think “this project should be completely different” or “I don’t know a thing about this project”.
Learning more elements and clearing your doubts, you can aim for harder and harder tasks, which require more and more context. For every task you complete, you own another piece of code. When you try a complex task, you learn a lot about the structure problems and how your ideas may fit. And these great ideas are a sign that you are a code owner.
Owning it
Being a code owner doesn’t mean you are some kind of code boss. It means you are able to collaborate independently to the project — and this comes with responsibilities. If you can develop and deploy a whole new component, you should be regardful to documentation and ready to explain anything other devs may need.So hey, be a good code owner and remember that the relationship between the devs shows up on the code. I wish you can all have a team as lovely and awesome as mine. We join forces to own new projects together, helping each other to communicate with other devs and understand all the new concepts. I hope this little piece of my understanding of what we do can help you love your teams and projects as much as I do.
下载开源日报APP：https://openingsource.org/2579/
加入我们：https://openingsource.org/about/join/
关注我们：https://openingsource.org/about/love/
