What I learned at a startup I didn’t learn in school
Guest Blog by ELP Student Chris Shih – Electrical Engineering – SUGS – Class of 2018
In Panama, fresh water is a limited resource. Multiple villages depend on a single well to supply all of their daily water needs. Such a system necessitates either a technical crew constantly on-call, or, having a monitoring system that can detect when the well breaks. Then a crew can be sent out to fix it. There were 4 different major types of wells in Panama, meaning that each product had to be customized. And to make matters worse, because of cultural acceptance issues, each sensor had to have a very specific appearance.
An engineer realized that every product had to be customized for every single customer when there were a lot of similarities between the products. The main cost would be the time of engineers as they went about customizing each part. Instead of investing so much time into customizing every single product, a platform to build these devices was built instead. By doing so, total costs were reduced to a point where Non-Government Organizations (NGOs) could purchase them and provide a constant, clean water source for villagers in Panama.
That platform is the foundation of Arch Systems.
I’m merely an intern at Arch Systems. I didn’t have the understanding and maturity to understand or envision this humble mission. My day-to-day work is similar to someone’s work at a big software company (for example, Facebook or Google). I’m spending my days coding, debugging, and testing. I’m learning less about corporate America and how to operate a company at scale. Instead, I’m learning how to direct my own projects and surrounding myself with driven people who want to make a difference.
Find a Purpose
“The best reason to start an organization is to make meaning;
to create a product or service to make the world a better place.”
This quote never truly resonated with me until I started working here. Everyone has a purpose to work, whether it’s for the paycheck or just to waste the days away. The optimal strategy is to have the paycheck become either the tertiary or quaternary reason why you are working at a startup. The primary and secondary reasons being:
- You have a humble purpose to pursue the company’s mission.
- You believe in the mission.
There’s a tangible difference between someone who works just because it’s their job and someone who works because they have found a purpose to work endlessly.
Everything breaks until the end (the end never comes)
“F**k it. Ship it.”
There is a college version of this quote, then a corporate version of this quote. In college, you ship assignments based on the grade you want. In startups, you ship products based on the amount of customer retention you want.
In startups, half-finished products still need to do everything they are expected to do. Iteration commonly adds one feature at a time. Each new feature still needs to function as expected and bugs need to be fixed.
The reason for this is two-fold. First, you have higher customer retention. Second, you save time by not having to remotely debug the device. I have seen hours of time wasted by engineers attempting to fix mistakes of the past. In this internship I work considerably slower than my work in college, but my work is of higher quality. One software bug at an early stage startup can waste hundreds of hours in the future.
Learn to write your own project guidelines and rubric
“Inspect the end to be achieved and then concentrate solely on the means.”
This is more a lesson for engineering in general. I believe I was forced to internalize it in a startup where there are you are working on new technology and time is scarce. It’s difficult to find things online to help you. There are times when your manager will be AWOL doing something for a customer or working different hours. It’s important to learn how to identify blockades and understand every step towards the final solution.
The ultimate goal: “Transmit this ‘payload’ to this cloud.”
The steps to the goal:
- Generate payload in end device
- Encode payload
- Send payload via RF signal to intermediate gateway
- Process and check payload contents
- Send payload via IP to cloud
- Process payload on cloud and wait for acknowledgement
- Intermediate gateway pings cloud for acknowledgement
- Intermediate gateway queues acknowledgement down to end device
- End device pings intermediate gateway(s) for acknowledgement
- End device receives acknowledgement
And then within each step:
- Generate payload in end device
- Learn how to pull sensors data from sensor API
- Learn how to properly package the data into a readable format by the gateway
- Learn how to properly package the data into a readable format by the cloud
- Learn how to properly encrypt the payload for security reasons
- Encode payload
- Learn how a payload must be encoded for RF communication
- Learn how to encode payload properly to prevent retransmission
- Learn how to use Forward Error Correction and a Coding Rate to allow signals to recover from dropped bits
And so on…
It’s not important to write it out, but by the end you should be able to. This skill is important in any engineering job, startup or not. In a startup, you’ll be forced to adapt by yourself. You will likely be one of the only ones in your small company who understands how that system really works.