5 ms·

This is right. The OP said he is "disillusioned with technology" but I didn't see actual technology being described as the problem with any point. So there's a

by jblow 6y ago

This is right. The OP said he is "disillusioned with technology" but I didn't see actual technology being described as the problem with any point. So there's a conflation here happening between technology and "tech" companies. And I can only say the phrase "tech" companies while using sarcasm quotes around "tech", because almost nobody at any of these companies develops actual technology. And that's a big part of the problem.

kristopolous 6y ago
There's a subculture that's reinvented the merits of software engineering to being as ornate and ceremonious as possible. It doesn't have to work well, or be bug free, or compatible with the previous version, or address any real world need. No! Instead it has to use fashionable technology and be extremely complicated so other programmers can see how incredibly clever they are! Almost like they took a random bug from the issue tracker by looking at last nights lotto numbers and then they opened to a random page of Knuth by letting a fan blow on the pages for 5 minutes and said "alright, I'll solve this problem in that way! Surely everyone will acknowledge my genius!" It may be a slow lumbering buggy pile of brittle barely functional code about to implode, but boy does it look nice!
- kovac 6y ago
  I don't agree with this view. I agree with the original commentor's comment. I do this myself outside of work just to enjoy building something without the responsibility of having to maintain it with 20 other engineers for two more decades. However, even I can see that a team would get burnt if they built an enterprise software the way I code my personal email client. The problem here is that people forget that building software professionally is an engineering job. Like other forms of engineering, there are processes and good practices to facilitate both functional and non functional aspects of a software and the building process. While the extra burden of version control, testability and extendability takes some of the fun away, I would have reservations working with someone who pushes directly to a release branch, does not write test and hardcode values instead of uaing configuration. It's about balance and realising that job is a job.
  - kristopolous 6y ago
    ok, let's go back to 2014. I was working on a project, a web front end. The ticket was "change color of button". This sounded easy, modify the CSS. However, the CSS was generated. From YAML. The YAML was generated from JSON. the JSON was pulled from mongo. The Mongo was updated through a strictly validated XSLT that had an enumeration of colors. Those colors did not include the button color we needed. Don't worry! There was an ability to reroute the xml through the use of ruby mixins and then add the attribute by parsing the dom, editing it, then re-ingesting it later downstream so it gets out to mongo right. oh and there's a cache layer at every point here. so make sure you invalidate it to see the change. every time. I closed the ticket and did a few more like this for 6 weeks, mostly in ember - they were even crazier. The product, an interface to some server software, had basic html with markup like this: <ul class='links'> <li><a href=/a>link</a></li> </ul> Like the most trivial stupidest simple code you can think of. 15 minutes of php, at most. However, changing it to do something else was never direct. 4, 5, 6 maybe 7 different languages, servers, restrictions, databases, input and output formats ... absolute and total batshit. I left. Company is worth over $100 million today, looks like I'm the loser I guess. This isn't about having a dev and release branch, this is about endless layers of abstraction and insanity that make easy things 1,000 times harder and almost impossible.
    - ohvirginia 6y ago
      I love this. you nailed it. modern tech stack is so bullshit. I won't mention the framework I detest most because that would be flame bait, but this.
    - kovac 6y ago
      That sounds complicated. Though I'm not sure if this is a valid example to counter my view. I can't comment on the exact situation you went through. It could be that that complexity was a side effect of having to solve far more complex and frequent issues more easily as opposed to doing simpler and rarer things more easily (unless of course changing button colours is a frequent modification). It's also possible that the design was simply bad. This doesn't mean that you were going to better off without git workflows, code reviews, tests. My experience has been the opposite. It's exactly where there's no good technical leads/technical discussions/code reviews I have seen this kind of mess. Each person goes on and do their own thing with no clear direction or architecture. At the end of the day, for me, to stay sane in the face of this kind of nonsense(as in bad engineers - unfortunately there are those even at senior positions), so what if the button that could have taken a few minutes to change now takes 6 days if we are paid to do it? As a responsible engineer, you point out the issue perhaps with a proposal for improvement. If they listen, good. If they don't, fuck it. On the other hand, if all I end up doing is changing colors of buttons regularly, each taking a week, then for the sake of my career, just say no and move on - unless of course if the pay is so good that it makes sense to spend a couple years doing it - people have to do far more shitty jobs for less. And spend some of the free time to code like a cowboy :)
- eeZah7Ux 6y ago
  > Instead it has to use fashionable technology and be extremely complicated so other programmers can see how incredibly clever they are! You are describing "CV-driven development", where people want to use heavily marketed technology brands in their CV as a substitute for real skill and experience.
