Knowing your faults is great advice. It's important to know where your own flaws lie, so that you can find ways to work around them. If you aren't aware of your flaws, you can wind up making some serious mistakes, like letting your emotions make your decisions for you.
I think the same can be said of software. It's important as an engineer to know where your software is weak. Every project I've ever been on has had at least ten things that "could be improved" if we had more time/money. Knowing this list is one thing, tracking it and adapting for it is another.
When designing software, it's important to make sure that the weaknesses aren't critical to the success of your business, however sometimes this is inevitable (or it was designed by someone else ;) ). Recognizing these flaws lets you mitigate them until you have a chance to remove them.
In real life, I have a set of close friends who are very honest with me. If I'm doing something stupid, they'll let me know. Imagine these friends as my profilers, loggers and monitors.
There was a recent blog post about Monitoring Driven Architecture. Finding and determining useful monitoring metrics can be the key differentiated between quickly solving architectural issues and shooting at the wall hoping you hit your own zombie-infested hand.
In the future, I will not start a new project without identifying weak areas and monitoring points. These things need to be monitored as soon as possible. Also, only real deployments can truly tell you which metrics are useful, so make sure you update your monitoring as time goes on.
To my readers who still subscribe even though I've been really lame about making useful posts recently:
I normally don't write these rambling though-stream posts, so send me some feedback. If you'd rather like more technical blogs, I'm working on a few (The "Leaky" Monad should hopefully be done soon ;) ).
I think the same can be said of software. It's important as an engineer to know where your software is weak. Every project I've ever been on has had at least ten things that "could be improved" if we had more time/money. Knowing this list is one thing, tracking it and adapting for it is another.
When designing software, it's important to make sure that the weaknesses aren't critical to the success of your business, however sometimes this is inevitable (or it was designed by someone else ;) ). Recognizing these flaws lets you mitigate them until you have a chance to remove them.
In real life, I have a set of close friends who are very honest with me. If I'm doing something stupid, they'll let me know. Imagine these friends as my profilers, loggers and monitors.
There was a recent blog post about Monitoring Driven Architecture. Finding and determining useful monitoring metrics can be the key differentiated between quickly solving architectural issues and shooting at the wall hoping you hit your own zombie-infested hand.
In the future, I will not start a new project without identifying weak areas and monitoring points. These things need to be monitored as soon as possible. Also, only real deployments can truly tell you which metrics are useful, so make sure you update your monitoring as time goes on.
To my readers who still subscribe even though I've been really lame about making useful posts recently:
I normally don't write these rambling though-stream posts, so send me some feedback. If you'd rather like more technical blogs, I'm working on a few (The "Leaky" Monad should hopefully be done soon ;) ).