It's too early to give up saying, "You can't change the development culture by yourself."

This story is article that records the past six months when a developer, a regular employee, has worked hard to create an in-house development culture. Half a year later, I achieved my desired goal. If we maintain this method, I'm sure it will gradually change to a better shape, even if it's slow. We hope that more and more companies with a good development culture will work in a development culture that will satisfy more developers. Then, let's get started!

Technology blogs are a great marketing tool.

There is a popular topic that appears when you meet and talk to several developers during development community activities. It's the development culture. Companies called developers' wannabe appeal that they have a good development culture as well as salaries. If you're a developer who wants to learn technology, is there you be able to do say "no"?

The importance of development culture increases day by day.At least heard of the IT companies that have set up technology blogs. "Naver D2", "NHN Meetup", "Woowahan techblog", "Line Engineering" and "Kakao Tech" as well as "ELEVEN STREET Tech Talk" which was specifically intended to signal development leaders' lectures. The same goes for my "SARAMIN HR" and many companies, such as "MUSINSA", "Daangn Market" and "Kurly" want to grow technology blogs.

The reason for creating a technology blog is so clear. The basis for sharing technology and experience includes marketing toward developers. "Our company is great!" It's a means to make you feel like, "How is it? You want to work with me, right?" Maintaining a technology blog while hiring DevRel separately means that more outputs will occur from a long-term perspective. Developers naturally accept the company positively when they look up the technology blog while working. Technology blogs are marketing tools that invest developers from a long-term perspective.

Let's start. Development curation.

The technology blog only brings out the contents, not confidential. Since it is a marketing tool, we cannot reveal the company's weak point. Therefore, even if you operate a technology blog, the gap between in-house developers will not narrow. Technology blogs are tools to attract external developers. Of course, developers themselves brand through this, but this behavior is difficult to directly relate to their colleagues.

I wanted to reduce the deviation between colleagues and create a culture where we can talk about development without hesitation. However, there are many developers to approach each person individually, and it is difficult to reach out to them. It takes a lot of time. Even if it's simply calculated as 100 people, it takes as many as two weeks per person in an hour. While living in agony, "How can I create a communication channel for in-house developers?" I came up with the idea of using the strategy used in technology blogs. To whom? To the company developer!

The method is not much different from the technical blog. Should I say it's my own courtship to my colleagues? I packed it under the name of Development Curation and held a pen for my colleague. Writing is not that difficult for me. It has already been half a year since regular mailing was sent to in-house developers.

In fact, it's curation only in words, and half of it is a topic that I translated into writing for my colleagues.

I had a lot of worries until I suggested 「development curation」 to CTO. Will my colleagues respond? Wouldn't I look annoying for no reason?I had a vague fear of that. Nevertheless, I started because the act of organizing in writing is my own means of study. If you look back while organizing it with your hands, you can see the faint knowledge. Contents that you don't understand yourself are not transferred to writing. It's something I usually write anyway, so I decided to select a fellow developer as a reader and write it down. Including the first publication in October that I wrote down in advance, I've already written 17.

Trial and error due to clumsy preparation.

When I started 「Development Curation」, I didn't make a specific plan, so I experienced trial and error. I have motivated but didn't prepare anything. I've seen that a person who was my senior in the development community has been writing steadily, but the subject matter is clear because it's a translation of periodicals. But you can't bite the story you brought out of your mouth once. I hope those who are interested will not go through the same trial and error as me.

The first one is a publish serially. The company's main task is to develop main services, and 「Development Curation」 is a side project that spends personal time alone. My role in the company is a Back-End developer, so my main project is my top priority.

When it comes to writing, you have to figure it out and organize it in your head, right? At first, I thought weekly serialization would be possible, but it was ridiculous arrogance. It was absurd unless it was the main task. We decided to issue it bi-weekly because we thought consistency was important. Resource restrictions are too large to be combined with service development. It was temporarily changed to weekly serials only when a lot of pages were needed, such as 「Object」.

