4 ms·
are you designing a database schema and writing queries against it = kind I worked in a project using MongoDB. Initial implementation was easy and quick to ite
by Chyzwar 6y ago
are you designing a database schema and writing queries against it = kind
I worked in a project using MongoDB. Initial implementation was easy and quick to iterate. After a few years when it was evident that it was not sustainable. Two years of painfull effort was required to squeeze out MongoDB.
are you doing frontend development (or something similar where fast paced change means new technology, new best practices etc. all the time) = unkind
React already won, front-end tech is stable in last 4 years. It is an easier part of my job. Front-end development require high upfront learning, but it is boring at some point.
are you doing text processing analysis of structured data following well understood schemas = kind
I know some pipelines on structured data that are hell. I worked with XML (FpML) and systems that produced/consume these, It would make most people cry. It is very easy to create massive technical debt where data is flowing. Any change needs to be done from both ends. It is not like front-end where I can refactor components as much I want.
Because programming is such diverse field, I would be careful with labeling anything kind/unkind.
- bryanrasmussen 6y ago>Any change needs to be done from both ends. If the change needs to be done on both ends it is probably an integration problem, which I labelled unkind. The use of the words kind/unkind is probably not well-thought out, because kind implies easy, but there is nothing in the description of the term that means it is an easy thing to do.
- Chyzwar 6y agoKind because there is an obvious path forward. Unkind because there is uncertainty over time. In programming there is no objective measures for code quality, cost of maintenance or even productivity of individuals. I would argue that programming is fundamentally unkind. You can only learn a small fraction of stack and operate on assumptions. It is very hard to learn from other people's experiences as it is hard to quantify complexity. If someone is preaching for microservices you can only understand tradeoffs by having a specific knowledge/experience. That why we have people still using PHP for new projects because they are so entrenched in their local maximum.