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

331–340 of 588 posts

Re: "We ran out of columns"

#331

Post by nvy »

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.

At least as late as 1998, I recall version control was thought of in some circles the way people think of C vs memory-safe languages today.

Some thought version control was an obvious improvement to make better, more bug-free software. Others had a fetish for doing things the hard way with little justification beyond emotional resistance.

Re: "We ran out of columns"

#332

Post by makmanalp »

Aeolun wrote: post #322
makmanalp wrote: post #304

Earlier quoted context omitted.

As much as this stuff is nuts to think of today and there's tons to hate, I am kinda nostalgic for some aspects of my experience of working at a place where software is maybe needed and/or valued but isn't a core competency. Or maybe a time when software was a new fangled thing that hadn't fully been integrated into corporate structure yet: - No one having any preconception of how you're /supposed to/ do things or wh…

Don’t think so. My first job was kind of like that. I don’t even know how they thought that little old me just out of university could be left alone to successfully build applications on my own, but I think people trusted a lot more during that era because eternal september hadn’t arrived yet. Working directly for the users without any weird BA/PM/TA shit in between is glorious, both because you can always walk up to…

> I don’t even know how they thought that little old me just out of university could be left alone to successfully build applications on my own, but I think people trusted a lot more during that era

A similar feeling on my end too :-) That might be it - trust sounds like a big part of it for me. Taking a chance on someone who you might eventually end up being good, rather than interviewing and evaluating them 7 ways till sunday. I understand the impulse. I wouldn't want to be a new engineer out of college today though - seems rough.

I did get paid less then than some new grads seem to be now so that might have been a factor in taking the pressure off.

> because you can always walk up to get immediate feedback (people generally like to see you are actively working on their issue)

Oh absolutely!

> It still amuses me that IT was located together with finance, because we did reports xD

It was communications for me, because the software tool we built was free to use on the web, and websites are communications, obviously :D

Re: "We ran out of columns"

#333

Post by eichin »

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.

SCCS was released in 1977 and it hasn't even turned up in these comments at all. "Not evenly distributed". (I introduced RCS as a replacement for "just editing files" at a job in 1990; "there's a man page and some binaries on the system" really doesn't contribute to adoption. CVS at least propagated through things like USENIX, because solbourne made cool toys and talked about the challenges.)

Re: "We ran out of columns"

#334

Post by treflop »

bsder wrote: post #277
mewpmewp2 wrote: post #271

Earlier quoted context omitted.

Why is it astonishingly? Git is not a natural development at all. Obviously, it is a standard right now. But I as a hobby coder at my teens I started out with FileZilla and copying over index2.php, index3.php, index_final.php, index_final_2.php and all of it worked well enough when at that point. I took a little break from that hobby, and it still took me a lot of time to build intuition around Git when I started out…

> Git is not a natural development at all. Obviously, it is a standard right now. Git is actually an unnatural development. Its UI is atrocious. And it worked like crap on Windows for forever. Over time, I taught non-computer people who used Windows all of CVS, Subversion, and Mercurial. They got each one and why things were better. The first time they had to recover something, they really got it. Source control got…

GitHub won because it was good.

SourceForge had a messy interface and frankly I hated it. Google Code was like frozen in time, like most Google projects. Microsoft’s thing — I don’t even remember the name — felt half assed and like they were going to abandon it… and they abandoned it. There were also others… none of which I even think were serious enough.

Also Git won because SVN and CVS were centralized VCSes and you needed a server. I can just make Git repos before I even know if a project is serious.

There were other distributed VCSes of course, like Hg, but they either cost $ or wasn’t backed by a major user… like Linux. I admittedly just waited this one out and chose Git because it was more popular.

Re: "We ran out of columns"

#335

Post by Aeolun »

grishka wrote: post #282
bartekpacia wrote: post #253

Earlier quoted context omitted.

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?

> BTW, would you mind sharing how you got that job? I started working with Pavel Durov in 2011 on the VKontakte Android app, after winning several of his developer contests, and it all just went from there. I was the last one of the "old" team to transfer to Telegram. My main job was actually the libtgvoip[1] library and its integration into the Android app (the other platforms were done by their corresponding devs).…

