14 Month Retrospect as a Web front-end Developer

I recently left a 14-month stint as a front-end developer at two startups. I returned to school this semester, spending the first six months as a credit-bearing school work placement and the remaining eight months working full-time at a seed-stage startup. Here’s a brief retrospective of my time at the company.

I’m a senior in college and will graduate next year. I started working in development for the first time in early 2019, so I’ve been getting paid for development for over two years now. I have experience in outsourced development, personal projects, and company work.

Why I delayed graduation and started working for a company

• I started development late, so I needed more time to learn and study development before graduating. I didn’t have the confidence to go into my senior year as it was.
• I wanted to know if working at a startup was a good fit for me. It would be the fastest way to find out. I also wanted to figure out what kind of company I liked and what type of work environment I liked.
• To do this, I devised a rough plan - why not try two organizations in a year?
• I wanted to save some money and graduate.

Companies I worked for

First company (6 months)

I was hired as an intern for a semester as part of my school fieldwork.

It was a global chatbot solution startup operating in China and Korea, and not only chatbot but also SI across the web. I decided to join the company because they had about 15 developers in the series A stage, and there was a third-year gunner who I could definitely watch and learn from. At that time, I wanted to meet a real gunner so severely.

I developed the front end of the company’s commerce and SI projects using Vue.js for large and mid-sized companies.

My biggest gain was the experience of collaborating with so many different stakeholders within the company. I worked with PMs, planners, designers, backend developers, fellow front-end developers, Chinese developers from the company’s Shanghai office, and people from large enterprises (client-side). I kept thinking about how to communicate and collaborate. Speaking English is a must… I decided that one day, I would take the time to study it.

When I joined the company, I worked in an office inside a large corporate building. This experience indirectly exposed me to how a large organization works and how people working in large companies work, which was good for me since I had no corporate experience.

I created an NPM library for efficient development and a front-end internal wiki just before I left.

Second company (8 months)

At my first company, I worked on many outsourced system integration projects, which meant that my impact on the business as a subcontractor developer was limited to what the client asked me to do. As a subcontractor developer, my impact on the industry was negligible. This whetted my appetite and made me want to try working in a more minor team where I could be more involved in decision-making.

The second company is a seed-stage startup that provides a fashion pre-order platform. The platform attracts designers who want to create fashion products and matches them with consumers through pre-orders. Despite my lack of skills, I led a three-person front-end development team, which was possible because it was a very early-stage team.

As my responsibilities and roles increased, I had to think about design, component structure, health management methods, deployment automation, mobile app development, and more. I kept thinking about the fear of maintaining a live service, the carefulness required, and how to collaborate and develop efficiently in an early startup with rapidly changing requirements. I didn’t do a good job because I was a junior. Still, I also had the opportunity to think about how to make developers work well together and grow together.

I learned to swim with my feet on the ground. Being an early development team with no seniority, I wanted to know if my judgment was sound or we were on the right track, so I was constantly studying and researching. Along the way, I gained a little confidence that even without a gunner (although I wish I had one), I could learn and master things independently and contribute to the product.

It’s a shame I didn’t get to do everything I had planned, but it was rewarding to see the service increase. I hope the Series A investment goes well.

My coworkers were really great people. It was an energetic startup with much love for the team and eagerness to see it grow.

Reasons for leaving.

The main reason I left was that I wanted to graduate from university sooner rather than later and have more freedom regarding my status.

Second, I wanted to study independently before returning to the job market. As a non-major, I only have a little knowledge of computer science. I needed more time to organize the knowledge I didn’t understand because I was building products quickly.

Of course, I could have continued working, but I like to do something when I feel ready. Being the person I am, the last time I’m in school before graduation is the last time I’ll be able to study at my own pace and on my own terms.

Feelings

The ‘me’ at work

I’ve never experienced “me at work” before. It made me think about how I like to work and what a good work environment looks like for a developer.

In a startup, there is no rigid work structure, so it’s been fun to try out new ways of working and figure out the most efficient way to do things.

Just a developer, not a front-end developer

In addition to web front-end development, I’ve been exposed to mobile app development, infrastructure design, and CI/CD implementation. I’ve realized that I’m not just a front-end developer. I’ve learned a lot of different skills by doing things.

Just because you’re a front-end developer doesn’t mean you’ll be doing only front-end work in a company, especially if it’s small. I realized that as a developer who builds software, you need to know the basics to learn quickly and produce a certain level of quality in any given task.

Understanding what was happening in the development team was essential for productivity and practical discussions. The front needs to understand the backend and infrastructure, too. The learning never ends, and there seems to be nothing you don’t know in the development world.

I don’t want to say, “I can’t do this,” or “I don’t know that.” I don’t want to be a front-end developer; I want to be a developer.

I’m too junior to lead a team, yet

