The truth is that big part of those roadblocks can be tackled with a single line of code. Yes, you can work on low hanging fruits and have a lot of fun!<\/p>\n
Which technical impediments can you work on?<\/h2>\n
Recently I had the opportunity to code a little bit to help the team. I can suggest the following topics, where you can achieve positive outcomes with very little effort:<\/p>\n
Outdated project readme files<\/h3>\n
It’s just text, but it’s a good opportunity to hone your GitHub and markdown skills without breaking stuff.<\/p>\n
Besides helping a new member on his onboarding process, it will also spread the message that it’s important to keep it up to date.<\/p>\n
Outdated Boxen manifests<\/h3>\n
Some of our folks use Boxen to set up their environments. We often forget to update the project’s manifest. One more chance to practice. Go for it, your teammates will be grateful when they perform another clean OSX install!<\/p>\n
Front-end fixes (color, text, positioning, size, UI behavior)<\/h3>\n
They’re small, they’re easy to fix and may bore a developer to death. But to you it’s all new and rewarding. Those represent the majority of the commits I’ve done.<\/p>\n
As you become more experienced and confident you can expand into other areas, it’s just a matter of curiosity and opportunity.<\/p>\n
What are the benefits?<\/h2>\n
Between one commit and another I noticed some advantages. Below are some that might also work for you:<\/p>\n
Codebase knowledge<\/h3>\n
As you perform fixes, you get in touch with different parts of the code. It will naturally increase your awareness of where things come from and where they belong. From now on when you hear about a bug you will probably track its origin with ease.<\/p>\n
This also makes grooming sessions more productive, since you are more familiar with the effects a new feature will bring to the application, improving your negotiation superpowers.<\/p>\n
Better communication and relationship<\/h3>\n
Good communication saves a tremendous amount of time and energy. When you deal with code, you learn the technical vocabulary. In your next conversation with the team, people won’t need to translate jargon so you can understand. The same applies in the opposite direction.<\/p>\n
In my opinion, a manager that can code also increases the sense of fellowship, improving the overall relationship among team members.<\/p>\n
The feeling of shipping code<\/h3>\n
My first commit made some checkboxes to be selected by default. Nothing big, I know, but when I saw the customer using it I realized that shipping code feels amazing!<\/p>\n
This brings the sense of belonging and increases shared ownership. You should give it a try!<\/p>\n
Working with Pull Requests<\/h3>\n
At my very first day at Plataformatec, I realized that all teams were using Pull Requests. Shortly after, I figured out why we were using this technique. But I really understood it when I first submitted one of my own. Reading code and discussions added value to me, because I could see what was going on without interrupting people. Discussions also acted as a thermometer, revealing some insights about team relationship.<\/p>\n
Learning how to write tests<\/h3>\n
Your code will break some tests (believe me, it will). Panic? Never! Go on and learn how to write and run automated tests. It’s not that hard. Ask your friends, they will be happy to teach you.
\nLearning about tests will help your communication with developers and reinforce quality culture as well.<\/p>\n
Waste reduction<\/h3>\n
Waste is a fierce enemy and every chance to beat it must be taken. Coding can give you some opportunities to do so.<\/p>\n
Every little fix you deal with is one less interruption and context switch for a developer. Every conversation you join in a Pull Request is a shorter feedback cycle being nurtured and less time being spent in queues.<\/p>\n
These and other factors combined can positively impact the team’s performance.<\/p>\n
Where to start?<\/h2>\n
I recommend following these steps:<\/p>\n
Learning git and Pull Request basics<\/h3>\n
Here in Plataformatec we use GitHub, so finding documentation about Pull Requests wasn’t difficult. If you use it as well, you can browse Github’s Help and even use our Guidelines<\/a> as a reference. If you don’t, I’m sure you can find plenty of content about your version control tool with a simple Google search.<\/p>\n Look for a repository that you can commit without spreading panic if you mess things up. For instance, I have practiced in our Campfire bot. If you don’t find any appropriate repository, you can fork a public project on GitHub and use it as your sandbox.<\/p>\n In this phase my colleagues helped me a lot crafting my first Pull Request, I bet yours will do the same. Don’t be shy and ask them for help!<\/p>\n You have just developed a new skill, now it’s time to use it! Look for things similar to those examples I suggested and invest a little time in them. A couple of fixes later you will be able to work more independently, and the results will start to come.<\/p>\n If you do things in a careful and balanced way, they will happen just right. But there are some traps you should avoid:<\/p>\n Remember that you are coding to help removing obstacles. If you turn yourself into the person responsible for maintenance, you have just become a bottleneck for the system (or an irresponsible developer, as you prefer).<\/p>\n Despite the several advantages mentioned, not every manager likes to code. Don’t force people into doing it.<\/p>\n Joining Pull Request discussions brings great value. Micromanaging doesn’t. Don’t even think of using Pull Request discussions as a control tool. Trust your team!<\/p>\n I hope this blog post can help you and your team to improve. Have you ever tried something like this? What are you thoughts about it? Share them with us in the comments below!<\/em><\/p>\n As a Scrum Master, Project Manager or any other project management role you can have, removing impediments is part of your daily routine. They come in many forms and sizes, ranging from organizational to human ones. But there are also technical impediments, those you annoy ask your beloved developer teammates for help if you don’t … \u00bb<\/a><\/p>\n","protected":false},"author":34,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"ngg_post_thumbnail":0,"footnotes":""},"categories":[1],"tags":[231],"aioseo_notices":[],"jetpack_sharing_enabled":true,"jetpack_featured_media_url":"","_links":{"self":[{"href":"https:\/\/blog.plataformatec.com.br\/wp-json\/wp\/v2\/posts\/4836"}],"collection":[{"href":"https:\/\/blog.plataformatec.com.br\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blog.plataformatec.com.br\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blog.plataformatec.com.br\/wp-json\/wp\/v2\/users\/34"}],"replies":[{"embeddable":true,"href":"https:\/\/blog.plataformatec.com.br\/wp-json\/wp\/v2\/comments?post=4836"}],"version-history":[{"count":10,"href":"https:\/\/blog.plataformatec.com.br\/wp-json\/wp\/v2\/posts\/4836\/revisions"}],"predecessor-version":[{"id":4846,"href":"https:\/\/blog.plataformatec.com.br\/wp-json\/wp\/v2\/posts\/4836\/revisions\/4846"}],"wp:attachment":[{"href":"https:\/\/blog.plataformatec.com.br\/wp-json\/wp\/v2\/media?parent=4836"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blog.plataformatec.com.br\/wp-json\/wp\/v2\/categories?post=4836"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blog.plataformatec.com.br\/wp-json\/wp\/v2\/tags?post=4836"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}Practicing in a controlled environment<\/h3>\n
Looking for and working on impediments<\/h3>\n
Is there any pitfalls in this practice?<\/h2>\n
Creating dependencies<\/h3>\n
Forcing people to code<\/h3>\n
Micromanaging<\/h3>\n
![\"Subscribe](\"http:\/\/blog.plataformatec.com.br\/wp-content\/uploads\/2014\/11\/subscribe-to-our-blog.png\")
<\/a>\n<\/div>\n","protected":false},"excerpt":{"rendered":"