Advice to live by from Patrick Calahan, see his thread on Twitter:
https://twitter.com/padraig2112/status/979439970107600896
It includes:
If you're simplifying a complex problem, you're likely doing it wrong.
If you're building a complex solution to a simple problem, you're probably also doing it wrong.
If you think you've wrapped your head around a complex problem, you're probably wrong or you're building a solution that already exists. Go find the one that exists first. If it's good, use that. If it's bad, figuring out why it is bad will inform you about the problem domain.
Building things is fun. Building things so that someone else can understand them is hard and not fun. If you are having only fun building things, you're probably building something that other people won't or can't use. That may be a cool thing, but in practical terms it is junk.
If you are managing some group of people and there is a common problem that only one person can fix, one of three things is true: you are a bad manager, you have an employee who built something only they can understand, which makes them a bad team player, or both.
Everybody is wrong some of the time. The better you are at something, the less likely it is that you are wrong at any given point, and the probable severity of the wrongness is reduced.
Any group of people who are all experts is less likely to have a group version of the previous problem. However, when they are collectively wrong, they are likely to be badly wrong. This is why sanity-checking is important.
Everything you build has to be maintained. If you don't pay attention to maintenance costs, you are creating a problem for somebody else (also you are bad and you should feel bad.)
"Fast, cheap, and good. Pick two." is a very common rule of thumb in IT. What is less common is the acknowledgement that usually focusing on "fast" and "cheap" is often the better idea because everything in IT has an end-date of usefulness.
https://twitter.com/padraig2112/status/979439970107600896
It includes:
If you're simplifying a complex problem, you're likely doing it wrong.
If you're building a complex solution to a simple problem, you're probably also doing it wrong.
If you think you've wrapped your head around a complex problem, you're probably wrong or you're building a solution that already exists. Go find the one that exists first. If it's good, use that. If it's bad, figuring out why it is bad will inform you about the problem domain.
Building things is fun. Building things so that someone else can understand them is hard and not fun. If you are having only fun building things, you're probably building something that other people won't or can't use. That may be a cool thing, but in practical terms it is junk.
If you are managing some group of people and there is a common problem that only one person can fix, one of three things is true: you are a bad manager, you have an employee who built something only they can understand, which makes them a bad team player, or both.
Everybody is wrong some of the time. The better you are at something, the less likely it is that you are wrong at any given point, and the probable severity of the wrongness is reduced.
Any group of people who are all experts is less likely to have a group version of the previous problem. However, when they are collectively wrong, they are likely to be badly wrong. This is why sanity-checking is important.
Everything you build has to be maintained. If you don't pay attention to maintenance costs, you are creating a problem for somebody else (also you are bad and you should feel bad.)
"Fast, cheap, and good. Pick two." is a very common rule of thumb in IT. What is less common is the acknowledgement that usually focusing on "fast" and "cheap" is often the better idea because everything in IT has an end-date of usefulness.
