Sudo Internship Journey (1)

This post is based on a true story; any resemblance is purely coincidental.

From 2015–7 to 2016–10, over the course of a little more than a year, I started my first internship in my second semester of sophomore year — Sudo. At that time, Sudo had only just been founded not long before (though the official website was already mostly built and was still being iterated on), and when I joined there were only about 13 or 14 people.

Everything was still unfolding amid uncertainty. And because I was in a company that faced engineers, I had the chance to take part in many offline communities and conferences, and along the way I met many outstanding developers.

Although I wouldn’t call it the best internship, it was definitely quite an exciting year. A lot happened back then, and because I was busy with schoolwork and work, I only wrote down bits and pieces of notes here and there. Coincidentally, I’m now getting ready to look for a new job, so I整理ed the fragmented notes I had written in the past, hoping to record this period of my journey.

I got this internship through an introduction from Xizhe. At the time, in order to catch up on old programming progress, whenever I wasn’t working part-time I would be in the library writing Java and building websites. Because it required long periods of concentration, and my phone had no internet, my classmates had a hard time finding me.

Xizhe happened to know that I was interested in web development, so he introduced me to a startup to chat. I didn’t expect that I would end up joining it.

I don’t know whether it counts as lucky, but experiencing a company from its rise all the way to the end of its service was perhaps a rare experience. (Though I don’t want to go through that a second time either…)

What is Sudo?

Although the service has now been shut down, you can still find quite a few results by searching the keyword on Google. It can broadly be divided into the following categories:

• A matching platform to help engineers find jobs
• A matching platform to help students find internships
• A matching platform where you can apply for headhunter services to find jobs
• A large platform for searching engineering and internship openings

The Warring States Era of Front-End

When I first joined, I wasn’t yet familiar enough with Javascript, so I started by taking tutplus tutorial courses (paid for by the company) to make up for the basics of Javascript. At home I would read the Rhino Book to understand concepts I didn’t quite get and implement some built-in functions.

At that time, front-end development had just entered a Warring States era: Angular was fading, React was rising, the original flux was gradually being replaced by Redux, and babel, es6 syntax, and webpack all emerged around the same time. Fortunately, because the team happened to be using React to develop complex pages, I began learning the related technologies.

After the original front-end developer left, I started taking over development of the main site, which was my first time working closely with a team. We did scrum together, triaged tickets, submitted PRs, wrote style guidelines, introduced linters, and so on. Only later did I realize that startups with such a complete process are actually quite rare; in most places, managers simply ask for whatever feature they want and development proceeds directly, and the workflow varies depending on each person’s understanding.

The Development Team

I haven’t introduced the development team yet. When I first joined Sudo, the development team consisted of Keke, Peter, Denny, and Henry.

At first I simply felt that working with these people was very pleasant, and later I realized how hard it is to find a team as solid as this one.

During my internship, because Denny and Keke were focused on web development, I gradually learned babel, es6 (which was just becoming popular at the time), react, and redux. Even before RxJS had really taken off in Taiwan, Denny had already come over to tell me: “When you have time, take a look at RxJS, functional reactive programming.”

Denny

There’s a saying: “Someone who can control their weight and their wake-up time can do anything.” He once sacrificed XXX for the sake of writing code.

In the music world, when someone has extraordinary achievements or skills, they’re described as having “sold their soul to the devil.” Then perhaps Denny could be described as having “sold his soul to code.”

Saying it like this makes Denny sound like a programming fanatic, which is perhaps unfair. But besides writing code, he also founded “世界大代誌” and “求職天眼通”.

What I remember most clearly may be one morning when I got up early (4:00 AM) to write code and saw Denny still online; after I sent him a Slack message, he actually replied. Another time, during a company trip, while everyone else was playing games, Denny was sitting alone with his laptop watching a channel called funfun function (about functional programming) and dozing off.

Most people’s effort is still nowhere near enough to surpass talent.

That was probably the biggest takeaway I got from Denny. Although he left in the second half of my internship, his attitude and spirit of learning have always been something I deeply admired.

Even someone outside the field works that hard, so what the hell are you doing?

Something like that.

Peter

Let’s start with skills. It’s already rare to find a designer who can write HTML and CSS; he also knew how to use Bootstrap and Ruby on Rails syntax to help with development, and he could use GitHub to submit PRs and solve some front-end page issues.

The pages he designed also weren’t so idealized.

Ordinary designers—especially those who transition from graphic design to UI design—often design very perfect pages. The text fits exactly, the images are beautiful, the cards are the same height, fixed widths, and so on.

But in real web pages, there isn’t just one state, and input won’t be as perfect as you imagine. How do you handle overly long text, line breaks, and ellipses?

There are also other states to consider: empty states, error states, edge states, loading states, and so on. These are common blind spots for designers.

Another point is that Peter was very willing to communicate with engineers, and he would try to respond to unreasonable requests and clarify issues. When I first joined the team, because of my position—youngest, still a student, and with the least development experience—I didn’t really dare to speak up. But he kept encouraging me to express my opinions and share my own ideas, because the result of not communicating is eating shit. I really came to feel that after joining Sudo.

Henry

Henry is a very experienced engineer. From web development, app development, back-end, devops, to Linux operations, he was very familiar with all of it, and he often shared technical information, from which I benefited greatly.

Beyond development issues, Henry could also answer your questions about a certain game, Steam sales, guides to watching American TV shows, and so on.

Keke

I think Keke is like a real-life version of the 3 great virtues of a programmer. These traits may seem negative, but in software development they are virtues. Keke’s personality influenced me a lot later on: first make it work, then make it better.

Laziness

At Sudo, many things were automated: automated deployment, CI, Slack bots connected to business operations, using Hubot to let other departments retrieve statistics, Rollbar, and so on. These were all built by Keke in one way or another (and Henry too), saving a lot of effort in development. Although I wasn’t directly involved, I gradually learned some knowledge about devops and common third-party services along the way, which was very helpful for later development.

James

A manager is very important; they can almost determine your satisfaction with the job. In discussions, they keep the topic focused in the right direction and control the development schedule.

These may seem like natural things, but after I went to work at other companies I felt this very deeply: no one sets meeting times, meetings have no clear goals, and no one manages the timeline or follow-up. In the end, the whole development process turns into a mess, and only then do you realize how precious it is to find a PM you enjoy working with.

There wasn’t much actual close collaboration with the other teams, so I won’t introduce them in detail

Sudo Weekly

Sudo Weekly was launched by Keke, leading the development team in sharing the technologies they had come across. Although it has long since fallen into disuse as everyone went their separate ways, you can still look back at the past issues.

To be continued.