We’ve had a growing invisible divide in software for two decades now:
A: People who jam in frameworks, copy examples online, and adopt “processes” and principles that bigger companies claim work for them, that only result in pulverizing responsibility, speed and understanding. They don’t expect to understand their tools. They fudge them until they stop giving off visible problems and wrap that up in “grown up words” by making ineffectual unit tests, make a PR, tagging it “bugfix: ticket #877”, sending it to review, debating some syntax, and spend the next two years debugging the system because of all the small things that go wrong because the thing they make don’t behave according to a clear mental model.
B: People who don’t think knowing a single programming language counts as competence, and prefer making things according to a model (instead of copying someone else’s framework and contorting their own work to fit inside it)
Group A are the reason shit sucks today, and they believe LLMs can code, because they themselves can barely code and just copy impressive looking convoluted shit from others anyway.
Frameworks can be fine. Using them before understanding what you make is not. At that point you often see it is faster and better to just make the parts you needed yourself.
Model as in you have a clear opinion on what your system does, why, how, and what it doesn’t do. A model evolves during development, which is where it becomes hard: You always need to make room for things you didn’t predict, so you need to adapt and refine the system model so that the change makes sense.
Adding features until a full system explanation consists largely of “but”, “and also” or “except”, things like “and you should ask Bea about how that part works” or the worst of all “this part can be anything”, is the opposite of working from a model.
We’ve had a growing invisible divide in software for two decades now:
A: People who jam in frameworks, copy examples online, and adopt “processes” and principles that bigger companies claim work for them, that only result in pulverizing responsibility, speed and understanding. They don’t expect to understand their tools. They fudge them until they stop giving off visible problems and wrap that up in “grown up words” by making ineffectual unit tests, make a PR, tagging it “bugfix: ticket #877”, sending it to review, debating some syntax, and spend the next two years debugging the system because of all the small things that go wrong because the thing they make don’t behave according to a clear mental model.
B: People who don’t think knowing a single programming language counts as competence, and prefer making things according to a model (instead of copying someone else’s framework and contorting their own work to fit inside it)
Group A are the reason shit sucks today, and they believe LLMs can code, because they themselves can barely code and just copy impressive looking convoluted shit from others anyway.
so group B doesn’t use frameworks but prefers making things according to a model? What’s a model here? I’m not following
Frameworks can be fine. Using them before understanding what you make is not. At that point you often see it is faster and better to just make the parts you needed yourself.
Model as in you have a clear opinion on what your system does, why, how, and what it doesn’t do. A model evolves during development, which is where it becomes hard: You always need to make room for things you didn’t predict, so you need to adapt and refine the system model so that the change makes sense.
Adding features until a full system explanation consists largely of “but”, “and also” or “except”, things like “and you should ask Bea about how that part works” or the worst of all “this part can be anything”, is the opposite of working from a model.