4 ms·

Ok. I get that. But to play devil's advocate: with that mentality we'd never learn a new technology and still be stuck on punch cards. And I don't have the time

by kabes 3y ago

Ok. I get that. But to play devil's advocate: with that mentality we'd never learn a new technology and still be stuck on punch cards. And I don't have the time anymore for hobby projects. I'd say it's ok to introduce something new as long as it's one thing at a time and not an entire new stack in the "a rewrite will solve all problems" projects

beagle3 3y ago
To me this argument sounds like “I don’t have time for hobby projects, so I’m going to treat this professional one as a hobby”. I always start a professional project with technologies I am intimately familiar with - have used myself, or have theoretical knowledge of and access to someone with real experience. There has never been a new shiny library/technology that would have saved more than 10% of the project time, in retrospect. But there have been many who would have cost 100% more.
- jamwil 3y ago
  I take your point but you don’t explain how you came to be intimately familiar with those technologies in the first place. Applied consistently, this logic would seem to preclude becoming familiar with anything.
  - beagle3 3y ago
    For projects where I have a paying customer, this rule is absolute; I do not experiment on my client's time (and dime) unless they specifically request it. But I do have projects which I finance myself (with myself as customer), and which do not have a real deadline. I can experiment on those. Call them "hobby" projects if you insist. > Applied consistently, this logic would seem to preclude becoming familiar with anything. Well, project requirements always rank higher, and many projects require some piece I am unfamiliar with (a new DB - e.g. MSSQL; a new programming language; etc). That means one does get familiar on a need basis , even applying this approach robotically. If a project requires building the whole thing around a new shiny technology with few users and no successful examples I can intimately learn from ... I usually decline taking it.
- nyrikki 3y ago
  This isn't a dichotomy. That is the point of DDD,SoA,Clean, Hexagonal patterns. Make a point to put structures and processes in place that encourage persistence ignorance in your business logic as the default and only violate that ideal where you have to. That way if you outgrow SQL as a message bus you can change. This mindset also works for adding functionality to legacy systems or breaking apart monoliths. Choosing a default product to optimize for delivery is fine, claiming that one product fits all needs is not. Psql does have limits when being used as a message or event bus, but it can be low risk if you prepare the system to change if/when you hit those limits. Letting ACID concepts leak into the code is what tends to back organisations into a corner that is hard to get out of. Obviously that isn't the Kool aid this site is selling. With this advice being particularly destructive unless you are intentionally building a monolith. "Simplify: move code into database functions" At least for any system that needs to grow.
  - beagle3 3y ago
    I was not saying "psql is all you'll ever need". I was just replying to >>> "Applied consistently, this logic would seem to preclude becoming familiar with anything." As a general principle.
deathanatos 3y ago
I'm okay with new technology, actually, but the person introducing it has to be able to champion it & do the work of debugging issues and answering questions about its interactions with the rest of the system. I.e., they have to be responsible for it. The last part in my parent comment is more of a "it was chucked over the fence, and it is now crashing, and nobody, not even the devs that chose it, know why". I do have examples of what you describe, too: a dev I worked with introduced a geospatial DB to solve issues with geospatial queries being hard & slow in our then-database (RDS did not, at the time, support such queries) — so we went with the new thing. It used Redis's protocol, and was thus easy to get working with¹. But the dev that introduced it to the system was capable of explaining it, dealing with issues with it — to the extent of "upstream bugs that we encounter and produce workarounds", and otherwise being a lead for it. That new tech, managed in that way by a senior eng., was successful in what it sought to do. The problematic parts/components/new introductions of new tech … never seem to have that. That's probably partly the problem: it's such an inherently non-technical issue at its heart. The exact thing almost doesn't matter. > as long as it's one thing at a time IME it's not. When there are problems, it's never just one new thing at a time. > a rewrite will solve all problems And the particular system I had in my mind while writing the parent post was, in fact, in the category of "a rewrite will solve all problems". Some parts of the rewrite are doing alright, but especially compared to the prior system, there are just so. many. new. components. 2 new queue systems, new databases, etc. etc. So it's then hard to learn one, particularly without someone championing its success. It's another to self-learn and self-bootstrap on 6 or 8 new services. ¹(Tile38)

