Forem: Kathleen Bongco

Side Project Blog: Clear Bench - Tech stack and Backstory

Kathleen Bongco — Wed, 13 Aug 2025 14:37:41 +0000

Prior to becoming a software engineer, one of the projects that has always been on the back of my mind was creating a LIMS system of some sort. This came from my experience as a laboratory technician.

On my second week for working in a cosmetics company, I remember walking in to work and starting to test some samples. All of a sudden, one of the scientists for the innovation team comes running to me and my colleague in a panic and extremely angry at us. Her first thing was to yell at us about not testing her samples as it was overdue by about a week. She brought her manager and our manager to rip us a new one.

So the questions popped up that I asked:

Did you drop off the samples in the appropriate chambers?
Did you submit the paperwork that goes along with this so we can take it down + see the estimated dates for testing?
Did you upload the sheet onto the shared drive for us to use?
Did you place the paperwork into the folder to be tested?

The answer to the first question was yes. However, the answer to the questions for the last 3 questions was a big fat no.

Even though the answers to the last 3 questions was a no, the blame was still placed on us the stability team that was responsible for testing the samples. So in the end, myself and my colleague was reprimanded.

This is one of the few stories that stood out to me during my time as a laboratory technician which made me ask the question of:

"How can i make this process more efficient and more accountable for all parties and not just the lab techs?"

I've actually gone through several iterations of this project but I've only officially came up with a specific name for it. (Thanks ChatGPT).

This is a project I call "Clear Bench". Clear Bench is "a modern sample submission app for busy tracking teams who are tired of using excel spreadsheets". At all the labs I've worked at in the past, they really loved using excel as their database and a way to track their samples testing results. While that's great and all, I'm a firm believer in technology being able to make things more efficient and less of a pain for everyone involved. While using excel spreadsheets is a cheap way of doing things, it often leads to mistakes such as miscommunication and missing data.

Clear Bench aims to:

replace ad-hoc systems with a structured, digital sample submission
ensure all users have visibility into sample status
reduce finger pointing by making workflows transparent.

So let's talk Tech stack and why I went with what I went with:

🧠 Frontend: React (Vite, TypeScript, Zustand)

So I have professional experience both working with React and Angular. I like Angular because it is very much a batteries included framework with everything I would need from Reactive Forms, RxJS, etc. However, I went with React instead.

I went with React because it is the framework I am most comfortable with. It gives me the flexibility to scale the UI overtime. Since React is a library, there is a lot of flexibility when it comes to the packages I can throw in my project. I can choose the best tools for what I need, instead of being locked in to Angular's opinionated structure.

Vite, I discovered vite pretty early on and I loved how fast it was when it was scaffolding my projects vs CRA (create-react-app)
Typescript, I used to joke that Typescript was Javascript with extra steps, and I did not really like the type safety. However, the more I worked with it the more I realized how useful it was with helping me catch bugs early on.
Zustand, while I have experience using Redux in my previous roles. I did not like the amount of boiler code that came along with it. For all intents and purposes since this is a "small" project for now, I wanted to go with something more "lightweight".

🔧 Backend: FastAPI (Python)

I chose FastAPI (Python) for what I will be using to develop my backend for this project. For most of my professional career as a software engineer, I was often in front end engineering roles with a tiny bit of experience working full stack from coding bootcamp. However, I decided to challenge myself by refreshing my memory of Python. In fact, the very first iteration of Clear Bench was actually written in Flask during the height of the COVID-19 pandemic!

Python is used in scientific computing so maybe in the future I can add in some of its other libraries such as NumPy and Pandas. However, I chose FastAPI specifically because of:

It is extremely developer friendly and there is type hinting and validation with Pydantic. Going back to Typescript, this really appealed to me.
Automatic API docs. This probably is a result of my scientific background, but I love when there is documentation, and as a developer having documentation when it comes to how to use an API is like a gold mine.

Side Project Blog: Clear Bench - Tech stack and Backstory

Kathleen Bongco — Tue, 05 Aug 2025 15:34:04 +0000

