- Andrew Kos
- Bill Burlein
- Bryan Williams
- Christian Vozar
- Jeff Brown
- John Kraus
- Joseph Mak
- Josh Durbin
- Mark Daugherty
- Matt Van Bergen
- Melissa Geoffrion
- Michael Kang
- Michael Chan
- Michael Hodgdon
- Mike Motherway
- Molly McDaniel
- Nadia Maciulis
- Pat McLoughlin
- Paul Michelotti
- Puru Hemnani
- Rohit Srinath
- Ryan Lunka
- Tom Kelly
What makes a great developer?
Thursday, April 16, 2009
This is what it all comes down to. A lot of developers tend to write complex code. I think it is a result of the ad-hoc nature of programming. The truth is that it is much more difficult to write simple code. I think there are two facets to writing simple code. One is experience, and the other is patience. Experienced developers are better prepared to write simple code from the start. However, simplicity is ultimately achieved by continuously refactoring the code.
The code may be simple, but is it elegant? Elegant code is a sure sign of a great developer. It is no longer about efficiency or effectiveness. It is about pride.
In order to achieve simplicity and elegance, a developer needs to find the right balance between framework/libraries and code. A lot of developers assume that when a framework/library can be used, it should be. Others insist on writing code without the use of any frameworks/libraries. It is all about finding the right balance between the two.
If the code is simple, elegant, and balanced then there is no reason why it shouldn’t be clean. It should be formatted and follow the proper naming conventions.
The breadth and depth of knowledge is not nearly as important as a developers ability and desire to learn. As a matter of fact, I’d say that a significant amount of breadth or depth may be detrimental. It may indicate a lack or awareness or flexibility. It is not about knowing X and Y for years. It is about being able to learn Z in days.
A great developer dominates the entire code base. While some developers may be comfortable in their area of responsibility, great developers have a need to know and understand the entire code base.
It is important to consider aspects such as maintainability when developing code. The focus should not just be on whether it is functional or not. A great developer considers the long term consequences in addition to the short term goals.
Well, this is my option anyways. I’d welcome any thoughts and/or suggestions.
So until next time, good fight, good night.
- Descriptive JMX Beans in AEM/CQ
- Invisible requirements within Business requirements
- Building a better Options Predicate
- Extensionless URLs with Adobe Experience Manager
- The Life of a Tester in Adobe CQ World!
- Limitations of the CQ Parsys Model and the Implementation of a Nested Paragraph System
- Using Apache FOP to generate a PDF document based on a form submission data
- Configuring SAML in AEM 5.6