I encountered this post on my weekend reading. 91 Surefire Ways to Become an Event Greater Developer contain a comprehensive guide linking to all sort of blog posts providing insights on improving your skills as a developer.

While the list is very long and sometimes debatable it does have some interesting pointers. If you do nothing else, delve into item #8: Learn Programming by Not Programming referring to the following post by Jeff Atwood.

The topic in question is why some developers outperform their peers regardless of their accumulated experience:

But the dirty little secret of the software development industry is that this is also true even for people who can program: there’s a vast divide between good developers and mediocre developers.

A mediocre developer can program his or her heart out for four years, but that won’t magically transform them into a good developer. And the good developers always seem to have a natural knack for the stuff from the very beginning.

The answer lies in the quotes taken from Bill Gates remarks:

“The nature of these jobs is not just closing your door and doing coding, and it’s easy to get that fact out. The greatest missing skill is somebody who’s both good at understanding the engineering and who has good relationships with the hard-core engineers, and bridges that to working with the customers and the marketing and things like that.”

Eric Sink makes the distinction even clearer in You Need Developers, Not Programmers drawing a distinction between Programmers who are only excited about writing code and basically only care about doing that, and Developers who contribute to the software product in many ways.

The Great Programmer\Hacker Stereotype

You all know that guy (hell, most of us were that guy when we just started out, I know I was) – he has great technical skills, likes writing code and can spend hours within his IDE writing code that’ll make most of us scratch our head. Yet, he views the world only in one dimension – code. Business? that’s for the managers to figure out. Sales\Marketing? annoyances for others to take care of. Documentation? but the code is so obvious…Builds? Deployment? Configuration? …

Passion for code is a great quality. But as a specialist its all too easily digging yourself deeper and deeper into a skill you’ve already proven yourself to be capable at when you’d be better of using the time to cultivate other skills that are part of the process of making software – rendering yourself obsolete over time…

The great hacker is a one trick pony – he writes great code but that’s about it…
Most of these guys end up working alone as consultants or freelancers where they don t have to care about that other stuff, or they end up as programmers at some big firms where there’s more room for specialists doing specific jobs (Architects to architecture, PMs do project management, Programmers code…).
On the other hand, those who truly like making software, open up to the other aspects of software development.
When that change in mindset happens, that’s when you can truly grow exponentially…

So what do I do?

Ok, I guess you got the point… But how do you get started?  Here are my own 5 cents on the topic…

Read, Read and Read Some More…

We’re in an industry that is moving forward at a fast pace. Technology becomes obsolete every year and a half or so and as developers we have to constantly struggle to keep up. Books are not only great to help you keep up but also to expand your knowledge to other fields.
There are plenty of interesting books and blogs about, well, pretty much everything.
Here are some recommendations to get you started:

The Inmates Are Running the Asylum	The Pragmatic Programmer	Made to Stick	Crossing the Chasm	The Innovator’s Dilemma	Eric Sink on the Business of Software
					(most of it is available online here)

Oh and one word about programming books: the best ones are timeless, transcending choice of language, IDE and platform.
I try to stay away from them thick, heavy, language\platform specific references – most of them go out of date after a year or so anyway and most of the information there could be easily obtained elsewhere (online – Google, the product’s docs, blogs…)

Most programming big are just a waste of your time (and money…)

Contribute to an Open Source Project

Back in the days of Delphi I was involved in Project JEDI dedicated to exposing different APIs (especially the Win32 API) to Delphi developers.
I learned a lot working with the JEDI code base, documentation, samples and other team members.
Later when it was time to get drafted to the Israeli Army (we all have to do it at 18 here) the experience, credit and code samples help me land a (very) exclusive position as a programmer. Who knows where I’d be today if I didn’t qualify and had to serve as a combatant…

Contributing to an open source project is a great way to gain experience, learn and get better.
There are no job interviews to pass, degree requirements or commitment to working hours or schedule required – you can just join in and start submitting patches or contribute in ways other than code (submit bugs, docs, support, …).

You can learn a lot just from studying the code and interacting with your peers…

