451–460 of 588 posts
I built a system as horrible as this. One of my many terrible inventions was as follows: Originally our company only did business in one marketplace (the UK). When we started doing business in multiple marketplaces, it came time to modify the system to cope with more than one. Our system assumed, _everywhere_, that there was only ever one marketplace. I had a plan: I would copy-paste the system, make an "internationa…
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…
I worked at a startup where we had to make a lot of compromises. The (non technical) founders could not get enough funding at the beginning, so they had to constantly raise small amounts to survive the next few months. We had to grow fast and prove that we had a market fit. This meant making compromises, but the technical debt was actually under control. We knew what to improve and how to do it once we had enough res…
Exactly the opposite of the one trick pony’s who just mindlessly apply what they learned or think is cool with a total disregard for context.
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…
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’ve used Clearcasse in 2006 and it had all the branches that we needed. We didn’t use locks because that was annoying. It was at Deutsche Bank and we were 200. When I moved to SVN, it was a regression. I really don’t understand why people describe SVN as cutting-edge (and why people didn’t like Clear Case).
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…
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…
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!
I’d argue everything else becomes expensive quickly.
…but it is also imperative to remember any modification on checked out code is a branch, technically, regardless of the version control system used. This becomes important if your testing is expensive.
Earlier quoted context omitted.
That's such a weird rewriting of history. I know blaming VC is very fun and all, but Bitbucket, originally centered around mercurial, had just as much resources as GitHub and even more. Tons of early contributors to git and the ecosystem were from google and Microsoft. Microsoft started using and shifting towards gif when GitHub was still a baby, etc.
> That's such a weird rewriting of history. I know blaming VC is very fun and all, but Bitbucket, originally centered around mercurial, had just as much resources as GitHub and even more. You might want to go review your history before accusing someone else of that. Github took $100 million from VCs in 2012. It then took another $250 million from VCs in 2015. Who the hell else was even within an order of magnitude of…
In any case,that doesn't really matter considering that git had big players adopting before GitHub got any sizeable investment. And I'm not just talking about Linux. Rails migrated towards it when GitHub was still in beta.
Earlier quoted context omitted.
1) Which version are we talking about? Segfaults were exceedingly rare either way. Especially so when I stopped using raw pointers. But yes, to no one's surprise, early versions were a mess. I can agree with you on that. I can't agree about the same about the last versions though. It was replaced by WebRTC that would sometimes just suddenly disconnect your calls, right. > I managed to improve the situation after week…
> but that still doesn't justify No, that really justifies anything. Programs should be pleasant for users to use, not for developers to work on them
And, honestly, these things are connected. It takes more needless work from the developer to maintain the user-visible pleasantness while adding new features. The code is much more fragile than it could've been which means bugs are much easier to introduce and much harder to diagnose and fix.
And I'm not asking for a complete rewrite. Just losslessly restructure the existing code, extract all those custom FrameLayouts and ViewGroups into separate classes, split those 2000-line if statements into separate methods, make some things (like ChatMessageCell) into sensible class hierarchies, introduce constants or enums to replace magic numbers, all that sort of stuff. This will not affect the UX, but it would make bugs harder to introduce and easier to deal with.
I'm generally not a fan of the developer-experience-focused approach to software development (Electron, React, and the web dev "trust me bro" attitude should not exist), but sensible code structure is where I draw the line.
> Now the story I heard at the time was that once upon a time SQL Server didn't support auto-incrementing ids. This was the accepted, correct answer. At a company that I used to work, they heard the same rumor, so instead of using identity columns or sequences, they kept a table with a number of ids "available" (one row per id). Whenever unique id was needed, the table would be locked, an id selected and marked as us…
Maybe they wanted to avoid maintaining a separate CUSTOMER_ADDRESS 1-to-many table or maybe it was done to make easy reverse lookups.
Earlier quoted context omitted.
GitHub won because they built a great product. It was better than all the alternatives and people flocked to it for that reason. Git itself is mediocre, and some other DVCS like Mercurial could have won out, although HgHub really doesn't have the same ring to it. The halo effect from the Linux kernel was also a factor. But the VC cash dump and Microsoft buyout came later, people used GitHub because it was better than…
Mercurial lost because it had the wrong mindshare. It was the Betamax of version control and while it had a lot of positives, it never gained the critical mass to overcome VHS.