Live data from Hacker News

"We ran out of columns"

jimmyhmiller.github.io

251–260 of 588 posts

Re: "We ran out of columns"

#251

When I started at my first company, they had a very complex VB application running on dozens of customers around the country, each having some particular needs of course. There was a LOT of global variables (seemingly random 4 uppercase letters) controlling everything. At some point, the application had some bugs which were not appearing when the application was run in debug mode in Visual Studio. The solution was ob…

My first role was with a company who had hit a limit for VB6 variable names iirc. So they'd all been renamed to shorter names. This may be the same issue. They were in the process of rewriting in VB.net.

Re: "We ran out of columns"

#252

It's hard for those who came into the discipline in the past twenty years to realize just how much things have changed around version control and building. Joel Spolsky released the "Joel Test" for determining if the software team you were interviewing had good practices in 2000 . One of the requirements was that they used version control. Not all that many teams actually did. Especially during the dotcom craze. Toda…

This reminds me of my first software job, an internship in college in 2012 building an application from scratch to facilitate evaluating teachers. It was basically an app to allow people to create a form for their school’s evaluation criteria and then submit those forms. Sounds super straightforward, right? It was. The catch was our team was 2 CS undergrad, a masters CS student, and a high school student. All with no professional experience. We knew nothing. Well kind of but more on that in a second. Our manager was absolutely non technical. In fact they were the second highest person in the company (fairly small company) and were managing our project and a bunch of other stuff at the company. And somehow with almost 0 oversight we built a functional Django application that the business was able to sell and make money from. My favorite highlights were 1) the codebase was initially shared over FTP (“Hey you’re not editing file X, right? Oh you are? Ah woops I just overwrote all your changes.”) till someone intelligently suggested “Uhhh Git?” 2) the actual best programmer amongst us was the high schooler. They suggested Django, picked the DB, they suggested using Celery to speed up async work, Redis for caching, and yes, “Uhh Git?” In retrospect the only reason we succeeded was because of them. They were like top 5 on the stack overflow Code Golf site IIRC. 3) My interview was basically showing my aforementioned manager who had never coded in his life a project I worked on at school and him being like “Yeah looks good. You’re hired.”

With 10 years of hindsight, I cringe thinking back to all the bad decisions I pushed for and the no-doubt terrible code I wrote. But I also marvel and look back fondly at being given a shot and being in an environment where I could just build something from the ground up and learn everything soup to nuts on the job. God bless whoever inherited that codebase.

Re: "We ran out of columns"

#253

The worst codebase I've ever worked on was the Telegram client for Android. I mean just look at this file, it's so huge GitHub gives up rendering it: https://github.com/DrKLO/Telegram/blob/master/TMessagesProj/... Or this one, it implements EVERYTHING for rendering and interacting with a message in a single class, all non-service message types, all drawn manually on a canvas "for performance", and all input processed…

It’s even more crazy because Telegram is by far the smoothest messenger app on Android.

BTW, would you mind sharing how you got that job?

Re: "We ran out of columns"

#254

When I started at my first company, they had a very complex VB application running on dozens of customers around the country, each having some particular needs of course. There was a LOT of global variables (seemingly random 4 uppercase letters) controlling everything. At some point, the application had some bugs which were not appearing when the application was run in debug mode in Visual Studio. The solution was ob…

> with some still having bugs fixed years before for others

Hopefully they won't discover at some point that customers were in fact depending on those bugs. That's poison for the programmer's soul.

Re: "We ran out of columns"

#255
post #217

When I started at my first company, they had a very complex VB application running on dozens of customers around the country, each having some particular needs of course. There was a LOT of global variables (seemingly random 4 uppercase letters) controlling everything. At some point, the application had some bugs which were not appearing when the application was run in debug mode in Visual Studio. The solution was ob…

> There was a LOT of global variables (seemingly random 4 uppercase letters) controlling everything. I once ran across a (c) program that had 26 variables, each one letter long, one for each letter of the alphabet. They were all global variables. And many of them were re-used for completely unrelated things.

Ah, the "user-defined registers" paradigm.

Re: "We ran out of columns"

#256

When I started at my first company, they had a very complex VB application running on dozens of customers around the country, each having some particular needs of course. There was a LOT of global variables (seemingly random 4 uppercase letters) controlling everything. At some point, the application had some bugs which were not appearing when the application was run in debug mode in Visual Studio. The solution was ob…

There is "do things that don't scale" and the there is bending over backward to do things in the dumbest possible way. Not sure where this lands.

Re: "We ran out of columns"

#257

My worst codebase story: In my first real job, I worked for a company that maintained a large legacy product programmed in a combination of COBOL and Java. In order to work on the Java side of the product, you checked out individual files from source control to work on, which 'locked' the files and prevented other developers from checking out the same files. This functionality was not part of our actual source contro…

> It took a small team two years to migrate the entire codebase to git with proper CI

I'm amazed they even allowed people to spend company time and money doing this. Corporations tend to not see the value in improving such precarious situations as long as the software keeps working. They just want employees to cope and accept the messiness. People usually cope by quitting.

Re: "We ran out of columns"

#258

The worst codebase I've ever worked on was the Telegram client for Android. I mean just look at this file, it's so huge GitHub gives up rendering it: https://github.com/DrKLO/Telegram/blob/master/TMessagesProj/... Or this one, it implements EVERYTHING for rendering and interacting with a message in a single class, all non-service message types, all drawn manually on a canvas "for performance", and all input processed…

Telegram happens to be one of the smoothest app experiences on Android, both in terms of perf and UX, so they must be doing something right.

Re: "We ran out of columns"

#260

Earlier quoted context omitted.

In my current company, we're using a similar approach: just shove everything into a JSON blob. If you need a constraint or an index, you can create a computed column (in PostgreSQL) that pulls out a field from JSON. For the data schema, we're using Protobufs with buf validate. This works surprisingly well, you can use the same types in the backend API and on the frontend. We even have a cron job that reads all the da…

Do you go to the trouble of updating individual values in objects using some kind of deep/partial updating function or do you just accept race conditions that come with updating full objects?

A lot of databases include functions for manipulating JSON which can be used for atomic updates. SQLite has JSON_PATCH(), for instance.
Post reply on HN