The Demise of the Art of Programming

S

Scott Allen

We both spend enough time in here to know that a lot of what you say is
true. Sometimes it's a real downer, sometimes it seems like just a few bad
apples spoiling it for the rest...I'm sure the number of people I've helped
once (and only once) in this newsgroup exceeds the number of people I've
helped more than once. For me, this implies that most people are giving it
an honest go, which (for now) is enough for me to keep helping out. Maybe i
haven't been around long enough, but I imagine this has always been true:
some people are "lazy", some aren't. I don't think there are more lazy
programmes today than there were 5 years ago....and if there are, I wonder
if .Net's harsh learning curve has anything to do with it...

If you think this newsgroup is a downer - you should try the forms on
www.asp.net.

Sigh.
 
K

Kevin Spencer

That being said, I have a feeling the worst offenders all have
"developer" in thier titles....

Unfortunately, I have worked with enough to know that there is a lot of
truth to that statement.

--
HTH,

Kevin Spencer
Microsoft MVP
..Net Developer
What You Seek Is What You Get.
 
G

Guest

I agree with you on some counts - but much of it may be the business
constraints required today. It used to be developers took assembly, then C,
and then C++ and OOP. This took enormous investment of time, and the payback
was slow. That's my background and I'm glad I got it. However, in todays
world, you cannot stay in business with such as approach since it doesn't pay
off right away. It took awhile to be productive that way although the result
was a deep understanding of the OS internals many programmers do not have.
Take .Net for instance - a very productive tool which by nature obfiscates
the underlying OS internals like messages passed, memory allocation and
pointers. I can understand much more of .Net since I know the lower level
code - but I could never afford to pay someone to do the same unless we are
developing device drivers or video games. (Although I still am hesitent to
use access control structures in .Net - the Interop is UGLY!) Anyway, my
point is that developers are getting shorted some basics because of business
requirements and that may be why they ask for "solutions" rather than develop
their own - TIME.
 
G

Guest

....and there you have it.

When you have big managers that are clueless technically but want a 5,000
line web application completed, tested, ready-to-go in a *DAY* .... you get
real lazy real fast! >:)
 
J

JiangZemin

But it seems to me much more inefficient to be having to ask in newsgroups
for ready-made snippets of code, often for things which are so basic that
they indicate a complete lack of understanding of the basics (or basic
Googling), and which will usually end up being stitched together in some
random manner. I dont see how this type of laziness makes coding or
testing any faster.

Its too simple to blame this on "technically clueless big managers". What
about technically clueless "developers"? If someone doesnt have time to
learn the basics then maybe they should try a different profession. That
sounds harsh, but would you represent yourself as an accountant just because
youve used Excel and Turbotax a few times?

I think the original post is really onto something. ie. more and more
"developers" who don't want to read a spec or a KB article because its "too
technical", just write the code for me please. And if your code doesnt work
then I'll post a complaint about how you dont understand what Im trying to
do, instead of me trying to THINK. So i would rename this thread "The
Demise of the Mindset of Programming".
 
K

Kevin Spencer

...and there you have it.
When you have big managers that are clueless technically but want a 5,000
line web application completed, tested, ready-to-go in a *DAY* .... you
get
real lazy real fast! >:)

I don't. I get OUT fast. That sort of thinking is "short term" thinking. You
get something done in the short term, and maybe you get it done for less
money. But in the long run, you pay much more for maintenance, support, and
upgrades. Personally, I'd rather suffer now, and coast later!

Remember, one has a choice about where one works. No more Dilberts for me!

--
HTH,

Kevin Spencer
Microsoft MVP
..Net Developer
What You Seek Is What You Get.
 
K

Kevin Spencer

Thank you, JiangZemin, for everything you said. I happen to agree with you.

What is programming, if not problem-solving? If one is not into
problem-solving, one should find a career which doesn't require it.

--
HTH,

Kevin Spencer
Microsoft MVP
..Net Developer
What You Seek Is What You Get.
 
G

Guest

Hi there,

Thought I would reply to this particular message in this thread, as it seems
to be a balanced view of the initial thread topic.

