I’m going to write a series of posts to record my observations of how to do things at my last few jobs as software engineer. I hope writing these will help me find the things that I did right or wrong, compare the pros and cons of different ways of doing things and apply what I learned better for the future. Even though I might not find anything to learn about, it’s always a fun thing to look back and write things down when I can still remember:)

Let’s go back to 2018 when I joined a prop-tech startup focusing on building a better platform for renters and landlords. I was hired as a full-stack engineer. The tech stack is React + Golang, both of which were new to me back then and I was eager to learn. It was also my first job in the web development industry; prior to that I mainly worked on developing single machine applications using C++. The company had 3-4 full-time software engineers during my stay and I became the most senior (except our CTO who only occasionally help) engineer leading other junior developers after a few months into the role.

I can’t recall 100% but here are some facts that should be mostly correct:

  • We use Sprints to plan and execute our feature releases. We use clubhouse.io to do project management.
  • We use Github to host our code and use circleci for CI.
  • We use AWS EC2. For deployment, someone would build it locally, uploaded it, killed the old version and start the new one.
  • For the backend, we have some mock unit tests and integration tests for DAO layer. For frontend, I remember we have limited unit tests using JEST and integration tests using Intern. One contractor also looked at using cypress but it wasn’t adopted.
  • We use GSuite and Slack for internal communication
  • We use Postgres as database

A typical development cycle is a 2-3 week sprint, starting with the CTO leading a sprint planning session. He first closed the previous sprint, carried over items that were not finished or need follow up and then pulled in new requirements into the new sprint. There were new features every sprint and development load was quite high to a small and young team like us. I remember one Friday night our CTO, myself and another developer worked until 2am just to release a feature that we want to be online by the next Saturday, which is typically the busiest day for renters and agents. I was single back then so it was not that a bad for staying late but one of our female colleagues, who was a mom of two, couldn’t stand this and quit after about 6 months.

Although I was the senior in the team but frankly speaking many times I was clueless as others. I was senior only because I was older and had more years of working experience; it wasn’t because I was more experienced as a full-stack developer or know more about this domain. That means I had to learn as I go and sometimes pretend that I know I was doing the right thing. This gave me a false sense of entitlement. It gradually made me believe that I was genuinely a senior developer. I remember in an interview for my next job I was asking questions about career progression as a senior engineer, the interviewer (I mean you Steve) bluntly told me that “You’re not a senior engineer”. I was shocked as well as felt embarrassed by my own stupidity. He was right. I was far from being a senior back then. I wasn’t qualified technically nor did I understand the business good enough nor did I have the mindset of a senior whom can be entrusted by the leadership to do long term planning (for the startup 6 months is long term)

In terms of development work, since every one was under pressure, we usually ignore automated tests, especially the frontend. For backend, I remember I was the main person responsible for it and since I didn’t have much confidence with my code I would write mocked unit tests and DAO layer integration tests (the magic of GORM kinda of force me to write tests to validate my understanding) before manual testing. We do code reviews but they’re usually “fast-tracked” when we were doing hot fixes or close to deadlines. Except a few occasions, I don’t remember myself trying to enforce a certain standard or convention in the code base - I wasn’t that much experienced myself after all. This means I didn’t many have many clashes with my colleagues at work (at least I couldn’t remember). It was in stark contrast to my last job. Of course, working under constant deadlines does help reducing the chance of clashes - if you have deadlines to meet then standard is a secondary concern. And the fact that I was the oldest engineer by a mile also helps - all the developers include myself have the same culture background and our culture notoriously value respecting the seniors as high merit.

So that was it. I plan to write a post to compare 4 jobs in the past 6 years but ended up only writing the first one and still feeling I have more to say. But I really need to go so maybe next time.