Sudo Internship Journey (1)

The contents of this post are based on true stories. Any resemblance is not a coincidence.

From July 2015 to October 2016, a span of over a year, I started my first internship during the second semester of my sophomore year—at Sudo. Back then, Sudo had just been founded (though the official website was mostly built and constantly iterating), and there were only about 13 or 14 people when I joined.

Everything was unfolding amidst uncertainty. Being at a company targeting software engineers, I was fortunate enough to attend many offline community meetups and conferences, meeting numerous outstanding developers along the way.

While it might not have been the best internship objectively, it was undeniably a thrilling year. So many things happened back then, and between schoolwork and the job, I only managed to jot down sporadic notes. As I’ve recently been preparing to look for a new job, I sorted through those old, scattered notes, hoping to document this journey.

This internship started with an introduction from Hsi-Che. Back then, to catch up on my programming progress from the past, I spent whatever time I wasn’t working part-time jobs in the library writing Java and building web pages. Because I needed prolonged periods of deep focus and my phone had no mobile data, my classmates could rarely reach me.

Hsi-Che happened to know I was interested in web development, so he introduced me to a startup for a chat. To my surprise, I got the offer just like that.

I’m not sure if it counts as lucky, but experiencing a company’s rise and eventual shutdown was certainly a rare experience. (Though I wouldn’t want to experience it a second time…)

What was Sudo?

Although the service has shut down, searching the keywords on Google still brings up quite a few results. They can be roughly categorized into:

• A matching platform to help software engineers find jobs
• A matching platform to help students find internships
• A matching platform offering headhunting services to job seekers
• A massive hub for searching engineering and internship job openings

The Warring States Period of Front-End

When I first joined, I wasn’t familiar enough with JavaScript. So I started with Tuts+ video tutorials (paid for by the company) to shore up my JavaScript fundamentals. At home, I pored over the “Rhino Book” (JavaScript: The Definitive Guide) to understand tricky concepts and implement some built-in functions.

Front-end development had just entered its “Warring States” era back then: the Angular hype was gradually cooling down, React was on the rise, the original Flux architecture was being supplanted by Redux, and Babel, ES6 syntax, and Webpack all burst onto the scene around the same time. Luckily, because the team happened to be using React to build complex pages, I started learning these relevant technologies.

After the original front-end developer resigned, I took over development of the main site. It was my first time collaborating intensively with a team: running Scrum together, resolving tickets, opening PRs, writing style guidelines, introducing linters, and so on. Only later did I realize that very few startups have such a well-defined process. Most simply have managers demand whatever feature comes to mind, and the development workflow suffers due to misaligned expectations.

The Engineering Team

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

At first, I simply felt it was a pleasure working with them. Only later did I realize how rare it is to find such a well-rounded team.

During my internship, thanks to Denny and Keke focusing on web development, I gradually learned Babel, ES6 (which was blowing up at the time), React, and Redux. Even before RxJS had gained traction in Taiwan, Denny came up to me and said: “When you have time, take a look at RxJS—functional reactive programming.”

Denny

There’s a saying: “Those who can control their weight and their waking time can achieve anything.” He once sacrificed XXX just to write code.

In the music world, when someone achieves extraordinary technical mastery, they’re often described as having “sold their soul to the devil.” Perhaps you could say Denny “sold his soul to code.”

Describing Denny solely as a coding fanatic doesn’t quite do him justice, though. Aside from coding, he also founded “United Issue” and “Qollie”.

The memory that sticks with me most vividly was waking up early one day (4:00 AM) to write code and seeing Denny still online. I pinged him on Slack, and he actually replied! Another time, during a company retreat while everyone else was playing games, Denny was sitting by himself with his laptop, watching a YouTube channel called Fun Fun Function (about functional programming) until he dozed off.

Most people’s effort hasn’t reached the level where talent even matters.

That was probably the biggest takeaway Denny gave me. Even though he left during the latter half of my internship, his attitude and drive to learn are things I’ve always deeply admired.

Even someone who didn’t major in CS is working this hard—what the hell are you doing slackin’ off?

That was pretty much the vibe.

Peter

Let’s start with technical skills. A designer who can write HTML and CSS is already a rarity, but he could also use Bootstrap and Ruby on Rails syntax to assist with development, and he would submit PRs on GitHub to fix front-end UI issues.

The pages he designed were never overly idealized, either.

Typical designers (especially those transitioning from graphic design to UI) often design overly perfect screens: the copy fits just right, images are gorgeous, cards are equal height, widths are fixed, and so on.

In a real-world web application, however, state is rarely one-dimensional, and user input is never as clean as you imagine. How do you handle overly long text, line wraps, or text truncations with ellipses?

Then there are other states to consider: empty states, error states, edge cases, loading states, and more. These are common blind spots for designers.

Another great quality of Peter’s was his genuine willingness to communicate with engineers. He would actively push back on unreasonable requirements and clarify problems. When I first joined the team, because of my position (the youngest, still a student, and with the least development experience), I was always hesitant to voice my opinions. But he constantly encouraged me to speak up and share my thoughts, because the consequence of not communicating is getting handed a pile of crap. I resonated with this profoundly after joining Sudo.

Henry

Henry was a seasoned software engineer with extensive experience. From web development, mobile apps, and backend systems to DevOps and Linux operations, he knew it all inside and out. He would often share technical articles and insights, and I learned a tremendous amount from him.

Beyond engineering questions, Henry could also answer your questions about obscure video games, Steam sales, recommendations for American TV shows, and much more.

Keke

I think Keke is the living embodiment of the “Three Great Virtues of a Programmer.” These traits might sound negative at first glance, but in software development, they are virtues. Keke’s mindset had a huge influence on me going forward: make it work first, make it right later.

Laziness

At Sudo, so many things were automated. Automated deployments, CI, Slack bots handling all kinds of operational tasks, Hubot allowing other departments to query metrics, Rollbar integration, and more—all built from the ground up by Keke (along with Henry). This saved an immense amount of effort in development. Although I wasn’t directly involved in building them, learning about DevOps concepts and common third-party services throughout the process proved invaluable for my future engineering work.

James

Managers are crucial; they practically determine your overall job satisfaction. Guiding discussions back to the right track, controlling development timelines…

These things, which might seem like givens, became painfully obvious to me only after working at other companies: meetings scheduled without agendas, meetings held without clear objectives, no one tracking timelines or following up. In the end, the development schedule fell into complete disarray. Only then did I realize how precious it is to find a PM you genuinely enjoy working with.

I won’t be introducing the other teams here since I didn’t collaborate with them closely.

Sudo Weekly

Sudo Weekly was an initiative spearheaded by Keke to help the engineering team share technologies and articles we encountered. Although it has long been abandoned as everyone went their separate ways, you can still check out past issues for reference.

To be continued.