- muyuu 6y ago
  Really well put. It's a combination of this phenomenon and a push for commoditising engineers/makers. Paradoxically it's based on "sound economics" - the clear advantage of commoditising "resources" and the clear advantage of anticipating a future stage (which in a massive asymmetry of information is what checkbox-investment appears to be addressing).

by jblow 6y ago

kristopolous 6y ago

There's a subculture that's reinvented the merits of software engineering to being as ornate and ceremonious as possible. It doesn't have to work well, or be bug free, or compatible with the previous version, or address any real world need. No! Instead it has to use fashionable technology and be extremely complicated so other programmers can see how incredibly clever they are! Almost like they took a random bug from the issue tracker by looking at last nights lotto numbers and then they opened to a random page of Knuth by letting a fan blow on the pages for 5 minutes and said "alright, I'll solve this problem in that way! Surely everyone will acknowledge my genius!" It may be a slow lumbering buggy pile of brittle barely functional code about to implode, but boy does it look nice!

kovac 6y ago
I don't agree with this view. I agree with the original commentor's comment. I do this myself outside of work just to enjoy building something without the responsibility of having to maintain it with 20 other engineers for two more decades. However, even I can see that a team would get burnt if they built an enterprise software the way I code my personal email client. The problem here is that people forget that building software professionally is an engineering job. Like other forms of engineering, there are processes and good practices to facilitate both functional and non functional aspects of a software and the building process. While the extra burden of version control, testability and extendability takes some of the fun away, I would have reservations working with someone who pushes directly to a release branch, does not write test and hardcode values instead of uaing configuration. It's about balance and realising that job is a job.
- kristopolous 6y ago
  ok, let's go back to 2014. I was working on a project, a web front end. The ticket was "change color of button". This sounded easy, modify the CSS. However, the CSS was generated. From YAML. The YAML was generated from JSON. the JSON was pulled from mongo. The Mongo was updated through a strictly validated XSLT that had an enumeration of colors. Those colors did not include the button color we needed. Don't worry! There was an ability to reroute the xml through the use of ruby mixins and then add the attribute by parsing the dom, editing it, then re-ingesting it later downstream so it gets out to mongo right. oh and there's a cache layer at every point here. so make sure you invalidate it to see the change. every time. I closed the ticket and did a few more like this for 6 weeks, mostly in ember - they were even crazier. The product, an interface to some server software, had basic html with markup like this: <ul class='links'> <li><a href=/a>link</a></li> </ul> Like the most trivial stupidest simple code you can think of. 15 minutes of php, at most. However, changing it to do something else was never direct. 4, 5, 6 maybe 7 different languages, servers, restrictions, databases, input and output formats ... absolute and total batshit. I left. Company is worth over $100 million today, looks like I'm the loser I guess. This isn't about having a dev and release branch, this is about endless layers of abstraction and insanity that make easy things 1,000 times harder and almost impossible.
  - ohvirginia 6y ago
    I love this. you nailed it. modern tech stack is so bullshit. I won't mention the framework I detest most because that would be flame bait, but this.
  - kovac 6y ago
    That sounds complicated. Though I'm not sure if this is a valid example to counter my view. I can't comment on the exact situation you went through. It could be that that complexity was a side effect of having to solve far more complex and frequent issues more easily as opposed to doing simpler and rarer things more easily (unless of course changing button colours is a frequent modification). It's also possible that the design was simply bad. This doesn't mean that you were going to better off without git workflows, code reviews, tests. My experience has been the opposite. It's exactly where there's no good technical leads/technical discussions/code reviews I have seen this kind of mess. Each person goes on and do their own thing with no clear direction or architecture. At the end of the day, for me, to stay sane in the face of this kind of nonsense(as in bad engineers - unfortunately there are those even at senior positions), so what if the button that could have taken a few minutes to change now takes 6 days if we are paid to do it? As a responsible engineer, you point out the issue perhaps with a proposal for improvement. If they listen, good. If they don't, fuck it. On the other hand, if all I end up doing is changing colors of buttons regularly, each taking a week, then for the sake of my career, just say no and move on - unless of course if the pay is so good that it makes sense to spend a couple years doing it - people have to do far more shitty jobs for less. And spend some of the free time to code like a cowboy :)
eeZah7Ux 6y ago
> Instead it has to use fashionable technology and be extremely complicated so other programmers can see how incredibly clever they are! You are describing "CV-driven development", where people want to use heavily marketed technology brands in their CV as a substitute for real skill and experience.
muyuu 6y ago
Really well put. It's a combination of this phenomenon and a push for commoditising engineers/makers. Paradoxically it's based on "sound economics" - the clear advantage of commoditising "resources" and the clear advantage of anticipating a future stage (which in a massive asymmetry of information is what checkbox-investment appears to be addressing).