I found this thread rather interesting, as I currently am deciding which
programming route to take for a forthcoming project. The original discussion
and questions posed by Kevin appear to fairly accurately sumarise the current
trend in forum questions. That is, it would seem that some people (whether
developers or newbies) appear to be searching for a quick solution to their
problems rather than searching for education. If I may pose some thoughts...

Perhaps we must ask ourselves, is the trend related to changing attitudes of
programmers (i.e. laziness), or due to the fact that the trends in
programming environments themselves foster visual/quick/shortcut approaches
to overall solutions, or due to higher, faster, more demanding expectations
on producing solutions by clients/managers, or just due to some obscure trend
centred around the fact that possibly the current crop of users that tend to
ask questions in 'forums' also tend to be those that don't read
manuals/books/help-files and are therefore not the sort to actually want/need
to understand the solution but would rather just have the solution?

To be honest, I know not the answer, and perhaps it is a combination of all
the above, and then some. However, I find myself now asking what do I want. I
am new to .Net. I look at a piece of code on the screen and wonder 'where has
the art gone from code', if only because the code looks so disjointed and
fuzzy.

I was a beginner programmer from the later seventies, working on Z80 and
other 8-bit processors in assembly language... now, 'that' was art! A big
improvement, to help find 'solutions' was when we all moved not just to
assemblers, but 'macro-assemblers'. Then I moved on to working with other
higher level languages, that eventually allowed me not to just write code,
but to 'design visually'. Then we were given 'components', nice ready made
'object's that provided 'solutions' for me out of the box. Then, we came to
the challenges presented by the 'stateless' web, just to add to the
confusion, and again, better IDEs and components solved these larger problems
for us. Thus, maybe what we have created is a solution-providing
envirionment...

I was doing fine with ASP until I finally decided recently to take a step
into what used to be the future and is now the present, the .Net platform. So
now, where as before I could just string together a few 'increment register,
roll-right bit rotations, etc) in machine code, to using someone's macro to
do some high-level task of 'sending an ascii character to the screen', to
using a set of a few easily understood and remembered commands that allowed
me to build some higher level routines to do this or that to a string or
apply that function to a date, now, and this is what is frightening, it seems
I need to try and remember the 4500 odd 'class' thingies that .Net has for
me. It all looks so complicated, maybe it is no wonder I might have the
necessity, or temptation at least, for someone just to give me a solution, as
the learning curve looks steeper than ever before...

It seems that where as we might have had ten string functions and statements
to do 'all' we had to do with strings, now there are specialised string
classes to do loads of specific things, and now I need to learn each one! How
loveley...

My point, and there is one, is that the environment at the moment has lead
to the language itself being more complicated than before, more powerful, but
certainly it takes a lot more to learn. Plus, we have created tools that
allow for 'bolt-on' solutions', encouraging people to 'buy solutions off the
shelf' And finally, we have the technology available that allows people to
ask 'silly questions', using forums, to try and squeeze out an answer, as
even posing a well-thought-out search phrase in Google is harder than just
asking an expert for an answer, let alone going to the manuals for help.

This is the environment 'we' have created. However, the culture can be
changed, but not be those asking the questions, but by those that are
answering them. Give guidence towards how to 'find' the solution, not give
the 'solution'. Then we will help breed better programmers.

And those that can't get their solutions from a forum anymore may just start
reading books again...

Cheers.
 
K

Kevin Spencer

I couldn't agree more, Cass!

--
HTH,

Kevin Spencer
Microsoft MVP
..Net Developer
What You Seek Is What You Get.
 
G

Guest

Ma'am, Sir,

There is so much to sort through in life already and our work as programmers
of the world's computer programs is only one of the many interesting things
to do in life.

When a new programmer arrives on the scene the human soul inside the shell
of socio-economic-materialistic person must look deep (deeper than that)
within themselves and decide what is and is not art to them. Everyone sees
art in a different way much as Mr. Henry David Thorreau described us all as
'stepping to the beat of a different drummer'. Perhaps we should all just
wait and see where time and the future really takes each of us and just look
at all the different kinds of art along the way deciding each for ourselves.