I’m a junior developer, and I’m still thirsty for growth. But in my second company, I led the front team. Here’s the disconnect: I could have taken care of the team better to maximize the team’s productivity as a whole. When it came to work distribution, I wanted to do what I wanted to, which would allow me to grow. I wanted to do things that would help me grow rather than devising a work distribution that worked for the team rather than me. I needed to think about the team’s productivity first.

I didn’t know my teammates’ abilities, and I thought, ‘If I give this task to this person, they’ll be able to grow more.’ I didn’t do things like study together so that the whole team could grow. I shared a couple of articles a couple of times that were technical things that I wanted other people to know.

I’m a junior developer, so maybe that’s an excuse. I may need to see the big picture. Perhaps I’m not good enough. I want to be a developer who can take care of the team, grow with the team, and grow with the team as I gain more skills and experience. I apologize to my teammates in many ways.

Early startups are comfortable with juniors in the wrong way

Early-stage startups need help from talented developers. The company keeps its eyes low, and hiring inexperienced junior developers is relatively easy if you can get the job done right away.

Early-stage startups are more concerned with rapid feature expansion and quick products to showcase than the solid design of the software for immediate growth. Even if you solve a problem in a way that doesn’t look good for the future, as long as it’s solved, it’s a job well done for the team and the company. You don’t have seniority, so you don’t know upfront if this was an excellent way to do things. You only realize you’re doing it wrong when something goes wrong.

Of course, you can grow through trial and error. But if the cycle is too slow, and in the worst-case scenario, you don’t explore the way you do things or the technology, you keep doing things the way you’ve always done them. Then there’s no growth, and you think you’re doing an excellent job at the company because you’re doing things the way you’ve always done them. It may be a lot of work, but you’re doing it similarly, so it’s comfortable.

From this perspective, I think early-stage startups are good places for junior developers. You can’t grow as fast as you can be broken, so I think it’s really important for a junior developer in an early startup to take the initiative to learn and constantly look for better ways to do things than the design or code you’ve done.

I don’t know if I did well, but I kept studying and validating. If you ask me if I gave 100%, I’m not sure. I keep thinking that if I didn’t do that, I should have applied something sooner (I’m a very timid and futon-kicking person), so I just need to keep studying and validating wherever possible.

Developing for ‘me’ and the company

As mentioned in the paragraph above, early startups are more concerned with scaling features and delivering results quickly than solid software. Even if I wanted to make structural improvements or refactoring, I often found that the CTO or development team leader wouldn’t allow me to grab a task and work on it in a sprint because they had other higher-priority things to do faster.

While I understood the situation at hand, I was frustrated. Partly, it was clear that if we continued to add features to this structure, development productivity would suffer. The other reason was that I wanted to grow by adapting what I thought was a better structure.

I was able to make very slow, incremental improvements. When I was working on a particular feature, I would refactor it so that I could apply the improved structure in very small increments. Or I’d take time to refactor while working on something else, like doing a little more work.

In retrospect, refactoring was beneficial not only for the company but also for me. I planned to experiment with better structures, improve the product, and grow.

Of course, I’m grateful to my company for allowing me to refactor in this way among all the other things on my to-do list. Suppose you have a structural improvement you want to make. In that case, it’s a good idea to propose a refactoring or structural improvement to your company to help it grow. Of course, it has to be obviously beneficial to the company as well as to you, and the task has to be acceptable to the company.

Startups are an uncomfortable and cutthroat labor scene

Before I experienced corporate life firsthand, there was something romanticized about startups. You know, like climbing on a rocket and experiencing insanely fast growth.

But when I joined my second company, it was going through its first Death Valley (…)

The company atmosphere wasn’t great. Many people were leaving, the numbers weren’t going up fast enough, we weren’t seeing growing metrics, and it was more of a point where we were investing in developing metrics. The development team had to create new products within deadlines that were ridiculous in hindsight, and they were getting burned out.

After 4-5 months, the company started to grow again: we had more designers coming to us, and the number of projects we were opening was at an all-time high. It wasn’t a J-curve, but it was enough to get us out of a plateau and back on track, and by the time I left, we were looking for a Series A investor.

I realized that to build a rocket that grows, you also have to struggle. Every moment of a startup can’t be growth. I also learned that there’s always a deficit and that you must maximize your resources and try to grow a little to move up. Along the way, people suffer a lot.

I realize that this can be an unbearable work environment for some people. It’s uncomfortable and intense. For me, though, it was a very challenging environment, and I think I learned a lot from it, both inside and out. I would definitely come back to work at an early-stage startup again someday but with a little more experience and skills.

#closing remarks

Looking back on my 14 months at the company, I’ve experienced and learned a lot quickly, and I still have a long way to go. I want to continue to build my skills and learn to become a helpful developer to both the team and the people in my future organization.

I want to thank everyone who has worked with me. You taught me a lot and made me a better developer. I wish you all the best and success!