441–450 of 588 posts
Oh, those kinds of columns. I thought we were talking text columns, and I was about to relate. I work at a small business. Despite computer software being about the literal opposite of our business (plants), the founder built an entire suite of interconnected tools that runs off MS BASIC for Xenix, on a single HP machine running SCO OpenServer. The machine has so many customizations, self-scheduling cron/at jobs, odd…
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…
Is that kind of stuff common? People checking out on Black Friday and coming back for New Year's?
Earlier quoted context omitted.
These type of stories are a humbling reminder that PMF always beats engineering excellence
Well that depends entirely on what you consider to be the goal - as a software engineer, your role is entirely concerned with engineering excellence. As a member of a team, especially a team of extremely highly paid and highly educated individuals, it is your duty to spend your time (and thus, the company’s resources) efficiently by doing what you’re educated, qualified, and hired to do.
Earlier quoted context omitted.
You either meant Visual SourceSafe or Team Foundation Server for the Microsoft product. SourceSafe did get abandoned... because your source wasn't actually safe in it. Its replacement, Team Foundation Server got rebranded as Azure DevOps; but the product's still around, 19 years later.
Yes, but it's source control shifted to git years ago (I think you can still use TFS, but it's strongly legacy ) and git is mich better than TFS ever was.
Earlier quoted context omitted.
Aside - the fact that cars dont include spares these days is infuriating. IMO its a classic example of real world enshittification
that's not enshittification! it sucks, yes, but when coined, the term referred to a platform extracting value from its users by degrading their experience, forcing them to upgrade to a premium plan. your car not having a spare isn't an example of that! https://en.wikipedia.org/wiki/Enshittification
Earlier quoted context omitted.
> 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.
The old codebase was an hairy ball of scala using a very outdated version of a (now) infamous actor framework. Before they figured out that untyped messages kinda left out one of the major selling point of Scala.
The code was readable, but the authors had this strange idea that every little piece of logic should be part of its own "Actor". An actor is pretty much equivalent to a class, and each one of them had their own little file. With this many classes, with very specialized purposes, you ended up with 90 character identifier names.
To understand what would be a single function in a normal code base, you would have to dive through half a dozen files through several repositories to piece together the logic. Generally, at the end, you find that most of the code is about passing around a value, and there is this one file where there is actual logic applied to the value.
It wasn't that awful. The thing was that it was impossible to change anything: no documentation, no test, no bug tracking, not even any PR process, laconic commit messages, no Wiki pages. And the actor framework made it very difficult to add tests. But later developers did manage it pretty well, they drew fences around the old services, with an HTTP API to communicate with it. And all later additions were part of different services that were very cleanly and consistently designed.
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…
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…
No, that really justifies anything. Programs should be pleasant for users to use, not for developers to work on them
If you have a messy app, you have a messy organisation.
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?