Mr. Charles Moore in his brilliance set the world, especially Intel on a
path of excellence that is nearly unbridaled. Every single day all over the
earth many (more than that) computer hardware engineers work with a very
strong (stronger than that) sense of motivation, dedication and purpose.
Their hard work is what makes Mr. Moore's law a reality. If they were lazy,
the demise of computer programming could perhaps take place, but they are not
and for that I love them dearly.

Think of this: today, it is the 25th day of the month of March in the year
2005 and the fastest Dell PC in the catalog on my desk that was mailed to me
from Dell.com states that a 3.2GHZ CPU is the fastest machine sold by
Dell.com. Now think that is the year 2007, Moore's law states that we can
expect 6.4GHZ. Again, it is now 2009 and we are at 12.8GHZ. Keep going on
your own and discover like I did that every 20 years we add three zeros to
the cycles-per-second HERTZ measurement-number meaning that in the year 2025
3,200,000,000,000 will have replaced the 3,200,000,000 which is to say that
3,200GHZ will exist in the year 2025 and 3.2GHZ exists today in the year
2005. That means that in the year 2065 which will be three years away from
my 100th birthday since I was born in 1968, the fastest CPU on earth may very
well be 3,200,000,000,000,000,000 or 3,200,000,000GHZ which means that we
ancient programmers way back in the year 2005 will hardly be thought out or
remembered anymore than the ASSEMBLY language programmers of the 1960s are
thought of by C programmers or C++ programmers or Java programmers or C#
programmers or BASIC programmers today. Time changes everything. It is no
one's fault, it is simply the progress of human kind observed by us mere
mortal human beings. I like quoting movies to make points so I ask you to
remember the movie "THE LION KING" remember the line ..."The Circle of Life"
so it is for us too.

If Moore's Law holds true which is as likely as it is not likely for the
sake of history supporting Moore's original observations, consider then that
programming and the nature of programming or rather the art of programming
computers will also change. Already the nature of code has really changed
incredibly since the early days of Altair BASIC and Q-DOS. Back then very
few people worried about anything other than MACHINE or ASSEMBLY languages
because CPU speeds were very, very, very, very slow compared to today speeds.
Consider that an Intel 486/25mhz or 25,000,000 cycles per second existed in
about 1991 and that Intel released 286 and 386 slower machines than the 486
only years earlier. RAM was very expensive and was very limited and very
expensive at about $100 for a stick of good 8mb memory or perhaps a deal at
16mb for $129.99. Today, 512mb of RAM in one stick where four slots usually
exists only costs about $79.99 on average in a retail store like COMP-USA.
Programmers in the 1950s and 1960s before had to really work hard to do
anything. The most clever text-graphic-creating COBOL programmers were
looked up to as they printed very long banners on dot matrix printers for our
offices at work. I remember how it really was. FLOPPY DISKS were humongous
and very flimsy. Today, CD-RWs and DVD-RWs and SD/MMC has greatly changed
non-volatile data storage.

In 1970, Dennis Ritchie and Brian Kernigham produced the first C language
compiler while working at Bell Laboratories. Since then, religious-like
stances on the art of programming have introduced themselves as sects or
divisions amongst the world's programmers. It is as sad as the Muslim vs
Christian vs Hindu vs Judaism vs Buddhism warring on earth today. We all
share voltage or no-voltage states of mind should we not celebrate that? Or
should we be devoutly C or devoutly UNIX or devoutly BASIC or devoutly JAVA
or devoutly C-SHARP? We should respect each other's opinions and celebrate
each other's accomplishments and try with every fiber of our being to
forgive/overlook each other's shortcomings. A pat on the back is worth
$1,000,000,000,000.00, a trillion dollars, to a working-class man or woman on
earth. Remember that, Mr. and Mrs. Corporate Executive! Remember that Mr.
and Mrs. Admiral/General/Military Officers! Remember that Mr. and Mrs.
Elected Official/Judge. Remember to pat your folks on their backs. Speaking
of, my wife just called and made sure that I end this shortly and return to
pat her on her back for all she does for me and my children. See what I
mean...folks, we need each other.

