|
|
|
|
|
by btilly
1965 days ago
|
|
The principles of architecting code and system design are timeless. That I emphatically agree with. Some of my favorite programming books are decades old. There are definitely people out there who don’t “code really well on command”, but can ask the right questions to design a solid system. There are? I can't say that I've ever met one. The problem is that people don't know what they don't know. A non-programmer can know exactly the business problem to solve and exactly how they want to solve it. But they can't tell the difference between what is easy for a programmer and what is hard. They don't have to learn a ton of programming to fill that bit in. But if they never fill it in, that limitation will keep them from being able to be a good software architect. |
|
I am probably rather crappy programmer. I was crappy perl programmer, crappy php (starting with version 2), crappy in delphi, c, c++. Probably okay in Python, but mostly because Python allowed to concentrate on solving problem and not fighting the language.
Me been crappy was probably because I never really enjoyed to write code, as interesting part is figuring out solution to a problem. Rest is implementation details :) You can say if you want that I am simply too lazy to write code.
Me been crappy in writing code doesn't mean that i am bad in understanding code or understanding what is it to write code the easy way or the hard way.
In majority of cases when programmers come to me with design that will be easy for them to implement, turns out that they have a bunch of big problems that they missed, mostly due to lack of experience. Most of the time solutions that they come up with complicate things further and add even more problems.
And this is the point of time when I assist them to simplify whatever complex design they made to something much more simple and doable.
I saved many man/years of development time by showing programmers easy ways that they didn't know that they exists