So I've been out on the job market for a while since 2023. During this time a lot of things have happened in my personal life which had me stop being a developer for about a year, at least until July 2024. But of course life tends to pull you in different directions, and I continued to code but other things pulled me away for a bit and after competing in my biggest competition in powerlifting, I told my coach I wanted to "swing the pendulum back" and find balance between being an athlete and being a software engineer again.

So the questions popped up that I asked:

Did you drop off the samples in the appropriate chambers?
Did you submit the paperwork that goes along with this so we can take it down + see the estimated dates for testing?
Did you upload the sheet onto the shared drive for us to use?
Did you place the paperwork into the folder to be tested?

The answer to the first question was yes. However, the answer to the questions for the last 3 questions was a big fat no.

This is one of the few stories that stood out to me during my time as a laboratory technician which made me ask the question of:

"How can i make this process more efficient and more accountable for all parties and not just the lab techs?"

I've actually gone through several iterations of this project but I've only officially came up with a specific name for it. (Thanks ChatGPT).

Clear Bench aims to:

replace ad-hoc systems with a structured, digital sample submission
ensure all users have visibility into sample status
reduce finger pointing by making workflows transparent.

So let's talk Tech stack and why I went with what I went with:

🧠 Frontend: React (Vite, TypeScript, Zustand)

Vite, I discovered vite pretty early on and I loved how fast it was when it was scaffolding my projects vs CRA (create-react-app)
Typescript, I used to joke that Typescript was Javascript with extra steps, and I did not really like the type safety. However, the more I worked with it the more I realized how useful it was with helping me catch bugs early on.
Zustand, while I have experience using Redux in my previous roles. I did not like the amount of boiler code that came along with it. For all intents and purposes since this is a "small" project for now, I wanted to go with something more "lightweight".

🔧 Backend: FastAPI (Python)

Python is used in scientific computing so maybe in the future I can add in some of its other libraries such as NumPy and Pandas. However, I chose FastAPI specifically because of:

It is extremely developer friendly and there is type hinting and validation with Pydantic. Going back to Typescript, this really appealed to me.
Automatic API docs. This probably is a result of my scientific background, but I love when there is documentation, and as a developer having documentation when it comes to how to use an API is like a gold mine.
It’s designed for performance and async support, which gives me room to grow this into a more scalable service.

🛢️ Database: SQLite (for now)

Right now I'm just using SQLite for development because its easy to spin up without additional set up. I'm already starting to work on the ERD, and I can already see how I will eventually migrate to PostgreSQL for the more complex relationships between the tables.

Hosting and Deployment

So the most I've really done with this previously was using netlify. I am currently investigating other such as Firebase for the front end and Render for the backend. However, I'm currently taking a course on boot.dev to learn more about CD/CI and Docker!

So yeah, this is my project "Clear Bench" I'm planning on writing more about this as a way to lay out my thoughts, show off my thought process, etc.

If you are interested in seeing the repo for this project the link is right here

Side Project Blog: Clear Bench - Tech stack and Backstory

Kathleen Bongco — Tue, 05 Aug 2025 15:34:04 +0000

So the questions popped up that I asked:

Did you drop off the samples in the appropriate chambers?
Did you submit the paperwork that goes along with this so we can take it down + see the estimated dates for testing?
Did you upload the sheet onto the shared drive for us to use?
Did you place the paperwork into the folder to be tested?

The answer to the first question was yes. However, the answer to the questions for the last 3 questions was a big fat no.

This is one of the few stories that stood out to me during my time as a laboratory technician which made me ask the question of:

"How can i make this process more efficient and more accountable for all parties and not just the lab techs?"

I've actually gone through several iterations of this project but I've only officially came up with a specific name for it. (Thanks ChatGPT).

Clear Bench aims to:

replace ad-hoc systems with a structured, digital sample submission
ensure all users have visibility into sample status
reduce finger pointing by making workflows transparent.

So let's talk Tech stack and why I went with what I went with:

🧠 Frontend: React (Vite, TypeScript, Zustand)