Contributing to open source shows dedication and passion – its a walking talking resume.

Get a mentor

Find yourself a mentor or mentors who can teach you about different aspects of the business. I’ve had several at SAP and talking with them proved to be an invaluable asset (If you’re reading, thanks! )

It doesn’t have to be official mentoring which is part of the person’s goals or job description. Many of your peers are experts in their field and they’ll be happy to show you around if you just show some interest…

Become a Mentor

Great developer are eager to learn… and teach. Can you pass you passion and knowledge to others?

You can also…

• Open a blog about your experience, opinions, etc.
• Start answering questions at stackoverflow.com and collect achievements

Land an Internship

Try getting an internship in a different role. When I was in SAP they had a special program allowing employees to apply for a ~6 month position somewhere within the company. The reason behind it was to get employees familiar with different aspects of the company. Maybe product management, marketing or sales in not really your first choice of profession but why not try it for a couple of month without the risk of going through a career change? How cool is that? I’m sure many large corporations has something similar and even if not, it can’t hurt if you come up with such an interesting offer to your boss…

Own a Product Area

Get ownership on some part of the product your team is working on. Weather a specific component or a vertical (like Security) you should be in charge of getting it done – from getting the definition done with the product\sales\business team, through UX, development, QA, etc…
There’s nothing better than learning about the process of software development through experiencing the entire cycle…

Innovate

Start something new. When working on Duet we’ve had many issues getting the thing deployed. So I made a tool for (myself mainly) our QA and RIG (regional implementation group – the guys who work with customers) to help diagnose problems. This later became the official Duet Support Tool and got its own dedicated development time. Is your product, development environment perfect? I’m sure not… find a need a feel the gap…

Why? If by owning a product area you learned about the entire development cycle, here you’ll learn about defining and “selling” to the team…

Bonus Reading…

Another link worth visiting is the one about the Metrosexual Developer. Funny and true…

Related:

• So you want to be a great developer?

Tags: Programming, software development, Tips

I was on a phone interview the other day where I was asked for my definition of “Good Code”.

The first thought that came to mind was maintainability – if it can’t be understood, maintained and extended by other developers than its definitely not good.
Then, other things came to mind: efficiency, elegance (simple, proper use of language constructs and environment capabilities), modularity, proper object-oriented design, …
Of course, and we tend to take that for granted, it also has to work… without errors, security holes, etc.

In his book, Code Complete, Steve McConnel supports my definition of good code as maintainable code:

Another theme that runs throughout this book is an emphasis on code readability. Communication with other people is the motivation behind the quest for the Holy Grail of self-documenting code.

The computer doesn’t care whether your code is readable. It’s better at reading binary machine instructions than it is at reading high-level-language statements. You write readable code because it helps other people to read your code. Readability has a positive effect on all these aspects of a program:

• Comprehensibility
• Reviewability
• Error rate
• Debugging
• Modifiability
• Development time—a consequence of all of the above
• External quality—a consequence of all of the above

Readable code doesn’t take any longer to write than confusing code does, at least not in the long run. It’s easier to be sure your code works if you can easily read what you wrote. That should be a sufficient reason to write readable code. But code is also read during reviews. It’s read when you or someone else fixes an error. It’s read when the code is modified. It’s read when someone tries to use part of your code in a similar program.

…

Making code readable is not an optional part of the development process, and favoring write-time convenience over read-time convenience is a false economy. You should go to the effort of writing good code, which you can do once, rather than the effort of reading bad code, which you’d have to do again and again.

On the other hand, Paul DiLascia, from MSDN’s {END BRACKET} column, provides a list of traits that good code should have:

Whether you code in C/C++, C#, Java, Basic, Perl, COBOL, or ASM, all good programming exhibits the same time-honored qualities: simplicity, readability, modularity, layering, design, efficiency, elegance, and clarity.

Simplicity means you don’t do in ten lines what you can do in five. It means you make extra effort to be concise, but not to the point of obfuscation. It means you abhor open coding and functions that span pages. Simplicity—of organization, implementation, design—makes your code more reliable and bug free. There’s less to go wrong.

