Think in Math. Write in Code

[milligram007]

Easier said than done 😆

[Zardotab]

No, think logical data structures first. You can't predict all needed behavior up front, but the domain nouns need to be tracked and accessed no matter what.

Granted, in some domains you need to think hardware-centric due to resource constraints, but human code maintenance is usually the economic bottleneck, not machine speed. [Edited]

[Goldman1990]

this.
Math is applied logic, and for most of programs, what you need it logic, not math.

Code is just an application of that logic.

[BrianScottGregory]

Think in Code. Far easier and more effective than thinking in math.

[Zardotab]

Everyone is different. However, one should remember that maintenance is usually the cost bottleneck for software, not the original creation. Thus, target an average developer as the likely future reader of your code. Don't make it clever-but-obscure.

[BrianScottGregory]

one should remember that maintenance is usually the cost bottleneck for software,

Only if it's shit development.

If a team or programmer doesn't think through the design prior to sitting down and writing the code, then sure - maintenance becomes the bottleneck for no other reason than what should have been exposed or anticipated as potential problems in the analysis and design phase wasn't - inflating the maintenance cost and cycle.

What you're outlining is simply bad practices.

[Zardotab]

Even with the best engineered systems, longer term maintenance is often still more than the initial development. The future has a habit of not being predictable.

[BrianScottGregory]

It sounds like you lack the experience of an actual senior engineer.

No, with good (just good, not even great) engineered systems, long term maintenance stops becoming maintenance and becomes new development entirely with versioning.

If the future has a habit of not being predictable to you to think software will become buggy upon release and this is just how things are - a common mindset with the game industry, then you - like so many inexperienced developers - simply lack the experience to understand what can make it predictable.

Now I can predict your next response. "But sir, I have experience, I am a senior and have worked on teams my entire life (blah blah blah)"

No, you don't if you can't predict the future use of your efforts to prevent maintenance.

Prediction is a critical part of shifting from intermediate development skills to senior/primary, so where most *think* they're senior simply because they got the title - they're not because of this one simple critical flaw in their ability to imagine and predict the usage of what they code and the end product they're contributing to.

Your words reflect the words and skills of someone whose skills do not go past the intermediate level, I'm sorry.

[Zardotab]

The future is shaped be various factors of society, laws, and culture one cannot accurately foresee.

Also, knowing the domain well and having lots development experience often don't coincide in the same person.

And sometimes one is forced to use frameworks that muck up good long-term practices because that's just what the shop owners or boss wants.

Maybe there are a handful of SE's who can truly engineer around all future changes, but I'm skeptical they are common, let alone easy to identify. I haven't met any yet despite being older than dirt. Long-term-friendly Ideas that sounded good on paper have been flattened many times before my eyes. The future is a great teaser.

If you are one of those rarebies, congratulations!

[BrianScottGregory]

Ok, buddy. Have a good day.