To encrypt data you send to me, or to verify docs digitally signed by me, please use my GNU Public Key:
-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: GnuPG v1.2.2 (MingW32)
mQGiBEaJVpoRBAC7aD0MH+QpFj0FzZZ/A0eUIK6f0YxgueT2jHKcQqRhQzigimXi
Ztsg9YVGF+xpC2OJ9za/I6GNpG4kdI4+JhWWzKeKPygGTmx/xjA5tzGJX4zQAtGQ
af25S6jW1xEBJI81gGAvcTllbe6rKrFHHkYCN0dlBRtWg+H3fcNUetT05wCgvdJY
ipkBV7VTo9qZ2TlpOug0WRcD/2lL2r3i+buBe72FKpvCOfo3W3px8zPAywlryeC1
me2SAjWp4JxT9bE8GCcP5hXMJanlESO963xxgM7pig6riZUFe/fmrhgpUmm+PGns
rxScRVdhbNRewa2pPrrbWIrykMJAZHCabc5AX/QLLQ83VpaZB54Hn58Lv3jsiqVQ
ABZjBACiPR4IrqDh1+oNl/ILimtv4Wpv42LD4O4f8vGFQtc3Rh19Soo2H2qX3zyJ
vdmyW6ZLfoJkGZfw34UXTBesPkZlx8QPFCL/QaTwqXU9QYWxP223NGpPouOG4Na3
4JIpFYjM8gXboyhKF3D57DGMq0rFDoPj/+J0OZavK2BlccSNzbRQQmlsbCBXcmln
aHQgKFRoaXMgaXMgbXkgdmVyeSBzcGVjaWFsIENvbUZyYW1lIHB1YmxpYyBrZXkp
IDxid3JpZ2h0QGNvbWZyYW1lLmNvbT6IWwQTEQIAGwUCRolWmgYLCQgHAwIDFQID
AxYCAQIeAQIXgAAKCRCEy9mEvjZ9SNrFAKChXVTk5pGx6ntDrCm9/2oYkuQqYgCf
UNTylzchwpQhDJz6XXuV7J9fIuG5AQ0ERolWnBAEAPsP8fWX+FoIQVhST/TySD4w
mbn8UsGD9UCPe7EfJKsGfVeteAQsU8+PUPxqDviSxnlSaouUftZl44Xt5KT3qKGX
PZdkcr9xjt5Y2+C2Qdd94mnTMj+WdtfeviXHzkRWo+HrJPygONGTB0zFwiVsuLJu
c1v+/C3xUVwcIEdjxq4/AAMHA/9I+G5UxOIS1GMFMblsz9lq7YGlkceIb4cKixpM
n9oMP0BQMKVnVnW3kOfFQaY69CE0BCmVK+k7Xh49EqaZ34KuWrXNSGkYF8r2saHB
YUyR0B+oEdIWF9JhC2FjA2M5BiPOGmU6OGSDzq8zmc6eZBq6FyCdeU2/dKzSOBTw
9F+VJohGBBgRAgAGBQJGiVacAAoJEITL2YS+Nn1IH8oAnjx0JWw2DdcoY316L5j9
G3GYYEXBAJsGhz569+k1AKmxzKVNGMhyWcx5bg==
=/RXh
-----END PGP PUBLIC KEY BLOCK-----
Friday, September 28, 2007
Wednesday, September 12, 2007
Let's begin...
I really want to share with you some thoughts about software development.
These are some "truths" that keep making their way into my experiences. Perhaps you have seen them too.
1) Keep it simple. The best architecture is like achems razor, i.e. "All things being equal, the most simple explanation is probably the correct explanation."
2) A language is just a tool -- a means to an end. There are many languages out there, and no single one is made to fit all problems. The language carries with it frameworks that are designed to solve specific problems. Find the right language for your problem domain.
3) Don't reinvent the wheel. If someone else has solved a problem or pattern, use it!
4) Admit what you don't know. Software is a broad, broad area. No one can know it all.
5) Keep up with your contacts. Your past associations are often your best resources for information, solutions, and (most importantly) friendship.
6) Understand the major design patterns. People often quote certain patterns in geeky conversations as if knowing the name of the pattern puts you in the "club". I have seen people list design patterns on their resumes. On close examination, they don't really understand them. Don't be one of those guys.
7) Learn the business domain. Just applying software principles to a problem may be enough to solve the problem, but it doesn't add value to your resume. Develop your expertise in the business itself. You will find that it will lead to more consulting situations over time than just knowing how to code.
8) Learn to code. Don't fake it.
9) RTFM. Documentation is done for a reason. You are better off spending some time learning the background information about your problem than just by looking at the code.
10) Contribute to the industry. You have an obligation to add to your craft! Develop your expertise and share it through publications, technical associations, instruction, etc.
I really want to share with you some thoughts about software development.
These are some "truths" that keep making their way into my experiences. Perhaps you have seen them too.
1) Keep it simple. The best architecture is like achems razor, i.e. "All things being equal, the most simple explanation is probably the correct explanation."
2) A language is just a tool -- a means to an end. There are many languages out there, and no single one is made to fit all problems. The language carries with it frameworks that are designed to solve specific problems. Find the right language for your problem domain.
3) Don't reinvent the wheel. If someone else has solved a problem or pattern, use it!
4) Admit what you don't know. Software is a broad, broad area. No one can know it all.
5) Keep up with your contacts. Your past associations are often your best resources for information, solutions, and (most importantly) friendship.
6) Understand the major design patterns. People often quote certain patterns in geeky conversations as if knowing the name of the pattern puts you in the "club". I have seen people list design patterns on their resumes. On close examination, they don't really understand them. Don't be one of those guys.
7) Learn the business domain. Just applying software principles to a problem may be enough to solve the problem, but it doesn't add value to your resume. Develop your expertise in the business itself. You will find that it will lead to more consulting situations over time than just knowing how to code.
8) Learn to code. Don't fake it.
9) RTFM. Documentation is done for a reason. You are better off spending some time learning the background information about your problem than just by looking at the code.
10) Contribute to the industry. You have an obligation to add to your craft! Develop your expertise and share it through publications, technical associations, instruction, etc.
Subscribe to:
Posts (Atom)
