3 ms·

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 p

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.

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.