3 ms·

Generally (and I'm not sure if these are really mental models, but often are in my head as a code, and I would imagine are quite obvious to any developer above

Generally (and I'm not sure if these are really mental models, but often are in my head as a code, and I would imagine are quite obvious to any developer above entry level): Red Green Refactor, YAGNI, Dry, SOLID, and IoC. When it comes to choosing design patterns I usually lean towards KISS, and prefer less code. Cyclomatic Complexity is the enemy of maintainable software and naturally arises when users request new features and grows exponentially with the number of users and/or developers. Because of that I do prefer Cowboy Coding - it handles one side of that count. Reflexively I'll argue with new requests and try and predict what else can go wrong or what unintended outcomes will be that will lead to more user requests or complexity. One pattern I often use in my head is to imagine software as biological systems, evolving ecosystems in tandem with users. There's a sort of evolutionary arms race between growing user stories, making the business money, and Conway's law. I try and stick to the 80/20 rule as often as I can when refactoring and making changes and often consider the biological paradigm Structure/Function when designing. I consider it a win when the system is either less technically complicated or the use case is simpler (less steps for a users workow) after I've touched it between releases.

hkazemi 6y ago
Thanks this is really great answer. In fact I've noticed that the more experiences developers use "mental models" daily without knowing it. For example that 80/20 rule you mention is actually a mental model called Pareto Principle, or Negative Space model when doing a binary search, etc.
- Person5478 6y ago
  I don't know that I would call the Pareto Principle a mental model. But having said that, for me software dev is supposed to be chaotic and that's ok. I describe it as boiling water. There's a process going on, but if you look at it you'll see a lot of activity and churn, but it's still a steady move towards an endpoint (no more water). I believe simplicity trumps all unless there's a very good reason. A developer must be able to honestly introspect and ask themselves how much experience they really have in the current domain. If the answer is anything less than "a whole heckofalot" then do the stupidly simple thing instead of the complicated-thing-that-might-save-time-in-the-future. I think code has an ROI. If you write a stupid, simple brute force method and it works for 6 months, it's not a failure to have to rewrite it. You got an ROI on that code, and you now have a more concrete idea of what your performance needs are. If the new code sits for another 2 years and then needs a rewrite, still not a failure. Outgrowing the current solutions is called success, but I've found a LOT of developers feel as if it was a failure due to not anticipating future needs. I agree emphatically with the above poster about the 80/20 rule. I call it the 80% solution. This is particularly useful when automating things. For example, if you're a hosting company running VPS's and you want to automate the creation and destruction of those VPS's. It can be useful to have a human hit a button to confirm the destruction. It also changes how you look at software used by users. It's a tool to assist them rather than trying to engulf the entire problem. It can be completely ok to allow the user to download data into excel, do what they want to do, then re-upload it rather than trying to recreate excel in your software. These types of systems are often times more productive for users.

hkazemi 6y ago

Thanks this is really great answer. In fact I've noticed that the more experiences developers use "mental models" daily without knowing it. For example that 80/20 rule you mention is actually a mental model called Pareto Principle, or Negative Space model when doing a binary search, etc.

Person5478 6y ago
I don't know that I would call the Pareto Principle a mental model. But having said that, for me software dev is supposed to be chaotic and that's ok. I describe it as boiling water. There's a process going on, but if you look at it you'll see a lot of activity and churn, but it's still a steady move towards an endpoint (no more water). I believe simplicity trumps all unless there's a very good reason. A developer must be able to honestly introspect and ask themselves how much experience they really have in the current domain. If the answer is anything less than "a whole heckofalot" then do the stupidly simple thing instead of the complicated-thing-that-might-save-time-in-the-future. I think code has an ROI. If you write a stupid, simple brute force method and it works for 6 months, it's not a failure to have to rewrite it. You got an ROI on that code, and you now have a more concrete idea of what your performance needs are. If the new code sits for another 2 years and then needs a rewrite, still not a failure. Outgrowing the current solutions is called success, but I've found a LOT of developers feel as if it was a failure due to not anticipating future needs. I agree emphatically with the above poster about the 80/20 rule. I call it the 80% solution. This is particularly useful when automating things. For example, if you're a hosting company running VPS's and you want to automate the creation and destruction of those VPS's. It can be useful to have a human hit a button to confirm the destruction. It also changes how you look at software used by users. It's a tool to assist them rather than trying to engulf the entire problem. It can be completely ok to allow the user to download data into excel, do what they want to do, then re-upload it rather than trying to recreate excel in your software. These types of systems are often times more productive for users.