3 ms·

Yes, incredibly difficult. Nearing 20 years in the field now and programming is still as difficult as in at the start. Or maybe more so, because you are so awar

Yes, incredibly difficult. Nearing 20 years in the field now and programming is still as difficult as in at the start. Or maybe more so, because you are so aware things will break on the first try anyways. Always. Most important lesson for me is to stay close to the problem domain. Think deeply about what your domain means and model in code accordingly. Staying close to the true meaning of your application beats all other attempts at code maintainability. Types, tests, frameworks, dry, language features, ci pipelines, scrum whatnot. All just fun party tricks that fall short when your building the wrong thing. Are we building the wrong thing? Almost always.

keldami 3y ago
How do you realize that one is building the wrong thing?
- notresidenter 3y ago
  Not OP, but asking yourself who would use what you are building, and then checking whether they will use what you build is a good start. Of course, the "checking" part is hard, even with a lot of methodology.
eyelidlessness 3y ago
I agree almost totally. But I would frame this differently: > Types, tests, frameworks, dry, language features, ci pipelines, scrum whatnot. All just fun party tricks that fall short when your building the wrong thing. Some or all of these might be excellent tools in service of solving your problem in its domain. They may be even essential for solving it. And they might be the wrong tools. It’s situational, and evaluating the appropriateness of each, how and why they fit, is part of modeling the problem domain just as much as designing the appropriate data structures, or state machine flow, or any other mechanism for expressing the domain.
- sfvisser 3y ago
  Agreed, properly modeling domain knowledge without types for example feels insurmountable to me. Maybe there exist a category of programmer who can do this, but why make programming more difficult than it already is.

keldami 3y ago

How do you realize that one is building the wrong thing?

notresidenter 3y ago
Not OP, but asking yourself who would use what you are building, and then checking whether they will use what you build is a good start. Of course, the "checking" part is hard, even with a lot of methodology.

eyelidlessness 3y ago

I agree almost totally. But I would frame this differently: > Types, tests, frameworks, dry, language features, ci pipelines, scrum whatnot. All just fun party tricks that fall short when your building the wrong thing. Some or all of these might be excellent tools in service of solving your problem in its domain. They may be even essential for solving it. And they might be the wrong tools. It’s situational, and evaluating the appropriateness of each, how and why they fit, is part of modeling the problem domain just as much as designing the appropriate data structures, or state machine flow, or any other mechanism for expressing the domain.

sfvisser 3y ago
Agreed, properly modeling domain knowledge without types for example feels insurmountable to me. Maybe there exist a category of programmer who can do this, but why make programming more difficult than it already is.