by kabes 3y ago

beagle3 3y ago

To me this argument sounds like “I don’t have time for hobby projects, so I’m going to treat this professional one as a hobby”. I always start a professional project with technologies I am intimately familiar with - have used myself, or have theoretical knowledge of and access to someone with real experience. There has never been a new shiny library/technology that would have saved more than 10% of the project time, in retrospect. But there have been many who would have cost 100% more.

jamwil 3y ago
I take your point but you don’t explain how you came to be intimately familiar with those technologies in the first place. Applied consistently, this logic would seem to preclude becoming familiar with anything.
- beagle3 3y ago
  For projects where I have a paying customer, this rule is absolute; I do not experiment on my client's time (and dime) unless they specifically request it. But I do have projects which I finance myself (with myself as customer), and which do not have a real deadline. I can experiment on those. Call them "hobby" projects if you insist. > Applied consistently, this logic would seem to preclude becoming familiar with anything. Well, project requirements always rank higher, and many projects require some piece I am unfamiliar with (a new DB - e.g. MSSQL; a new programming language; etc). That means one does get familiar on a need basis , even applying this approach robotically. If a project requires building the whole thing around a new shiny technology with few users and no successful examples I can intimately learn from ... I usually decline taking it.
nyrikki 3y ago
This isn't a dichotomy. That is the point of DDD,SoA,Clean, Hexagonal patterns. Make a point to put structures and processes in place that encourage persistence ignorance in your business logic as the default and only violate that ideal where you have to. That way if you outgrow SQL as a message bus you can change. This mindset also works for adding functionality to legacy systems or breaking apart monoliths. Choosing a default product to optimize for delivery is fine, claiming that one product fits all needs is not. Psql does have limits when being used as a message or event bus, but it can be low risk if you prepare the system to change if/when you hit those limits. Letting ACID concepts leak into the code is what tends to back organisations into a corner that is hard to get out of. Obviously that isn't the Kool aid this site is selling. With this advice being particularly destructive unless you are intentionally building a monolith. "Simplify: move code into database functions" At least for any system that needs to grow.
- beagle3 3y ago
  I was not saying "psql is all you'll ever need". I was just replying to >>> "Applied consistently, this logic would seem to preclude becoming familiar with anything." As a general principle.

deathanatos 3y ago

I'm okay with new technology, actually, but the person introducing it has to be able to champion it & do the work of debugging issues and answering questions about its interactions with the rest of the system. I.e., they have to be responsible for it. The last part in my parent comment is more of a "it was chucked over the fence, and it is now crashing, and nobody, not even the devs that chose it, know why". I do have examples of what you describe, too: a dev I worked with introduced a geospatial DB to solve issues with geospatial queries being hard & slow in our then-database (RDS did not, at the time, support such queries) — so we went with the new thing. It used Redis's protocol, and was thus easy to get working with¹. But the dev that introduced it to the system was capable of explaining it, dealing with issues with it — to the extent of "upstream bugs that we encounter and produce workarounds", and otherwise being a lead for it. That new tech, managed in that way by a senior eng., was successful in what it sought to do. The problematic parts/components/new introductions of new tech … never seem to have that. That's probably partly the problem: it's such an inherently non-technical issue at its heart. The exact thing almost doesn't matter. > as long as it's one thing at a time IME it's not. When there are problems, it's never just one new thing at a time. > a rewrite will solve all problems And the particular system I had in my mind while writing the parent post was, in fact, in the category of "a rewrite will solve all problems". Some parts of the rewrite are doing alright, but especially compared to the prior system, there are just so. many. new. components. 2 new queue systems, new databases, etc. etc. So it's then hard to learn one, particularly without someone championing its success. It's another to self-learn and self-bootstrap on 6 or 8 new services. ¹(Tile38)