The second is to select a topic. It doesn't mean much to simply spread technology news then and then. You might think of it as another spam. There are also limited topics that can encompass all developers. Also, if you don't have time to look at the latest trends due to sudden busy work, you don't have the right material to move to. No interesting materials may be found during the week.

For regular serials, sufficient data must be prepared in advance. At first, I hurriedly prepared whenever the deadline for myself approached. I didn't collect any extra data. As a result, there were days when it was difficult. It was clear that if this condition persists, it would fail. I can't do that! When I usually come and go by subway, I collected data from time to time and began to classify them by topic in advance. Now, we have more than 10 extra minutes in the warehouse. I feel reassured! As data were prepared in advance, it became easier to bring up topics suitable for the situation. The writings I've been writing alone for a long time have also helped me a lot.

Changes brought about by development curation.

「Development Curation」 is based on areas where in-house developers are studying or where interest has increased due to in-house education. Sometimes I dealt with the AS for the TF I participated in. Immediately after the open recruitment of new developers, I included helpful content for them. Perhaps because of that, there are people who directly cheer for us, saying that they are watching well. Thanks to you, I was able to last for half a year. I couldn't say hello separately, but I'd like to thank you through this article.

Of course, there are more important changes than this. What is it? Finally, we have an in-house developer who will produce "Development Curation" contents! No matter how good the purpose is, you can't go to culture by yourself, right? It's encouraging to have a colleague to be with.

In the early days of 「Development Curation」 we recruited participants as an introduction.

Such content planning requires a lot of time during work to be done alone. Even in personal time outside of work, we need to figure out the news from time to time and see what topics will attract colleagues' attention now. It's only a side project now, so the proportion of practice is much higher, so there's a lot of energy to consume alone. One article must be revision dozens of times before it is completed.

Fortunately, when I constantly nudge the developers around me, there appeared a person who said he would write on his own. In fact, he has already written and finished teaching. The 16th theme of 「Development Curation」 will be shared with in-house developers. One step two is difficult. But step three and next step will be much easier. It will make it a place for developers to appeal their achievements.

Finally, an in-house developer participated in 「Development Curation」

One for all, all for one, Development culture that starts with writing.

There is a line that comes to mind when you think of Alexandre Dumas' novel, 『The Three Musketeers』.

All for one, One for all!

Shall we reverse the order of this sentence, which is also the unofficial motto of Switzerland?

One developer for colleagues, all developers for development culture.

Development culture certainly cannot be changed to alone. Culture is a flower that blooms in a group. It doesn't even bloom overnight. But if you don't move, you're just another developer complaining. So let's approach for our colleagues, not ourselves. I can't force others to like it. I'm even a just team member, not a management. So let's come up with a strategy and approach it.

I brought a familiar theory of behavioral economics. Nudge, when you create an open field and apply it, willing people change at their own pace. At first, even if it's slow, it finds its own speed one by one. At the same time, let's find issues solved by colleagues, share experiences, and actively encourage those who study content that will help other developers. If you are afraid to write, add that you will teach and teach your composition yourself. However, don't force me. You have to approach it for your colleagues. It's called culture because it can't be formed by itself.

Closing remarks

Individuals are independent subjects, so they do not move unless they benefit themselves. It's a reasonable reward to make rigid people move. And the biggest advantage for him is that you, who stand at the forefront and lead the way, will take it. Even if the company doesn't approve it, it's okay. Each material that started like this gathers to become knowledge and is made into a portfolio. How many developers have tried to change the development culture steadily? With its specificity, it will be a good weapon for companies that want it. Even if the company you work for now does not change, it will serve as a stepping stone for companies with development culture.

Nothing changes if you don't move and complain without taking any action. Why don't you move yourself and become Janne d'Arc? I'm a 6th year Back-End developer who is no different from you. If you have any questions, please feel free to email "devellany@gmail.com".

The link attached below is a project in collaboration with the human resources team to participate as an in-house developer interviewer. Even if it's not here, I hope to face you someday.

라민이가 말한다#1 : 개발자 in 사람인HR

안녕하세요! 인사팀 리크루터입니다!

www.saraminhr.team