So, before I go, given a CPU's speed constantly increases over time while
also becoming less expensive over time, volatile-storage RAM increases in
capacity and speed over time while also becoming less expensive over time,
and that non-volatile-storage EIDE/SCSI/CD-RW/DVD-RW/SD-MMC, etc. increases
in capacity and speed over time while also becoming less expensive over time,
it is clear that we, the computer-software-engineers, PROGRAMMERS, have only
good things to look forward to with regard to the ART OF PROGRAMMING as the
future unfolds...that is, if we do destroy our wonderful planet, EARTH, by
any means.

All that I have said has not even mentioned the issues of the day which are
TCP/IPv4/IPv6/HTTP/HTTPS, XML, HTML, XHTML, TXT, CSV, TSV, CHTML, FELICA,
WML, AES, HDML, ASCII, UNICODE, UTF-7, UTF-8, UTF-16LE, UTF-16LE, BMP, GIF,
JPEG, PNG, SVG, MP3, WAV, WMA, MPEG, MOV, WMV, ASPX, MMIT_ASPX, ASMX, ASCX,
C, H, CPP, DLL, JS, CS, VB, EXE, CE_EXE, DIRECTX, ACTIVEX, COM, OLE, SOAP,
WSDL, DISCO, UDDI, and on and on the list of important file types, standards,
technologies, acronyms goes on into time.

I believe that their is something preciously primitive about the acronym
BLIDSSS which is to say:

B oolean
L ong
I nteger
D ecimal
D ouble
S ingle
S hort
S tring

meaning that BLIDDSSS is a way to say that in the year 2065 when central
processing units or CPUs are going 1 million times faster than they are today
that those fast little brains will still be dealing with BLIDDSSS primitive
data types which by the say are defined by the Microsoft .NET Framework and
not by me.

I did purchase BLIDDSSS.com intending to illustrate what exactly I mean and
will do so to the best of my ability.

I have said what I came to say as honestly and intelligently as I can. I
rest in peace.

Thank you for your time and to all of the people who have written books or
helped me along the way I thank you all.

Respectfully,

SmartWebAgent
John Flaherty
(e-mail address removed)
http://www.smartwebagent.com
 
K

Kevin Spencer

Wow man, .... the colors!....

--

Kevin Spencer
Microsoft MVP
..Net Developer
What You Seek Is What You Get.
 
L

Lucas Tam

Sure, but on the other hand, if someone had told you to read the SDK
on RegisterStartupScript, you would have learned all about it, such as
where in the page it goes, and why, and you could have learned about
RegisterClientScriptBlock, and the other cross-references as well.

True, but the connection between setFocus and RegisterClientScriptBlock may
not be there, because the OP might not of had javascript experience.
 
G

Guest

Alas, I see three other trends that are helping to fuel this trend.

1) Tools are promoted as solving the problems of application development,
and making it easy for anyone to produce working systems rapidly. So when the
tool doesn't take care of everything, there is a feeling that its not
necessarily your fault.

I remember looking at Oracle Designer several years back. I noticed that
books on it had a similar structure. Half of the book showed how to use the
diagrams and dialog boxes to build 90% of you database application in 10% of
the time. The other half of the book covered PL/SQL programming, which is
what you needed to use when you couldn't just drag a field from the database
schema onto a form, but needed some real edits or business logic. The .NET
framework, tools and application blocks tend to have the same problem. When
you get past the simple dialog box mapped to a basic table, you hit the high
learning curve.

2) As Bertrand Russell observed, part of the purpose of technology is to
push technical details below the level of consciousness. We turn the ignition
switch on our cars to "start" and don't worry about the technical details of
the engine. In the same way, very few of us are worried about CPU register
assignments nowadays--the compilers (and now the CLR/CLS or JVM) pushes this
below the radar screen.

However, as technicians, we are expected to be able to drop below the radar
screen and solve technical problems. Unfortunately, the environments also
fail to hide some of the low-level details, such as the need to differentiate
between String and StringBuilder in .NET.

Also, we get some false hype about how the technology solves problems, when
it may just shift them around. Garbage collection comes to mind here; it
prevents you from getting a "invalid address exception", but only because you
end up using an object that should have been deleted. Also, G.C. doesn't
prevent certain types of memory leaks.

3) The emphasis of education and training programs has shifted to
"practice"--specific technology, procedures and the mechanical use of the
tools. This is mainly a response to pressure from businesses on the
educational institutions to produce "better graduates" who can hit the ground
running.

