3 ms·

"Sometimes"? I'd say 95% of them suck and more often than not, religious-like beliefs get in the way... as usual in all human discourse. People like me who mov

"Sometimes"? I'd say 95% of them suck and more often than not, religious-like beliefs get in the way... as usual in all human discourse. People like me who moved on from several different technologies during their career -- even though they have built profitable sub-careers on their shoulders -- seem to be an exception. I didn't expect that. I was convinced that programmers are rational and ruthlessly effective and that everyone is like me: they will understand and realize the limitations of what they work with and will move to something that serves them and the business better. Oh, how wrong I was. So yeah, most such discussions are like various religious fanatics screaming at each other. With time I severely dialed down my participation in such "discussions" and nowadays I only comment on HN and leave the occasional (read: 1-2 times a month) comments on Reddit. And I have trained myself to care less and less if somebody disagrees with me for emotional reasons or due to sunk cost fallacy. It's extremely tiring to explain those to people, from scratch, every time, and them eventually ending up saying stuff like "I don't know man, you might be right but I still believe that..." -- and proceeds to repeat something we disagreed on 20 times already. No time or energy for that stuff anymore. If you want to believe, then believe. Not my problem anymore, and nowadays I wonder why it was ever my problem in the first place (in the past).

bombela 4y ago
You care because most often it is your problem still. For example, when you know with facts that a given technology is less error prone than another. But the other party still picks the worse one. When a year down the line shit hit the fan, it usually ends up back on you. Because you are the only one with enough knowledge and expertise to even understand the mess they put themselves in.
- Supermancho 4y ago
  I'm certainly in the defensively argumentative crowd. Eventually, as someone who likes doing this work, a single/series ends up being a massive albatross on the team until the project dies or someone steps up. That's often me, because I don't want to be miserable. Sometimes the choices are so monumentally bad, there is no way to fix it. It's just a miserable death march.
  - pdimitar 4y ago
    Yeah, I am very much the same (if I read you correctly): I get it that maintenance is more important than "devs playing with new shiny toys" -- a saying over which I slammed a manager in a high-level meeting and I didn't flinch doing it; I'd do it again! -- BUT sometimes it's painfully obvious, usually months later, that using tech X or Y just makes it that much harder to maintain the software. There are points at which difficult decisions have to be made. It's a shame most managers / CTOs / VPs of engineering are so cowardly and idolize not being spotted by upper management for having a few hiccups in their projects, over any other concerns. I have no patience for their political in-fighting in companies so I usually arrive at a contract, beat a bunch of things into shape, reduce test failures, simplify deployment, introduce a few conventions (and document them) that make it easy to change code, make 1-2 high profile and very requested features and then usually end up leaving 6-9 months in -- simply because I start getting included in the political games. At that point I am like "hell no" and just move on.
- hutzlibu 4y ago
  "For example, when you know with facts that a given technology is less error prone than another." I am sorry, but this sounds a bit like you are in the fanatics camp. It always depends on what you want to build and what is the given skillset of the people and the avaiable time. Bad teams will mess up even with the best technology and good teams can deliver with outdated imperfect languages. And good teams can disintegrate over religious tech wars ..
  - pdimitar 4y ago
    This is always down to context -- so please don't generalize somebody as a fanatic. Many times during my work it has become apparent that (some examples follow): 1. We constantly introduce bugs due to the dynamism of the language we use. We had in-house devs that could have rewritten a few very small services (think 20-ish endpoints, we're not talking rewriting a mastodon with 500+ here) in a static strong typed language. Alas, almost everyone mercilessly shot that effort down even though it was right in everyone's faces how that will reduce the upkeep of bugs and maintenance with at least 50%, if not 80%. 2. Somebody figured it's a genius idea not to follow the conventions of a certain web framework. At least 15 people came and left over the course of a year and they all struggled hard to adapt. It's not because they're stupid; it's because you have a well-working schemata in your head that you have to undo many times over just so you can work in a single team / company. Eventually all these people figured it's not worth it and I can relate to them (even though I and several others had no difficulty adapting). 3. At one team somebody decided that the in-VM cache implementation is buggy -- even though it absolutely is not because otherwise even stuff like WhatsApp wouldn't function well, btw! -- and they said "hey, let's not only use Redis for cache" (which is fine) "...but also let's use it for mutexes and semaphores that span several computers" (lol). Only after me and another senior threatened to leave did management finally budge and they left us to rewrite the thing which resulted in smaller Dockerfiles, simplified deployment, inadvertent fixing of 20-30 intermittently failing integration tests, and reduction of coding lines by about 1200 (in a project with 11500-ish coding lines so 10% decrease). Then we still left afterwards btw, both of us together, because management figured we're some kind of a threat and sabotaged us at every turn afterwards. Petty small humans ignoring feedback from users and other dev departments telling them we did the right thing. Those I'd call fanatics. Point is, people want one thing to "just work" and never touch it again, and then proceed to use fluff language to disguise this like it's anything else BUT that. Some of us see through that BS. Yes, error-prone tech exists. Yes, projects get improved by the removal of those. And I truly believe all this mindset of "you can do your project in ANY tech and it won't make a difference" seriously has to stop. This has been demonstrably false throughout most of computing's history.

