3 ms·
Makers who don’t understand 1 or 2 often create slow or insecure code that often results in clear user impact. For example, I’ve seen diffing / recomputation c
by ummonk 7y ago
Makers who don’t understand 1 or 2 often create slow or insecure code that often results in clear user impact.
For example, I’ve seen diffing / recomputation code operating in O(n^3) or O(n^2) where O(n) or O(1) is possible and necessary for reasonable performance. I’ve also seen extremely poor use of network requests (multiple serial requests) that happen because the developer doesn’t understand network latency and networking performance (in this case with a single data center in the world).
- michaelscott 7y agoIn practice, a great engineer should be relatively well balanced in all 3 aspects and know when to favour one over another (such as the time sensitive case where performance in the code execution is more important than writing something that the next engineer can easily understand).
- inamberclad 7y agoYou can't make it better until you make it work.
- adrianN 7y agoBut you can start off with an architecture that requires a full rewrite to make it better.
- hellisothers 7y agoThe number of times I’ve seen this sentiment end in a project being late or never ship is easily 10x more than the number of times a project became crippled later because of performance issues.
- tdbgamer 7y agoImproving performance isn't the only way you can make something "better". A system could be architected in a fragile or rigid way that makes extending it or adding new features extremely difficult without a rewrite. I can't tell you how many times I've seen people "make it work" and create a mess that has to be rewritten later with much greater difficulty than if even the slightest amount of forethought had been given before hand.
- dnautics 7y agoReally? I think it's often group 2 that makes insecure code.