I went through a Computer Science program 20+ years ago, and found that it
provided some theoretical background but left me little prepared for
professional work. Luckily I survived and learned. Unfortunately, the
pendulum has swung to the opposite extreme where many programs have gone the
other route, leaving people without any conceptual or theoretical background
and understanding, only a very brittle understanding of the basics.

Instead of teaching people to fish, we're teaching them how to assemble a
specific rod and reel, attach a specific lure, and cast for a specific type
of fish. Then when that species is all fished out of that location, they're
no better off than if we'ld just given them a fish in the first place. They
just cannot adapt to new conditions.

I suppose the only thing to do is try to make up for this in our responses
to postings. Try to enlighten them that they need to learn the basics of
programming.

Also, lets make sure our resumes make it clear that we know how to actually
program, and why it matters.
 
K

Kevin Spencer

Excellent points all, David!

--
HTH,

Kevin Spencer
Microsoft MVP
..Net Developer
What You Seek Is What You Get.
 
G

Guest

I completed my CS degree 7 years ago - C++ / Java was the go back then, C# is
my arena now. My boss's did a course for 6 months. I am always hand feeding
them solutions - simple ones at that - on how to solve relatively simple
problems.

I have to admit that C++ was the best thing I ever did as it taught me what
things cost, and with that what to do and what NOT to do at a higher level.
A lot of programmers these days (like my boss) have learnt their progamming
skills from a short course - got a certificate - and the rest is history -
well they don't even know what a GPF is (or how it is caused).

With my degree - we actually where tought about bubble sort algorithms,
addressing, pointers, heaps and stacks, etc. If I popped any of the
algorithms to my boss he would say 'wy do I want to know'. Well I would want
to know how a computer worked before I actually started using it? Would you?

Programming is an art - but I think also that the tools are also to blame
for this demise as they are isolating the developer from the real processes.
Not the .net is sheilding the developer - its actually lower level the VB6.0
- but things like the Visual Component Designer do hide internal workings.

Again, with my degree, it was communication / problem solving / logical
analysis, that actually counted towards my passing, not learning a particular
language, and due to this I can pick up most languages very quickly.

Kevin, you are correct in that there is a demise in programming 'skill' out
there - but hey - these days there are 2 types of developers:

1. A Developer.

2. Solution Architect

I class myself as a (2) Solution Architect, as I try to create a solution to
the problem - not just a code monkey developer.

Buzza
 
G

Guest

BTW smartwebagent,

CPU speeds are starting to flatten out - i.e. Not Going to get that much
faster, instead, core technology (Hyper Threading) is being used to
compensate for this more core's will be added to the processor (I think 3 is
coming out soon) - so if you have never needed to do multithreading due -
better get out the books as this is how you are going to have to make your
apps run faster in the future ;)
 
R

Rob Nicholson

coming out soon) - so if you have never needed to do multithreading due -
better get out the books as this is how you are going to have to make your
apps run faster in the future ;)

And the instant you wander into multi-anything, boy does it get a *lot*
harder. Quality control/test ramps up as well.

Rob.
 
G

Guest

Kevin:::

I read your initial post and have to weigh in on this issue. Don't be such a
frustrated idealist! Let me off another perception here for you to consider.

I believe Microsoft is slowly redefining what it means to be a software
engineer today. The evolutionary move in software engineering from writing
pure syntactical code to integrating UIs with logic code substantially
redefined what it meant to be a programmer and it will happen again with the
continued improvements of the .Net framework, namely, by increased managed
code and incorporation of new and improved classes, objects, etc.

I believe that today's programming technology paradigm represents a
parabolic curve of sorts. While memory management, addresses, multi-threading
and the like are becoming easier to program against, understanding and
programming against the complexity of abstruse relationships among and
between the objects in an OOP world is becoming much more challenging today.
(Yes, I believe that multi-threading will eventually become obsolete [by
advances made to processors either through biotechnology, nanotechnology or
both], and therefore unnecessary to achieve FUTURE optimal application
performance.)

This challenge is due in part to the colossal number of options, methods,
functions, objects, procedures, etc. which today's programmer has immediate
access. I suspect that these capabilities will continue to increase in
complexity as Microsoft advances its .Net technology. It is within this deep
divide that will ostensibly distinguish the "average" programmer from the
gifted one.