bombela 4y ago

You care because most often it is your problem still. For example, when you know with facts that a given technology is less error prone than another. But the other party still picks the worse one. When a year down the line shit hit the fan, it usually ends up back on you. Because you are the only one with enough knowledge and expertise to even understand the mess they put themselves in.

Supermancho 4y ago
I'm certainly in the defensively argumentative crowd. Eventually, as someone who likes doing this work, a single/series ends up being a massive albatross on the team until the project dies or someone steps up. That's often me, because I don't want to be miserable. Sometimes the choices are so monumentally bad, there is no way to fix it. It's just a miserable death march.
- pdimitar 4y ago
  Yeah, I am very much the same (if I read you correctly): I get it that maintenance is more important than "devs playing with new shiny toys" -- a saying over which I slammed a manager in a high-level meeting and I didn't flinch doing it; I'd do it again! -- BUT sometimes it's painfully obvious, usually months later, that using tech X or Y just makes it that much harder to maintain the software. There are points at which difficult decisions have to be made. It's a shame most managers / CTOs / VPs of engineering are so cowardly and idolize not being spotted by upper management for having a few hiccups in their projects, over any other concerns. I have no patience for their political in-fighting in companies so I usually arrive at a contract, beat a bunch of things into shape, reduce test failures, simplify deployment, introduce a few conventions (and document them) that make it easy to change code, make 1-2 high profile and very requested features and then usually end up leaving 6-9 months in -- simply because I start getting included in the political games. At that point I am like "hell no" and just move on.
hutzlibu 4y ago
"For example, when you know with facts that a given technology is less error prone than another." I am sorry, but this sounds a bit like you are in the fanatics camp. It always depends on what you want to build and what is the given skillset of the people and the avaiable time. Bad teams will mess up even with the best technology and good teams can deliver with outdated imperfect languages. And good teams can disintegrate over religious tech wars ..
- pdimitar 4y ago
  This is always down to context -- so please don't generalize somebody as a fanatic. Many times during my work it has become apparent that (some examples follow): 1. We constantly introduce bugs due to the dynamism of the language we use. We had in-house devs that could have rewritten a few very small services (think 20-ish endpoints, we're not talking rewriting a mastodon with 500+ here) in a static strong typed language. Alas, almost everyone mercilessly shot that effort down even though it was right in everyone's faces how that will reduce the upkeep of bugs and maintenance with at least 50%, if not 80%. 2. Somebody figured it's a genius idea not to follow the conventions of a certain web framework. At least 15 people came and left over the course of a year and they all struggled hard to adapt. It's not because they're stupid; it's because you have a well-working schemata in your head that you have to undo many times over just so you can work in a single team / company. Eventually all these people figured it's not worth it and I can relate to them (even though I and several others had no difficulty adapting). 3. At one team somebody decided that the in-VM cache implementation is buggy -- even though it absolutely is not because otherwise even stuff like WhatsApp wouldn't function well, btw! -- and they said "hey, let's not only use Redis for cache" (which is fine) "...but also let's use it for mutexes and semaphores that span several computers" (lol). Only after me and another senior threatened to leave did management finally budge and they left us to rewrite the thing which resulted in smaller Dockerfiles, simplified deployment, inadvertent fixing of 20-30 intermittently failing integration tests, and reduction of coding lines by about 1200 (in a project with 11500-ish coding lines so 10% decrease). Then we still left afterwards btw, both of us together, because management figured we're some kind of a threat and sabotaged us at every turn afterwards. Petty small humans ignoring feedback from users and other dev departments telling them we did the right thing. Those I'd call fanatics. Point is, people want one thing to "just work" and never touch it again, and then proceed to use fluff language to disguise this like it's anything else BUT that. Some of us see through that BS. Yes, error-prone tech exists. Yes, projects get improved by the removal of those. And I truly believe all this mindset of "you can do your project in ANY tech and it won't make a difference" seriously has to stop. This has been demonstrably false throughout most of computing's history.