Disclaimer: This post was actually meant to be a series of techie rants. I guess this deserve to be the first amongst others since I am compelled to talk about it more due to its reasonable application for developers out there.
Software Developers
I know a few who are good developers. But what does it take to be one? Sure, the manager creates a test. The test could go on like a 10-minute quiz of True or False (not to mention statements that you can alter); it could be a series of short brain puzzles; or a simple test to see whether you can really code or not. Heck, whatever the test is, its actually telling more of the manager (or whoever created the test), and will also tell what kind of people he/she wants to work with.
Its true that birds of the same feather flock together. You can't get a developer who thinks similarly and works as you do if he/she is 'not' more or less half as good as you think of yourself. Okay, I'm in. I passed the exam, but what will determine your greatness as a developer if not for the pressures of the real life tasks, right? Pressures during exams are terrible, but real life tasks are worst bitches (anybody who's been able to work knows that)
The answer is simple. Develop it good, clean and simple. Do what you do best.
In the book "Great Software Debates", Alan M. Davis states in the chapter "Requirements", subchapter "The Missing Piece of Software Development":" Students of engineering learn engineering and are rarely exposed to finance or marketing. Students of marketing learn marketing and are rarely exposed to finance or engineering. Most of us become specialists in just one area. To complicate matters, few of us meet interdisciplinary people in the workforce, so there are few roles to mimic. Yet, software product planning is critical to the development success and absolutely requires knowledge of multiple disciplines."
From Wikipedia
Software Development
If I'm a developer, don't expect me to design. I'm not good at that.
Its really a shame that since the most populated career sector nowadays is the IT field (aside from the medical courses that take people abroad.. errr away from their native land), more businesses tend to abuse skilled IT workers. Its really not a plus for the employee who knows a little of everything. Sure, who wouldn't want to show off a little of whatever their brain can take in? But, be sure to excel in only one field.
People will admire you for trimming down your priorities. Its not like your employer is going to love to show you off to the world when you're the best in his office.
Point is? If you're a developer, know software development, and excel at it.
Good Software Development
Thing is, SD, being such a highly conceptual topic inside the class is often neglected (not by the lecturers, but by the student). Computer Science related students would want to skip all the writing and reading stuff and tread along the coding process itself. Hmmm.. this is actually why these students would never end up as managers. :P
The truth is, most systems do not survive the IT lifeline because they have not really spent much time in planning and going through the tedious and boring process of Good Software Development. I'll go through the key parts of what I believe is a Good Software Development Process.
1. Planning. Project planning is everything. It involves all the "can-be-skipped-for-later" parts. From defining your project goal, to defining managerial process plans (budget, identifying man power needed, etc), to requirements gathering. This is by far the longest and tedious part of a software dev't cycle.
2. Specifications. A developer must also know how to do this. This may involve writing pseudocodes or even writing sample scenarios to simulate how a function or module will work. There may be different approaches/strategies for this, but to start out with a user-end scenario would be best. Its like telling a story on how the user will be able to use that feature. This way it won't be too complicated nor too simple. Jeff talks about specs here.
3. Coding/Implementation. This is the real excitement, the height of putting all thoughts into practice. This may get the largest percentage of work but not necessarily the most important (depends on the kind of project).
4. Testing. Here, the developer must also learn to create his/her own test. This is exactly why in the earlier software development cycle, testers are hired (to separate the coding from the testing). But, since the birth of object-oriented programming, more tools are offering testing tools. This is one of the reasons why I love rails, for it allows you to use a pre-generated test from your structure, or modify it as needed. Unit Testing allows the developer to assess whether the problem has really been solved or not.
5. Documentation. Bah! Every developer hates this process, but I believe that, "If it isn't documented, then it doesn't exist". That is why a good developer must always leave trails inside the code, or document everything as they go along. Jeff also gives a few tips on writing a technical documentation.
6. Maintenance. The planning stage must also involve a section for the maintenance. Here, it can definitely be rigorous and quite nasty (if it wasn't your code). The maintenance programmer might feel like cleaning up somebody else's mess. (Maybe that's why Jefft Atwood called it a Noble Art). But this is important for sustaining the life of that system.
..to be continued