You can ask for and apply "canned" code all day to your application but if
you don't understand the SPECIFIC logic relationships that function among and
between ALL of your objects within a particular application, you will NEVER
rise to the level of programming talent that I believe will be required to
survive as a programmer in the next 15 years.

In many respects, computer programming today is limited only by the creative
potential of a human mind (that understands logic processes). Given this
belief, computer programming that achieves the highest levels of
computational functionality will always be more endemic of an art than a
science.

My 2 cents worth.

Brice Richard
 
K

Kevin Spencer

Hi Brice,

I'm not a frustrated idealist. I'm an idealist. Not sure what I should be
frustrated about! ;-)

If you think I'm frustrated with all the shade-tree developers out there,
I'm not. Less competition. However, my compassion moves me to help them in
some fashion. Hence, this (and other similar) thread. The original post was
intended to make people think, examine themselves, and see if they could or
should be doing better. Whether anyone DOES or not is not my responsibility,
and I happily recuse myself from it!

--
HTH,

Kevin Spencer
Microsoft MVP
..Net Developer
What You Seek Is What You Get.

Brice Richard said:
Kevin:::

I read your initial post and have to weigh in on this issue. Don't be such
a
frustrated idealist! Let me off another perception here for you to
consider.

I believe Microsoft is slowly redefining what it means to be a software
engineer today. The evolutionary move in software engineering from writing
pure syntactical code to integrating UIs with logic code substantially
redefined what it meant to be a programmer and it will happen again with
the
continued improvements of the .Net framework, namely, by increased managed
code and incorporation of new and improved classes, objects, etc.

I believe that today's programming technology paradigm represents a
parabolic curve of sorts. While memory management, addresses,
multi-threading
and the like are becoming easier to program against, understanding and
programming against the complexity of abstruse relationships among and
between the objects in an OOP world is becoming much more challenging
today.
(Yes, I believe that multi-threading will eventually become obsolete [by
advances made to processors either through biotechnology, nanotechnology
or
both], and therefore unnecessary to achieve FUTURE optimal application
performance.)

This challenge is due in part to the colossal number of options, methods,
functions, objects, procedures, etc. which today's programmer has
immediate
access. I suspect that these capabilities will continue to increase in
complexity as Microsoft advances its .Net technology. It is within this
deep
divide that will ostensibly distinguish the "average" programmer from the
gifted one.

You can ask for and apply "canned" code all day to your application but if
you don't understand the SPECIFIC logic relationships that function among
and
between ALL of your objects within a particular application, you will
NEVER
rise to the level of programming talent that I believe will be required to
survive as a programmer in the next 15 years.

In many respects, computer programming today is limited only by the
creative
potential of a human mind (that understands logic processes). Given this
belief, computer programming that achieves the highest levels of
computational functionality will always be more endemic of an art than a
science.

My 2 cents worth.

Brice Richard
 
G

Guest

I have found that the biggest problem with "clueless" management setting
unreasonable deadlines is not a problem with management. It's a problem with
the developer. Yes, I am saying developers are also responsible for their
own management. If a project's deadline is wrong, say so, whether it's
during the initial project discussion or during the course of development.

Doing so keeps your manager informed of the reality of development and
teaches them where to set their expectations. It also teaches them to adjust
fire where needed. We have all worked with that whiz kid developer who put
out a six-month team database project alone in two, only to quit later from a
rendering project in frustration. The first project set the bar that
couldn't be followed in the second.

I disagree with Kevin's solution of quitting. The solution should be to
talk with management. Become involved from day one, to include demanding to
sit in on meetings where your projects are planned. Developers need to
furnish that clue to clueless management...though I'll admit that demanding
5,000 lines of code ready-to-go in one day might indicate an incurable
condition.

Sorry, Slowly, I have to agree that there really is no excuse for asking for
someone else to figure it out for you. If you can't afford to buy the book,
look into all of the free APIs and other published information. If you're
asking for code, it's YOU who don't have a clue. Not your manager.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,755
Messages
2,569,536
Members
45,020
Latest member
GenesisGai

Latest Threads

Top