Category Archives: Working in Tech

A Rant About Startup Growth

Leave a reply

A bit of background

I very recently began working at a software development company that has grown very, very fast. Its profits have grown tremendously, its employee count has grown, its project count has grown, and even the amount of buildings it owns has grown. From the outsiders perspective, this is a great thing. When talking to those that are in charge of the business side of things (sales, management, hiring, etc..), everything is going just as according to plan; however, the tech side of the company definitely has a different story to tell. The company has grown so rapidly, in fact, that the technology and routines of the company cannot keep up with the ever-changing environment that the company lives in.

A Quick Example

Take, for instance, version control. This is probably my biggest gripe about how the company operates. The company consists of many, many teams doing many, many different things. None of these teams can agree on a single method of version control. Each team does something different with their own little twist. Many teams use an internal clone of GitHub, Many others use Perforce. This doesn’t seem so bad at first, however, with each side of version control comes its own integration of code review, submittal processes, and checkin/checkout procedures. There have been several occasions where I needed to grab code from another team that was in GitHub and attempt to sync it with my code that is stored in Perforce. It’s a logistical nightmare.

It doesn’t stop there, though. Each method of version control has its own story. I won’t go too far in depth, but let’s just say that the goal of the company was once something along the lines of “We need to push code that works“. Now, the company is leaning more towards a philosophy of “We need to push code that works and is efficient, modular, and understandable“. This makes fixing bugs on older products or adding features to older products a logistical nightmare.

A Resolution?

One of the problems that I have found with Perforce is that its local repository management is more than complicated. There have been several times where I quickly want to branch a directory full of code so that I can play around with a  possible new feature, but be able to quickly switch back to the main devline of code. With Perforce, this is much more complicated than a simple git checkout -b feature.

So, in order to solve this problem, I have resorted to keeping all of my copies of the company’s source code within my own local git repositories. I then sync all of the Perforce checkouts into a branch and then merge that branch into all of my feature branches, resolving all conflicts along the way.

The Message

Although this post seems to have gone nowhere at all and made no constructive points whatsoever (that was definitely not the purpose of the post), it did point out something that I never expected. The internal infrastructure of large companies can be a serious mess. This being my first position at a large software development company, I honestly did not expect things to be as messy as my code directory on my home computer. But it’s also much, much worse. I believe that the problem arose from the fact that the company simply expanded very, very fast and that the internal tech employees were unable to adapt to newer tools quickly enough.

What does this mean? It means that now developers are stuck at a crossroads of bad naming conventions and commented-out blocks of code. They’re forced to use project-specific version control and they’re constantly deciding on which of the hundreds of branches they should push their code to.

Honestly, in situations like this, I think it is best for the company to stop working on new features for a small while, and fix their current infrastructure disaster.

Working From Home

Leave a reply

I worked from home for the first time today.

It was actually just because I woke up late, and even then, I had a very, very bad headache. I rolled out of bed, hopped in the shower for 10 minutes, made myself a hot cup of coffee, roamed around in my underwear, and sat down with three toaster waffles and syrup for breakfast. I finished my breakfast within 5 minutes, pulled out my work laptop, and logged on.

It was weird working for home — seeing everyone on GChat who is at the office, where you’re supposed to be, doing things that you’re supposed to be doing. There is an overwhelming sense of guilt. I needed to get something done and fast. I opened up my code and made some changes. All was well. I just had to compile.

Normally, at the office, during compile time I sit around waiting for a good 30 minutes while the entirety of the company’s codebase combines into single executables. I usually just listen to music, read documentation, or tap my fingers. At home, though, it was a whole new experience.

I started the compile, got up, did dishes, made my bed, cleaned the table, got myself another cup of coffee, and then began reading tech news. There was no overwhelming sense of “You should be doing something corporate related”. I chatted with friends, read some documentation, and experimented a little with tools I’ve never used. It was the most fun I’ve had working in a while.

Why? All because it was from home. Granted, as the day went on, I continued this trend, and I think I ended up being a little less productive than I would have normally been because of this. However, I was able to truly get absorbed in my work since there was no pressure to get stuff done. It was a great feeling.

I always thought that working from home sounded like a bad idea. You would get distracted and wouldn’t get much done. My experience was completely different. Although I did get distracted, I got more done around the house than I would have ever gotten done if I was at the office. On top of this, my extra long lunch break was rewarding and delicious. Things just went well.

The only problem with working from home is, well, the fact that you’re at home. I got several requests from coworkers to go to certain locations within the office building to meet or look at something. The problem was that I wasn’t there. It is always a bad thing to tell your coworkers “Sorry! How about tomorrow”, and that was the worst part about working from home.

 

All in all though, it was a great experience. I would highly recommend it atleast once to anyone whose job does not involve a necessary physical presence at the office.