Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

"We ran out of columns"

jimmyhmiller.github.io

Post reply on HN
Print view View original

231–240 of 588 posts

Re: "We ran out of columns"

#231

Post by bdbdhxhdh »

kwhitefoot wrote: post #207
fouronnes3 wrote: post #130

Earlier quoted context omitted.

This is amazing. I can so well imagine a bright young hire joining that team, helpfully offering to "setup this thing called git" only to be laughed out of the meeting by all the "senior" staff.

Some of these stories sound a bit far fetched, especially those that involve Unix systems. RCS was released in 1982 and CVS in 1990 so Unix systems have had version control available for over forty years.

There is a lag between availability and mindshare to apply a technology.

I myself introduced SVN as versioning solution to a company in 2007, years after git was available I and I was aware of it

git simply didn't have the mind share jet, thus I went with what I knew

Re: "We ran out of columns"

#232

Post by cruffle_duffle »

kwhitefoot wrote: post #207
fouronnes3 wrote: post #130

Earlier quoted context omitted.

This is amazing. I can so well imagine a bright young hire joining that team, helpfully offering to "setup this thing called git" only to be laughed out of the meeting by all the "senior" staff.

Some of these stories sound a bit far fetched, especially those that involve Unix systems. RCS was released in 1982 and CVS in 1990 so Unix systems have had version control available for over forty years.

I can assure you they are true. Version control was still “controversial” in a lot of shops for quite some time. Plenty of places had the classic “v1, v2.3, v2_next_debug_cruffle_duffle” way of managing versions for a very, very long time.

Well into the subversion era…

Re: "We ran out of columns"

#233

Post by bdbdhxhdh »

thayne wrote: post #217
hleszek wrote: post #126

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.

wow this is just evil

I want an obfuscator doing such a transformation:D

Re: "We ran out of columns"

#234

Post by bdcravens »

alt227 wrote: post #180
bdcravens wrote: post #87

A couple of weeks ago I had a flat on the way to the airport. It was a total blowout, and my car doesn't include a spare. We were already over budget on our trip, so I had the car towed to the closest tire shop and had them put on the cheapest tire that could get me to the airport. I know I'll need to replace other tires, as it's an AWD, and I know it's not a tire I really want. I made a calculated choice to make tha…

Aside - the fact that cars dont include spares these days is infuriating. IMO its a classic example of real world enshittification

Supposedly there are reasons (for example, efficiency by avoiding the extra weight) and they give you a kit that's essentially a "fix a flat" product, but in the 2 times I've had a flat in a car outfitted like this, what they provided wasn't useful, usually due to the type of damage to the tire.

Re: "We ran out of columns"

#235

Post by collinmanderson »

omoikane wrote: post #102

This codebase sounds like a haunted graveyard[1], where everyone just fixes their local corner of things and avoid the risk of untangling the existing mess. Not needing to conform to some company-wide standard is probably really pleasant while it lasted, but every such effort adds to the haunted graveyard, and the lack of consistency will eventually come back to bite whoever is still around. [1] https://www.usenix.or…

It could maybe work if every team is responsible for their own area of the code base, where the code base starts to match the company tree

Re: "We ran out of columns"

#236

Post by ufmace »

fiddlerwoaroof wrote: post #151
ufmace wrote: post #139

Earlier quoted context omitted.

I think a lot of people who've only learned programming in the last 10 years or so don't realize that Git, and even more so the large-scale popularity of Git, is actually pretty new. A lot of programming happened before Git was created, and before it became mature and popular enough to be the default for everyone. Many of these earlier systems sound terrible and hacky to us, but they were the best that was available…

I use CVS, RCS and Subversion on my personal projects for several years before I learned git. I don’t remember any of them being a pain to setup for small projects and Sourceforge provided free CVS hosting for small projects.

I've never actually set up CVS myself, so I suppose I can't accurately say how easy or not easy it is. The "nobody" might deserve an asterisk - I'm sure it's not literally not a single person, but it seems to be pretty rare in my impression. Nevertheless, AFAIK, the non-distributed nature seems pretty limiting.

In Git, I can just create a local repo for anything, and I don't have to decide where I want it. I could never push it anywhere, or push it to a private hosted repo to collaborate with a person or team, or push it to a public repo to open-source it, and change between any of those at any time. I don't think you can really do that with these hosted systems. You could spin up a local CVS server if you really wanted to, but if you later decided you wanted to open-source it on Sourceforge, don't you have to abandon the history and publish it there as-is?

Re: "We ran out of columns"

#237

Post by grishka »

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 manually too: https://github.com/DrKLO/Telegram/blob/master/TMessagesProj/...

I even had the permission from the main developer to refactor some of it, but I never got around to actually doing it.

It's a miracle this app works at all.

Re: "We ran out of columns"

#238

Post by lemme_tell_ya »

mleo wrote: post #155
lemme_tell_ya wrote: post #83

My first day at my first full-time programming gig, I was asked to look at some reporting job that had been failing to run for months. I logged in, found the error logs, found that it needed a bit more memory assigned to the script (just a tweak in the php.ini) and let the team lead know it should run fine that night. He was shocked, "Dude, if you just fixed that report you probably just got a promotion, no one has b…

I know things have gotten somewhat better, but the amount of wasted time and latency of using RDP and Windows UI for development, testing and production maintenance is insane. Throw in some security requirements of RDP into host 1 to the RDP jump to host 2 and companies are just wasting money on latency. There is, often, not an appreciation of the administrative costs of the delivery. Not necessarily system admin cos…

Oh yeah, been there. I personally find Windows to be a terrible server OS. I'd rather be stuck with a fleet of AIX machines or something equally uncommon (but still nix-ish) than any Windows system.

Re: "We ran out of columns"

#239

Post by capitainenemo »

llmblockchain wrote: post #160
fouronnes3 wrote: post #130

Earlier quoted context omitted.

This is amazing. I can so well imagine a bright young hire joining that team, helpfully offering to "setup this thing called git" only to be laughed out of the meeting by all the "senior" staff.

I've been that person a few times. 1. The only developer on the team with Github and put forward the idea of the company not hosting their own source code with TFS. 2. The only developer using branches with git when the co-founder asked (demanded) everyone to only use master. The list goes on!

Given the various accidental leaks dues to people not realising deletion still has a history with git when publishing (not to mention git has no equivalent to mercurial's "censor" operation), or people confusing public and private repos on their github accounts, or even the story just last week here on HN with counterintuitive behaviour of forking in terms of privacy (https://news.ycombinator.com/item?id=41060102), I can totally understand a company being opposed to being on github.

Perhaps you should have proposed anything-but-TFS (git/mercurial/even svn - no need for distributed in a small company... https://www.bitquabit.com/post/unorthodocs-abandon-your-dvcs...) but internal.

Might be a relatively easy sell if you just setup a local migration of their data to repository with a decent web gui for viewing the commits and associating with tickets, given my experiences with TFS in terms of slowness, and crashes/data corruption.

Re: "We ran out of columns"

#240

Post by teaearlgraycold »

RaftPeople wrote: post #89
teaearlgraycold wrote: post #20

Earlier quoted context omitted.

Byte vs. Int is premature optimization. But indexing, primary keys, join tables, normalization vs. denormalization, etc. are all important.

> Byte vs. Int is premature optimization I think you can only judge that by knowing the context, like the domain and the experience of the designer/dev within that domain. I looked at a DB once and thought "why are you spending effort to create these datatypes that use less storage, I'm used to just using an int and moving on." Then I looked at the volumes of transactions they were dealing with and I understood why.

Absolutely
Post reply on HN