Live data from Hacker News

"We ran out of columns"

jimmyhmiller.github.io

511–520 of 588 posts

Re: "We ran out of columns"

#511

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…

Dear god this is pretty much what I went through when I started taking over a company with a 35-40 year old codebase. Files spread everywhere, no consensus, and supporting customizations for thousands of customers who we didn’t know if they were even still using the system.

It took five years and the firing of the long-time “head” programmer until some meaningful change was made.

Re: "We ran out of columns"

#512

Earlier quoted context omitted.

> not to mention git has no equivalent to mercurial's "censor" operation Haven't followed that for a while, but it used to be the case that it was Mercurial who was principled/fanatic about never rewriting history, ever , while git happily let you mess up with hard deletes.

Which is still the case. They use the hidden phase to avoid that. You can use hg absorb (also awesome) locally of course to simplify matters. What censor is for is the case where something absolutely has to be removed from the repo, for legal or security. It allows you to do it in a clean standard way, even replacing it with, say, a key signed statement, without forcing regeneration of the whole repository or alterin…

... and gotta say. mercurial will let you do hard deletes. They just discourage it and try to offer tooling that allows you to do what you want without destroying history / changing hashes / generally complicating life for those using the repo.

They also do have the tools to completely rewrite history if you really really want to.

So, "principled fanatic" is not quite accurate I feel. They just have a lot more options than git (which also applies to their commandline tooling I feel, although of course there's a lot of 3rd party stuff out there for git to mimic much of what mercurial has out of the box these days).

Re: "We ran out of columns"

#513
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 set up SVN for myself before Git and IMO Git is definitely easier.

Re: "We ran out of columns"

#514
In my very first programming job, I got hired on right at the end of a major refactor that had been going on for the better part of a year. I was a hacker kid who started programming less than a year prior. My first task at this company was to merge and resolve all conflicts from the refactored branch back into mainline. No one checked what I did. As long as it compiled on my machine and passed the CI test (just one), it got merged and released into production.

Shockingly, this project was notorious for regressions. We were on a weekly(!) update cycle, and we constantly had bugs reappear that had been solved months prior.

This was 2010 or so, and we were using SVN because the project lead didn't trust or understand git. He also didn't understand SVN. The solution to our constant regressions was pretty simple. Instead of merging branches into trunk, we would delete the master branch every week and create a new one out of all of the finished develop branches.

Surprising absolutely nobody apart from that project manager, this plan was a spectacular failure.

He also stole code out of my personal git repos from before I worked there, and bragged about how smart he was for stealing my code. So, y'know, just a general idiot and asshat.

Re: "We ran out of columns"

#515

This made me think of my first job. I was the sole developer on a project because the old developer left. Nothing was documented and nobody knew why things were designed the way they were. We had no code reviews, no design docs, no tests, nothing. We made the changes the way we thought they were right and would git pull them onto the production server. After I struggled to get productive for the first four months, my…

> my manager went on a four-week Christmas vacation. Is that kind of stuff common? People checking out on Black Friday and coming back for New Year's?

In Europe totally, and for example in Germany it's customary to get you six week vacation in the summer.

This also has the benefit that the workplace has to have real back-up person for all matters, as six weeks is too long to shove everything under the carpet waiting for your return.

Re: "We ran out of columns"

#516
post #139

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…

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…

> source control was clunky and a pain in the ass to set up

I concur. Creating a CVS repository was not harder than creating a git repository now `cvs -d $dir init`, and using, typical for the time, shared network drive, gives server experience without setting up a specialized server. It was just not included with Windows/typical Windows dev tools, so you had to know it existed, and knowledge was slower and harder to get.

Re: "We ran out of columns"

#517

Earlier quoted context omitted.

Nice. But I have to ask, considering it was Perl: Could an outsider understand it after you reduced it to 200 lines?

As an outsider of any reasonably large application can you really ever expect to grasp 200 random lines of code in any language? Maintenance programming is all about understanding the software‘s context and implicit design or a model thereof — even if it is a 20 year old patch work. Young developers tend to be amazed when I find the source of an obscure bug in our 1M lines of Perl code application as a senior. But th…

If you get a typically-structured Java/Spring application then often yes. By typically structured I mean domain objects, DTOs, service layer, controller layer, view layer. The idiomatic use of dependency injection frees the mind of the reader from understanding all the dependencies in code, just use an @Autowired class you want and someone part has the knowledge to configure it and does so.

Re: "We ran out of columns"

#518

Earlier quoted context omitted.

Git is pretty unnatural, but CVS? That is much closer to the "copy a shared file back and forth between people", except with nice things such as "keep track of who is editing what", "know what the latest edition is", and "keep track of the history". That said, if I was going to start out teaching someone coding today, version control would be timestamped .zip files.

>That said, if I was going to start out teaching someone coding today, version control would be timestamped .zip files. Oh no, we're in a different time zone. >We'll put the timezone in. Oh no, it's daylight savings time.

But someone works in Arizona!

Re: "We ran out of columns"

#519

Earlier quoted context omitted.

why a separate id and rowid? why not just rowid and data?

"The rowid is implicit and autoassigned, but we want developer-friendly IDs." maybe But of course, the obvious solution is to have one table with just ROWID and data, and another table with the friendly IDs! If you time the insertions really well, then the ROWIDs in both tables with match and voilà.

It's the same thing actually

https://stackoverflow.com/questions/41928749/pros-cons-of-re...

Re: "We ran out of columns"

#520

Earlier quoted context omitted.

This dude has absolutely no right to say anything about the quality of the source code of the android app, because: 1) His libtgvoip code, previously used for audio calls, is the worst code I have ever had the displesaure of touching, it caused all kinds of issues ranging from instability to segfaults, and thankfully it was completely replaced by webrtc. 2) The android app is literally the smoothest and most responsi…

Speaking as an outsider... Your comment reads as a blatant ad-hominem attack and does nothing to support your point. You should consider toning it down if your goal is to convince anyone.

That's just a cultural difference. I've seen Russian developers getting into physical fights over code more than once.

Thankfully, western (and especially american) corporate culture is much more conflict-awerse.

Post reply on HN