Before my graduation in the university, I was inclined to join a startup due to the amount of content online against the existing corporate ladder and by reading Zero to One by Peter Thiel. Luckily for me, I had connections that were starting up a company from the ground up. As a fired up teen that was into startups, I didn't think twice, I joined them.
Jumping to three years after my first startup, I'm currently in my third startup, and here are the lessons or reflections I've gathered:
Being against openness and honesty to any company's management here in the Philippines is seen as a safe area to not get a bad reputation from upper management due to your ideas being bad or your complaints being negative. Thus keeping silent about your own ideas and complaints is seen as a good thing, but from what I experienced it isn't a good thing.
1. Your opinions could contribute to the next big solution/change that the company needed, thus improving the startup.
In my current startup, we always voice out our thoughts about the features we're developing. Some of the ideas we come up may be bad, but the act of brainstorming to come up with a robust solution makes the team feel confident in implementing that solution (and excited in bringing out a new feature).
This results to several features changing from time to time and having positive impact towards the usability of the user interface and the flexibility of the code.
This isn't only limited to the project we're developing, we also discuss the culture of the company in this manner as well, resulting into an enjoyable work environment.
My first startup didn't last longer than I expected. Having a dedicated group chat about our complaints as software engineers in the company made us hide our hatred and complaints towards the business-side. In the end, all of us software engineers decided to resign, resulting in dissolving the startup.
The problem here is not us leaving, but about us not voicing out our opinions about the current state of the company (before we decided to leave). We, as a whole startup, could've discussed about the problem and created a solution, with our without us leaving. Instead, we decided to leave without discussing our concerns thus creating unclear decisions.
In my experience, doing something all the time in the safe zone of your domain of knowledge seems comfortable, and gets the job done but, it lacks growth. I've experienced projects that use the same frameworks and libraries on and on and it gets boring to a point. As startups, we should learn to experiment on tools that could make our workflow easy (and sometimes cheaper).
Having a small team has its challenges when it comes to doing quality assurance (QA) or maintaining the infrastructure of your cloud. That's why in our startup, we decided to use technologies that could ease that part. Of course, it takes time to setup but it's rewarding in the long run to have these tools ready-to-use all the time. I'll name a few and explain it briefly. I won't go in-depth to keep this blog short.
Terraform - a cloud infrastructure manager that uses a JSON-like syntax for you to easily manage the cloud without having to create services in the web console. This can be useful if you have multiple projects with the same infrastructure most of the time.
Serverless - almost the same as Terraform but more focused towards maintaining serverless functions like AWS Lambda functions. Deploying serverless functions can help you save cost on compute time if you have functions that can be separated from the main server and isn't ran most of the time (e.g. a downloader of a PDF or CSV report). This is one of my favorite technologies to explore, so I suggest you look into this!
Gitlab - used mostly for its reliable CI/CD (continuous integration / continuous deployment). This is a powerful tool combined with Terraform & Serverless as it can automatically spin up and tear down services using Terraform and Serverless' CLI commands. It's also best paired with Docker. Learn it if you want to get into deploying projects automatically every push to a branch.
There are more technologies that I have tinkered with but these are the honorable mentions I can think of. These are the commonly used tools in our daily grind. So if you're looking to easing the workflow with deployment and cloud infrastructure, I suggest you look into these technologies.
Of course, these solutions won't solve problems forever if the scale of the software begins to grow bigger (meaning more work for QA automation and cloud infrastructure scripts). It only serves a purpose in deploying reliable products in a fast way for fast results. Eventually startups would need to scale their manpower depending on the amount of work that's starting to grow due to the product's scale.
As mentioned before, exploring new technologies are good for your growth but its impossible to learn everything that exists in the world of code. That's the beauty of the coding world, endless learning! Just test and try tools and possibly you'll come up with what suits your workflow best. In a nutshell, it's being open to discard old knowledge and learn something new since in the world of code, some of the tools you learn won't last long to see the world end and will be replaced with something new and shiny (R.I.P. Adobe Flash).
Since we're speaking about growth, this is a nice segue into the next and last lesson.
Being in the startup scene, there may be times that you are needed to squeeze every hour in a day. That sucks for some people but if it makes you feel good, then that's fine (whatever floats your boat). Just be mindful not to exhaust yourself too much or you might sacrifice your well-being due to burnout or any other illness that could come up from being overworked.
Pushing beyond your limit is also good from time to time, but be wary of what your limit is. Sometimes due to motivation, we tend to put unrealistic goals for ourselves that is really far beyond our limit that we can't even reach. This makes it easy for demotivation to creep in and say that "you won't make it!". From what I've experienced, it's good to also think of the process behind of achieving a goal. Starting there, assess what you currently have in your arsenal that could kickstart you in doing that process. In that way, you could see what you can currently reach in your limit and slowly climb the process from where you stand.
Always be open that processes tend to change midway of executing it. From the book Flow by Mihaly Csikszentmihalyi, he explained that moving towards a goal doesn't always go as planned, and I've experienced that in numerous occasions (most of the time in code). Sometimes we meet circumstances along the way that make us adjust in order to move forward. In the end of that changing path, there's a possibility that the end result could look better than you expected.
What is with this self-help mumbo jumbo you ask? Well, without those lessons, I would've been more burnt out as ever due to the amount of demotivation I had in my kokote (which as a word for brain or mind in Tagalog). There were multiple occasions that I set unrealistic goals for myself and end up discarding it because all I thought of was the goal, not the process. Also, there were times that I get upset if things don't go as planned, instead of adapting to what happened. If you've encountered these problems, try giving those lessons a go!
Learning to set realistic and attainable goals, and even learning to celebrate small goals, can make you more motivated to move forward and also leading to making you a happier as a person.
Don't go drowning in a sea of unfulfilled dreams and forget yourself. Start decluttering your mind and focus on what you can do in the present. It's easier said than done and eventually you'll encounter these moments in life from time to time, but it's part of the process.
Take care of yourself! It's not bad to take time off for eating food or sleeping on time (and even play games, just not too much). Sometimes for better quality work, we need to take time off from work (as juxtaposed as that sounds).