TIL
KO
π» Building a Development Team We Want to Work For
- ABZ Corporation
- Resignation and Re-joining
- A Development Team We Want to Work For
- 1. A Team That Doesn't Fear Questions
- 2. A Team That Knows How to Fail
- 3. A Team That Knows How to Be Proud
- Building a Development Team
- GEEKS
- Code Review and Development Documentation
- What Kind of Developer Do I Want to Become
- Conclusion
- Referenced Articles
Compared to excellent developers with long experience and impressive careers, my career still has a long way to go, but I think it's still an interesting career that people might be curious about.
ABZ Corporation
2021.06 ~ 2023.04 / 2024.01 ~
In this article, I want to write about what kind of development team I want to build rather than technical topics, and what kind of developer I want to become.
The articles I referenced while writing are organized at the bottom. Please refer to the articles corresponding to the numbers in parentheses!
Resignation and Re-joining
In April 2023, I had to resign due to the company's business situation. I had heard rumors that there might be workforce reductions, but I didn't think I would be included, so it was more flustering than expected.
After becoming unemployed overnight, I wondered what I should do next, but that was only momentary. With the mindset "I'll find a new job quickly! I heard they're hiring a lot of developers!" I started preparing for job hunting.
However, the wall of job hunting was much higher than I thought. The developer market had already become saturated after the pandemic, and it wasn't easy to stand out among them. Even if I was lucky enough to pass the document screening, I would fail at coding tests, assignment tests, etc. I was a developer who couldn't easily answer the question "Why should we hire you?"
About a month after failing the final opportunity I thought was my last chance - Woowa Tech Course - while browsing job postings, I found a familiar job posting. That's how I returned to ABZ Corporation, my first company.
During the first meeting with some familiar colleagues and new colleagues, everyone's common introduction was about our future aspirations, and I answered as follows:
I want to build a development team that anyone would want to work for.
A Development Team We Want to Work For
What kind of development team do you want to work for? Or what kind of company do you want to work for? There seems to be no question as clear yet difficult as this.
- Latest MacBook
- Back-friendly chair (Herman Miller or something... Herman Miller...)
- Development culture (blog, code review, etc.)
If it were the old me, I probably would have talked about things like the above. Boring stories that anyone could say... πͺ
However, now that I've been deeply involved in developing one product, folded a product I spent 6 months carefully making, quit the company and went through a difficult job hunting period, I think I can talk about what kind of development team I want to work for.
1. A Team That Doesn't Fear Questions
I don't remember exactly who it was, but there's one sentence that was really encouraging to me when I just joined the company.
"Even if errors occur, we can cover everything."
Of course, solving error situations is natural, but the words "It's okay if errors occur, we have the ability to solve them all, so you don't have to be afraid" felt like a huge wall was supporting me from behind. Thanks to those words, I was able to try more things myself, experience more error situations, and develop problem-solving skills.
Like the story of Kim Beom-jun (former CEO of Woowa Brothers, current COO of Naver) who brought 50,000 lines of code to ask questions to a complete stranger at the same company, and the person who helped him, I want to build a team that doesn't fear questions.
I want to grow as a team member who is ready to ask questions regardless of the other person's experience and skills when there's something I don't know, and at the same time, who can willingly answer what I know.
There are always team members to help, even if you stumble.
2. A Team That Knows How to Fail
When I returned to the company, I had a conversation with fellow developers who were familiar faces. "I will do my best more than before so that you don't experience the same failure as me. So please think about it together."
In a way, I experienced failure once. While fellow developers who resigned at the same time all successfully found jobs at excellent companies, I did not.
However, I don't consider this period a failure. If I had remained as stagnant water in the company with the same mindset as before, I would have remained a frontend developer who only knew how to use React awkwardly, with little interest in what kind of development team I wanted to work for, only thinking about what to do at the company.
I think the same applies to companies and teams. If you've fallen once, you become stronger so you won't fall for the same reason again. Even if similar crisis signals come, you develop a kind of sensor that can detect them in advance, allowing you to grow more than before.
That's why I want to build a team that knows how to fail. Because that's how we can get back up.
Today's failure was yesterday's best effort. So don't blame yourself.
3. A Team That Knows How to Be Proud
One common characteristic of companies with well-performing development teams is that they're teams that know how to be proud. I want to explain knowing how to be proud as follows: Not simply "We're so amazing" or "Only we can do this kind of thing," but knowing how to promote their achievements through blogs, SNS, etc., and naturally lead to hiring.
I think the companies called dream companies among developers - NKLT (Naver, Kakao, Line, Toss) plus Baedal-minjok, Danggeun Market (nowadays including Moloco, Dunamu, SendBird, making it NKLTBDT-MDS) - all have a well-established culture of recording their technical concerns. Furthermore, they know how to be proud of this through YouTube, their own events (like Toss's SLASH), LinkedIn, etc.
Regardless of company size, I think there are concerns and achievements that only developers can have. And these concerns and achievements are hard to know from the outside unless you actively promote them. Projects to change tech stacks, struggles for performance improvement, etc. - all developers reading this must have something worth being proud of. If this aspect is culturally well-established, developers will feel much greater fulfillment and motivation in their work, and it will help the company recruit better talent.
Our company is also making efforts to express various concerns and overall business content through Medium (#3). Looking back, I think I was able to work happily when I directly faced complex and unfamiliar domains, eventually achieved success, and was proud of it.
Let's be proud first. Then something will come of it.
Building a Development Team
GEEKS
What I always envied when looking at job postings from companies with large development teams was an environment where I could focus entirely on development. Seeing cultures like Today's House's Fix-it Week (#4) and Toss's Engineering Day (#5), I thought it would be great if we could also regularly have time to think about accumulated technical debt and challenges, so I created a culture called GEEKS.
GEEKS, meaning geeks (so-called enthusiasts) gathered together, is literally a place where company developers can meet once a week to talk about anything development-related.
// GEEKS Intro text I created
Let's meet once a week, even briefly, to talk about development-related topics
Anything is good! (side project code, interesting blogs you've read, newsletters you want to introduce)
For a healthy GEEK life not confined to just work code...Since there's no set topic or format, it was awkward at first, but now everyone is used to talking freely about various topics, and I'm personally very satisfied with this development culture as various solutions for our products and problems have emerged.
In the future, I plan to continue nurturing this space so we can conduct studies or have weeks dedicated to solving development problems like Fix-it Week.
Code Review and Development Documentation
Since I joined and we became 2 frontend developers again, we resumed code reviews. While rapidly implementing the complex domain of group buying markets as a product, we're improving by creating code duplication, unnecessary code usage, and areas that can be improved for each other.
Ultimately, we're steadily completing our own CoC to create code that anyone can read and understand, and internal development documentation that can be used in the onboarding process of new developers, along with code reviews.
Until the day I can post the development documentation I created in job postings...!
What Kind of Developer Do I Want to Become
At the reunion with fellow developers, there was one piece of advice I gave. "We need to create for ourselves what kind of developer we want to become. That's how people will want to work with us." Since no one but ourselves can know what work we do better than others or what we find more interesting, I hope everyone reading this will think about what kind of work they find interesting.
I want to become a developer who finds inconveniences inconvenient. The target could be users using the service, the work process within the team, or our product. I want to grow into a developer who thinks day and night on their own to find inconveniences and strives to solve them without anyone telling them to. (#6)
Also, I want to become a developer with both volume and density. Not just increasing years of experience, but becoming a developer who can help others by being interested in various domains and trends. Based on this density, I want to grow in the future into a developer who creates my own services regardless of space and time constraints.
Conclusion
Since it wasn't technical content, I spent several days writing and deleting repeatedly before finally finishing. Like a fellow developer said that you can see the person through their writing, I'm determined to become a better developer through better writing.