Vite, I discovered vite pretty early on and I loved how fast it was when it was scaffolding my projects vs CRA (create-react-app)
Typescript, I used to joke that Typescript was Javascript with extra steps, and I did not really like the type safety. However, the more I worked with it the more I realized how useful it was with helping me catch bugs early on.
Zustand, while I have experience using Redux in my previous roles. I did not like the amount of boiler code that came along with it. For all intents and purposes since this is a "small" project for now, I wanted to go with something more "lightweight".

🔧 Backend: FastAPI (Python)

Python is used in scientific computing so maybe in the future I can add in some of its other libraries such as NumPy and Pandas. However, I chose FastAPI specifically because of:

It is extremely developer friendly and there is type hinting and validation with Pydantic. Going back to Typescript, this really appealed to me.
Automatic API docs. This probably is a result of my scientific background, but I love when there is documentation, and as a developer having documentation when it comes to how to use an API is like a gold mine.
It’s designed for performance and async support, which gives me room to grow this into a more scalable service.

🛢️ Database: SQLite (for now)

Hosting and Deployment

So the most I've really done with this previously was using netlify. However, I'm currently taking a course on boot.dev to learn more about CD/CI and Docker!

So yeah, this is my project "Clear Bench" I'm planning on writing more about this as a way to lay out my thoughts, show off my thought process, etc.

If you are interested in seeing the repo for this project the link is right here

Things I learned during 12 weeks of Coding Bootcamp

Kathleen Bongco — Thu, 15 Oct 2020 00:55:30 +0000

So as of the end of September, I completed General Assembly's Software Engineering Immersive and have been released into the metaphorical pool in the deep end, where my classmates and I can either:

-Sink and go back to whatever industry we were all in , so in my case it would be go back to the food industry and accept that I'll probably forever be a lab monkey
-Swim to the other side and make it as a software engineer.

Needless to say, I'll be swimming like crazy to the other side. But the pool is an Olympic sized pool and I'm not that very good of a swimmer, or I at least don't give myself enough credit. Not gonna lie, since I graduated I've had a couple of sinking moments, since then but I've managed to pick myself back up and continue swimming.

There were a couple of things that stood out to me from attending SEI, but here were the things that stood out to me.

Don't Compare Yourself to Others, only compare yourself to who you were then

Prior to attending SEI, this was something I struggled hard with. My cohort had a wide variety of people coming in to make a career change into software engineering. We had someone who was already well versed in Python and working in data, several people who worked in the restaurant industry, a bio major turned teacher, someone who worked in event planning, someone who was a senior in marketing, and even a couple of stage actors and such.

Unit 1 once we got past the basics of learning Javascript, learning axios calls and all of that went over my head badly. I struggled trying to understand a forEach loop, and in fact that night I ended up triggering an infinite loop with my forEach loop. When we got to Unit 2 which was React, and higher order functions such as .map, .filter, .reduce and props it didn't stick with me until unit 4, and learning Ruby in unit4 was kinda weird to me. Meanwhile, some of my classmates would be done with their hw for the night and I would have to be in TA hours getting help from our TA.

When it came to project week, more often than not I felt like my projects were not as up to par compared to some of my classmates. My first project was a disaster with styling compared to other peoples' projects, but by Unit 4 with my final project the styling improved. While my portfolio projects are not as complex as other, it does showcase what I love and who I am, and I often tell people I love to code because its a way for me to show who I am and what I love. So isn't that enough?

What I definitely learned was, its similar to my philosophy when I lift in the gym, you compare yourself to who you were yesterday. Prior to attending GA I had no idea about flexbox and grid, I dabbled in React and couldn't comprehend what was going on, and couldn't grasp the concept of Big O notation. Now, I can confidently say I know Big O notation and can probably confidently teach it to someone as well as explain the data structures pretty well, as well as my styling skills imprved my a lot.

You gotta come out of your shell and interact/talk to people

