今日推薦開源項目：《讀史使人明智 tongjian》
今日推薦英文原文：《How To Stand Out During Your Stand Up》
今日推薦開源項目：《讀史使人明智 tongjian》傳送門：GitHub鏈接
推薦理由：這次要推薦的項目是資治通鑒……當然了，肯定不是全文，而是一位希望能夠快速閱讀的作者製作的精簡版，將全文分割成許多片來一片片閱讀，通過為每一片古文添加註釋等來降低閱讀門檻。通過閱讀可以豐富自身的內涵，不管是科幻小說還是古典文學都在閱讀的範疇之內，資治通鑒當然也在其中。如果你對這長長的古文感興趣的話，也可以為這項目作出一份貢獻。
今日推薦英文原文：《How To Stand Out During Your Stand Up》作者：Michael Henderson
原文鏈接：https://medium.com/@michaelhenderson/how-to-stand-out-during-your-stand-up-33caeb600ee2
推薦理由：如何在會議中讓自己變的更有用
How To Stand Out During Your Stand Up
don』t be like every other pea in the pod
Image Courtesy of Magniscan on Pixabay
For some dev teams, a morning standup is the only time that you get to interact with your team members outside of instant messaging or email. So, it is important to be detailed, engaged, and interested in the goal that your team is trying to achieve. Not only are those qualities part of being a good developer but they can help pull your team across the finish line when they need it most. I am sure you have heard the saying that one bad apple will spoil the whole bunch… well, the opposite is also true. If you are positive, engaged, and interested in what the team is building then that attitude will most likely be reciprocated throughout other team members.
Be Detailed
Other team members must be picking up what you are putting down. For example, if you are going to talk about a bug that you fixed, don』t be one of those devs that say 「yesterday I fixed a bug」. My friend, you are a developer who is most likely making good money, you can do better than that. Here is a good example of the lousy example above:yesterday I worked on bug number 2490 and was able to finish it up before lunch. I ran into some issues but Ashley was able to explain a few things to finish up the task. After that, I moved on to task 5501 which is the label change in the navigation menu. I will be working on that for most of the morning.
See, not only does that sound better but it is informative to the entire team. You never know what problems you solved by being detailed. There have been times in my standups where the bug I was working on naturally solved an issue that another dev was going to begin working on that day.
Code Blockers
Although we hate to admit it, especially if we have wasted a lot of time on trying to fix a particular issue, but blockers are important to bring up to the other team members during the standup. To go ahead and address the wasted time reference, don』t let yourself be stuck on a particular coding problem for more than 30 minutes. Reach out to a team member, send a chat, or shoot a detailed email after you have researched and tried to solve the problem yourself. Anyway, yea, blockers suck.There are two main reason why you should mention your blockers during standup.
- Other team members could have a quick and easy solution to solving the problem that you are stuck on. Better yet, they may have solved the same problem before and can walk you through the process.
- It lets the leads and other developers know where you are in the development process. If you mention a blocker during the morning standup then you and another dev spend half the day trying to fix it, your time is justified and accounted for. If you spend a week trying to get past a blocker and don』t tell anyone until it is too late, then you are seen as underperforming.
「The man who asks a question is a fool for a minute, the man who does not ask is a fool for life.」 — Confucius
Reference Pull Requests and Bug Numbers
Did you leave detailed comments and information on bugs or pull request that would be worth mentioning?Maybe you asked the lead developer during standup to review one of your pull request. If there is another pull request that needs to go in before that one or if there is an issue that needs to be resolved before your pull request is fully finished, then mention it. Give the numbers, send a link after you are done with the standup.
All of this is to make the other team members job easier. After all, we want to work together to make all of our lives easier, productive, and efficient. If that is not the goal then why do we spend time setting up pipelines and implementing CI/CD?
Be Interested
Image Courtesy of kaboompics on Pixabay
Being interested in the project you are working on is one of the motivational factors that will lead you to put effort into your work and doing the best you can. A lot of people are ok with coming to work, not doing much, and getting a paycheck… but what quality of life will that provide you?
Suggest Improvements
Be excited about what your team is building! Are there improvements that you would like to suggest? Maybe certain components are being built that could be built better. Maybe the team members should start linting their code before opening a pull request so the code is more efficient and the build time is quicker. Maybe you should suggest a style guide for building maintainable code… after all, if code is clean, optimized and secure, then the results of the end product will follow. Even if the rest of your team is lazy and disengaged, don』t be afraid to stand out.「Better to embrace the discomfort of being different than the comfort of fitting in.」― Ogwo David Emenike
Team Goals
What goals are most important to your team at the moment? Maybe the lead needs a certain piece of functionality for the web application to be complete for a demo that is going down this Friday.Be sure to understand the goals so that you are making progress and meeting expectations. I have seen it a thousand times where a developer simply just won』t ask because they are afraid it will cause them more work or they will actually have to do something for a change. Don』t be that type of developer, that will get you nowhere in life and your career.
Lend a Helping Hand
If another dev on the team mentions that they are working on a certain bug and you have some experience in that area of the application, then speak up! Let them know to ping you in Slack or send you an email if they have any questions. This is especially important if it is a new dev. You want them to know that every person on the team is not in it for themselves. You are a team so you work together to pull everyone across the finish line.Be Engaged
Image Courtesy of FreePhotos on Pixabay
Honestly, being engaged is one of the traits that a lot of successful developers have. A developer can be faced with a problem and no matter how big, they will engage with the problem, ask themselves questions, and ultimately come to a solution. Then, when coming to a solution they engage in the solution to make it better, faster, and stronger. I am not asking you to build a solution or solve a problem right now, I am simply asking you to be more engaged during your stand up.
Set the Tone
This can be hard if your team has standups early in the morning. Don』t let it sound like you lost your best friend and then the coffee you drank induced explosive diarrhea. During standups, set an uplifting, and ambitions vibe when engaging in the conversation at hand. Even if there is a problem or you ran into a blocker, sound optimistic about it. If you are setting a bad tone during a standup, especially a morning standup, then the day is most likely going to be bad.Speak Up
If you do your standup through voice communication and not physically in a meeting room, then make yourself announced when you join the call. For example, when I call into the standups for my team, I say 「Good morning, Michael is here」. It sounds weird but it lets others on the call that may have joined earlier know that it is me on the call and not a ghost.If you notice that someone new is on the call, maybe they just joined the team, then introduce yourself. Let them know what you do on the team and let them know that if they have any questions then they can feel free to reach out to you.
I have personally made it a goal of mine to be more engaged this year and it has changed the way I perform when slinging code, receiving constructive criticism and having a conversation with a teammate. You see, being engaged is about listening, understanding, and helping others. A quick note about helping others… don』t do it during the standup.
A lot of times developers have questions during standups or have a blocker that they are dealing with and need your help. Instead of solving the issue during the standup while other people are waiting, ask them to shoot you a message. This makes sense because standups are not the place to solve issues and problems that have occurred nor is it a place to waste other peoples time. The same goes if you are needing help from another dev. Don』t expect someone to help you during standup, if another dev is willing to help you and wants you to contact them after, be sure to follow up.
Conclusion
If you do what was mentioned in the other parts of this writing then standing out will come naturally to you. If a company sees that you are not interested and are not fired up about what your team is building then that mood and thought process will eventually show in the finished product.Be the best you can be and don』t be afraid to stand out. People that standout work for some of the best companies. The only reason those companies are the best is because the people that work for them want to stand out, they want their team to stand out, and they want the company they work for to stand out.
How can I be more engaged, interested, and detailed with my work? I ask myself that question at least once a week. It is good practice because it has helped me stand out, not only during standups but with any type of product that my hands touch.
下載開源日報APP：https://openingsource.org/2579/
加入我們：https://openingsource.org/about/join/
關注我們：https://openingsource.org/about/love/