> He got furious when he was unable to call some journalist, cursed at me in front of the entire team and sent me a termination notice.

Honestly does not sound like a very healthy person to work for anyway.

Re: "We ran out of columns"

#336

Post by Aeolun »

failbuffer wrote: post #220
agentultra wrote: post #132

The ending is pure gold. Some of the best times in my career were working on a codebase for an application serving folks I knew on a first name basis and had had lunch with. I could talk through pain points they were having, we’d come up with a solution together, I’d hack up a quick prototype and launch it just to them to try out. We’d tweak it over a couple of weeks and when it was good I’d launch it to all customer…

... and get them talking directly to the user. I feel that's where the real magic happens.

So many “Oh, I just didn’t ask because I thought it would take months” saved!

Re: "We ran out of columns"

#337

Post by treflop »

mewpmewp2 wrote: post #271
gumby wrote: post #211

Earlier quoted context omitted.

Astonishingly, It took a long time for revision control to become widespread. Around 1991 when Cygnus had 6-7 employees and was based in the apartment complex where I lived, none of the GNU codebase was hosted in any sort of revision control. Everything was FTPed around as obscurely named tarballs. We had gathered something like 27 different forks of gdb floating around the net, for example. This was back when forkin…

Why is it astonishingly? Git is not a natural development at all. Obviously, it is a standard right now. But I as a hobby coder at my teens I started out with FileZilla and copying over index2.php, index3.php, index_final.php, index_final_2.php and all of it worked well enough when at that point. I took a little break from that hobby, and it still took me a lot of time to build intuition around Git when I started out…

I don’t know if I agree that it’s unnatural.

It only takes doing index73.php and index_old3.php for a few months and then eventually screwing up (unless you’re perfect) to realize how dumb putting numbers and _old4 at the end of names is. Then at that point, you naturally go look if there’s a better way.

Re: "We ran out of columns"

#338

Post by akoboldfrying »

paulddraper wrote: post #275
djbusby wrote: post #247

Earlier quoted context omitted.

Yep, that bit me/my teams more than once. But this case we had the commit from CVS showing it was just a fat-finger. But the seniors on the team pointed to CVS. Not the individual, not the "test" process, not the deploy checks. Nobody noticed it slow cause everything ran on LAN. Only noticed the issue on 56k

That's a really fat finger

Assuming a key repeat rate of 15Hz (a number I admittedly just pulled out of thin air), they would have had to lean on the Tab key for almost exactly 1 week.

The guy ate, slept, possibly got married while his finger was still accidentally holding down that key.

Re: "We ran out of columns"

#339

Post by kubectl_h »

cyberax wrote: post #244
kubectl_h wrote: post #226

Earlier quoted context omitted.

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?

We use optimistic versioning, with a dedicated "version" field (that is actually always pulled out of the blob in all tables). Classic fine-grained schemas are not that much different. A lot of high-level ORM frameworks simply save all the objects' fields on update, without doing fine-grained diffs. In addition, our frontend apps also support offline mode. They can get all the relevant objects, and then operate on th…

> We use optimistic versioning, with a dedicated "version" field (that is actually always pulled out of the blob in all tables).

All well and good but you do need to handle failures elegantly in code. The nice thing about flat DB tables and SQL is you don't really have to care if your goal is to update a single column authoritatively. The state of the other values in the table are, often, immaterial. It gets even more complicated reconciling deeply nested conflicts in open schemas.

Not knocking your approach, it's just a trade-off I guess.

Re: "We ran out of columns"

#340

Post by kubectl_h »

duskwuff wrote: post #260
kubectl_h wrote: post #226

Earlier quoted context omitted.

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.

Yeah, makes sense. To write safe code though at that point don't you have to enforce rigid schemas?

An example would be updating Kubernetes resources, the admission controller will verify the correctness of the change you are trying to make and reject the patch if it's non-comformant. Nested values have... value... in terms of contextualizing and isolating/localizing data leaves but at the end of the day aren't you still dealing with strict schemas and, when those schemas change you have to reconcile schema migrations?

Post reply on HN