(Not my meme, I got this off of reddit, you can find this here: https://www.reddit.com/r/memes/comments/9ujsfo/group_project/ ))
The previous industry I worked in was very independent/not very collaborative. I worked as a laboratory technician in the food industry, and needless to say the environment between working in a lab vs working as a software engineer is night and day. For one, lab work was very much a one-man thing and its kinda perfect for someone who is extremely introverted such as myself, from my personal experience while I was in a team working in the food industry it was very much a one-man thing, and collaboration was not encouraged as much as it is in the tech.

That being said, I really enjoyed the collaboration aspect that I experienced during coding bootcamp. We were often thrown into breakout rooms on Zoom where we would discuss and work through whatever exercise we were doing for the morning/afternoon, and on top of that for someone as introverted as me it got me talking to people in my class and asking for help when I didn't understand what the hell was going on, and I also made a bunch of friends too!

Also, as a bootcamp graduate, this applies to me 100%. Networking is one of the most terrifying things in the job hunt right now, and reaching out to people is definitely one of the things I am struggling to do. The unfortunate truth is as I've learned from everything I've read online that most jobs are found via networking and during this era of COVID, meetups are not exactly a thing right now so it comes down to messaging friends and friends of friends on linkedin which is very daunting.

Compared to how I was pre-SEI, I was not as confident reaching out to people, but after graduating I'm confident enough to reach out to people, but not as confident? (If that makes any sense)

ABC - "Always be Coding"

So practicing coding and making things is very similar to training at the gym. I'm a competitive powerlifter who's going to be competing at her first sanctioned meet this year, and before COVID became a big thing over here, I was 4 weeks out to a charity meet. Once the gyms shut down where I'm at, it was a good few months before the gyms opened up again, and once it did reopen, I hit the 3 big lifts (Squat, Bench, and Deadlift) to find that I couldn't remember the cues in order to lift properly and hit the big PRs. However, when I started getting a consistent schedule again training, muscle memory kicked in and I remember (most) of the cues now.

This is kinda similar to coding. I started this career change journey over 5 years ago after my first position ended. Only for me to give up on it as I thought I found my dream position in the food industry, but the enthusiasm I had for learning to code was still there. So I would stop, then re-learn how to code, stop, then re-learn how to code again. It didn't really sink in on how similar practicing coding was very similar to the gym until we got advice from our TA during the React unit, which was:

"You gotta practice and build dumb shit with code"

Similar to working out and gaining muscle, it can be applied to code as well, use it or lose it! This didn't really sink in until towards the very end of the course, I wanted to go back to my Python-ic roots and practice some Python only to find in horror that the only thing I can confidently say that I remember was:

print('Hello world!')

I couldn't remember the basic syntax of Python, until I started practicing it again alongside me practicing JS. So following the advice of one of my TAs in the course, I'm building a bunch of stupid/yet fun apps that show off who I am and things that I love.

To make sure I still remember axios calls and DOM manipulation, I built a mini app called "On this Day" which shows historical events that took place on the day of, to remember React and how to use Mapbox-GL, I'm working on a mini app to find powerlifting/weightlifting friendly gyms. That's just a bunch of weird examples of things that I'm doing to help me remember what I've learned in the course to make sure I don't lose that "coding muscle memory" ;)

You don't stop learning

As software engineers, we're in an industry that is constantly changing. Take for example, we know React is the number 1 front-end framework right now, but in the future Vue.js can end up taking that over. In this industry, we gotta keep up and keep learning.

Let's be real here, when you attend a coding bootcamp, you are fed a lot of information in the span of 12 weeks some which you end up retaining, others you have to go back and re-teach yourself because you don't remember what you've learned. Most topics you learn give you the brief overview of whatever topic you are going over.

That being said, its been almost a month since I graduated, I ended up teaching myself/reviewing data structures and algos as well as learning more hooks in React that we didn't cover. Our instructors of the course also told us to consider looking into/learning AWS since we don't really have time to cover it in the course and stuff.

Wow, this entry was a lot longer than I thought it was going to be, but these were 3 life lessons, (I guess?) I learned while at coding bootcamp.

Anyway, if you enjoyed this entry, sorry I rambled a bit, be sure to follow me and I'll also be migrating some of my previous entries that I wrote on medium to dev.to!