Editorials

Developer Skills Reader Comments

Developer Skills Reader Comments
Time to close out this topic with a few more comments from our readers. Writing about this topic, and reading the comments from many readers has confirmed to me that it is not just a specific toolset that makes you valuable. It is more important how you use the tools you have.

Seek those tools that provide transferable concepts.

Here’s a few more comments from our readers.

Tony
I didn’t see the thread you mentioned in your last email discussing which language to use so I apologize if some of this is redundant. But…I think the very notion of choosing the ONE best language to learn and practice is flawed in its very premise. To me this question was never even an issue. Even in various programming practices and models I find the notion to be somewhat ill-conceived. Please don’t mis-hear me; there are definitely "best" practice techniques that can serve very well in keeping code functional, bug-free, robust, readable/understandable and scalable. In my 20+ years of experience developing code, software development is not like math (an exact science) but rather like engineering where you solve a problem within acceptable error tolerances.

For example, if your goal is to read a simple 10-line XML file you probably don’t need to develop a server based SOAP protocol with schema validation, unless you have other requirements to do so or you reasonably foresee a need to build such a mechanism in the [near] future, i.e. making your design scalable.

You mention using VB vs. C#; which is better? Answer, depends what you need to do and/or what is available to you. Both utilize the .Net platform and to a large degree are interchangable. VB is good in that it simplifies many aspects of programming, such as COM development, and pretty much guarantees against memory corruption. C# has a syntax a little more cumbersome (to some) but does allow for things such as unsafe code (i.e. direct manipulation of memory) and unions. Both have a purpose and reason for being used in various situations. Java also fits here.

And let’s not forget good ol’ C/C++ (or even ADA). Some may argue that C/C++ is past its prime but I disagree. Unlike VB and C# which run on the .Net platform and utilize garbage collection, C/C++ is native and relies on nothing to run except the OS. This is obviously helpful when speed and efficiency are important such as in research, device drivers (remember the ‘volatile’ keyword?) or embedded system software on an airplane or rocket where responses need to be immediate and resources are limited. C/C++ doesn’t use garbage collection so the programmer can allocate/delete memory exactly when needed, no need to wait for a garbage collector. (Brief aside…even with Microsoft…most of its Office applications are written in C++ and do not use the .Net platform)

My philosophy has always been (and probably always will be) when choosing languages and design practices to do what makes sense for the challenge and restraints in front of you, take any reasonable steps to guard against error potential or code duplication, and design for flexibility and scalability where appropriate and where there is a reasonable expectation of need.

Bottom line, never say never and never (oops…;>) try to make a square peg fit into a round hole. Just solve the problem at hand within tolerances and do what makes sense (or cents)…

Sylvia:
Loved the tone of your article about extinct tools and languages. My first language was COBOL in the early ’70s.
Now that retirement is being tossed about, I just think about getting a part time job using COBOL….my first real love!
I made a left hand turn to go into DATABASE ADMINISTRATION for the last 25 years using SQL in all it’s forms….COBOL included.

Keep it real and thanks for your article.

Your comments and experiences are always welcome here at sswug. You can drop me a note at btaylor@sswug.org. Don’t forget we have our facebook page for you to join as well.

Cheers,

Ben

$$SWYNK$$

Featured Article(s)
The Procedural DBA (Part 4)
Although the functionality provided by SCOs is unquestionably useful and desirable, DBAs are presented with a major dilemma. Now that procedural logic is being stored in the DBMS, DBAs must grapple with the issues of quality, maintainability, and availability.

Featured White Paper(s)
Query Tuning Strategies for Microsoft SQL Server
Written by Quest Software

When you’re looking for a reliable tool to diagnose … (read more)

Featured Script
List index information for the current database
List index information for the current database… (read more)