Readability means what it says: that others can read your code. Readability means you bother to write comments, to follow conventions, and pause to name your variables wisely. Like choosing “taxrate” instead of “tr”.

Modularity means your program is built like the universe. The world is made of molecules, which are made of atoms, electrons, nucleons, quarks, and (if you believe in them) strings. Likewise, good programs erect large systems from smaller ones, which are built from even smaller building blocks. You can write a text editor with three primitives: move, insert, and delete. And just as atoms combine in novel ways, software components should be reusable.

Layering means that internally, your program resembles a layer cake. The app sits on the framework sits on the OS sits on the hardware. Even within your app, you need layers, like file-document-view-frame. Higher layers call ones below, which raise events back up. (Calls go down; events go up.) Lower layers should never know what higher ones are up to. The essence of an event/callback is to provide blind upward notification. If your doc calls the frame directly, something stinks. Modules and layers are defined by APIs, which delineate their boundaries. Thus, design is critical.

Design means you take time to plan your program before you build it. Thoughts are cheaper than debugging. A good rule of thumb is to spend half your time on design. You need a functional spec (what the programs does) and an internal blueprint. APIs should be codified in writing.

Efficiency means your program is fast and economical. It doesn’t hog files, data connections, or anything else. It does what it should, but no more. It loads and departs without fuss. At the function level, you can always optimize later, during testing. But at high levels, you must plan for performance. If the design requires a million trips to the server, expect a dog.

Elegance is like beauty: hard to describe but easy to recognize. Elegance combines simplicity, efficiency, and brilliance, and produces a feeling of pride. Elegance is when you replace a procedure with a table, or realize that you can use recursion—which is almost always elegant:

int factorial(int n) {   return n==0 ? 1 : n * factorial(n-1); }

Clarity is the granddaddy of good programming, the platinum quality all the others serve. Computers make it possible to create systems that are vastly more complex than physical machines.
The fundamental challenge of programming is managing complexity. Simplicity, readability, modularity, layering, design, efficiency, and elegance are all time-honored ways to achieve clarity, which is the antidote to complexity.

Clarity of code. Clarity of design. Clarity of purpose. You must understand—really understand—what you’re doing at every level. Otherwise you’re lost. Bad programs are less often a failure of coding skill than of having a clear goal. That’s why design is key. It keeps you honest. If you can’t write it down, if you can’t explain it to others, you don’t really know what you’re doing.

So what are the most important trait for “Good Code” ?
Later on, it struck me – like anything when it comes to engineering, its about balance.
When we write code we strive to find balance between complexity and simplicity by constantly evaluating the different tradeoffs we have to choose in order to get there.
Therefore, good code is code that strikes the right balance balance between all of the qualities mentioned above.

Think about it the next time you’re writing or reading someone else’s code…

Comments (2) imported from www.ekampf.com/blog/:

Tuesday, July 01, 2008 1:01:39 PM (GMT Daylight Time, UTC+01:00)

“On the other hand, I was using Google software – a lot of it – in the last year, and slick as it is, there’s just too much of it that is regularly broken. It seems like every week 10% of all the features are broken in one or the other browser. And it’s a different 10% every week – the old bugs are getting fixed, the new ones introduced. This across Blogger, Gmail, Google Docs, Maps, and more. “

As much I really like the simple but powerful UI of services like Gmail etc: Sometimes its really annoying to see bugs coming and going! The software seems never to get stable. And Google seems to be aware of this, at least they mark nearly all their apps with a BETA-tag
It would be interesting to hear something about the software development process. Do they practice things like unit-tests, continuous integration, code reviews, etc.?

Florian Potschka

Tuesday, July 01, 2008 1:25:41 PM (GMT Daylight Time, UTC+01:00)

Hey Florian,
According to this and this its seems like a one big community where each project is managed like an open-source project.
From experience, having developers dividing their time between several projects (that can be unrelated as the post says) doesn’t work well…
Not much public information on their internal practices though… not sure if its a good sign :S

Regards,
Eran

Eran Kampf

Tags: Code, interview questions, Programming, software development