“To code or not to code, that is the question!”
Are We In the Software Industry Inadvertently Creating a Generation of Non-coders?
What do I mean? Let me start with a perspective as a programming tool developer. Yes, I design programming tools for other programmers, from GUI libraries to drag and drop Visual Designers. Especially with code libraries, one eventually has to make a decision of whether a requested feature is worth the effort. As a tool developer, if I listened to every single customers' request and added it to my products, my software tools would become bloated and overloaded with thousands of tiny, slightly useful features at the expense of features which add significant benefit to my customers as a group.
So in dealing with tech support for many different programmers, I often find myself telling some customers to just “code it themselves”. I tend to follow a simple rule, “if you can code a solution in 10 to 20 lines of code, there is little reason for me add someone's requested feature to my programming tools”.
But isn’t that an awfully hard line to take?
Actually, no and here is why. We may be inadvertently creating a generation of non-coders and it may be getting worse. Let’s look at how we are teaching programming to the young generation.
Programming is Not a Game, Not Play, But Work
To try to give children the idea that programming is easy and that anyone can do it, is simply not fair nor realistic. Why? Do we tell children, learning to be an automotive mechanic is easy and that anyone can do it ? Likely not. Why? Because any skill requires a degree of effort as well as aptitude. I may wish I could play the guitar like my brothers can, but that does not mean it would be easy for me to learn or even that I have the aptitude for it.
The same holds true with programming. Trying to teach programming through software which is little more than a game itself, does not mean we will harvest a bumper crop of new coders. It also should be noted that there is a big difference between being a programmer and an application builder. Application Builder? Yes, there are many software tools which allow one to build an application with little or absolutely no coding. They serve a purpose and many are very adept at using them. But let’s call them what they are, “application builders”, not programmers (coders). If you give a child software which allows them to create a real 3D application, with little or no code at all, it may excite them initially, but in the long run they will be more likely to get bored when real coding is required. It will be just too much effort for them. Now consider the children of the 1980s who were using their Commodore 64’s, which initially were challenging to do much of anything at all, who eventually learned how to “peek” and “poke” values in RAM, grasping the meaning is bits, bytes and nibbles. Then they learned how to push the limits of the built in BASIC interpreters, dabbling in machine language and reading magazines like the Compute Gazette to learn more. Some of today's excellent coders came from that generation.
Application Building versus Programming
Application building is a very important part of software development today, but the lines between it and programming is being blurred a bit too much today. Consider how some can program using just a simple code editor alone. There is very little overhead in a simple code editor IDE and its companion compiler. The IDE and compiler I currently use only takes up about 8 megabytes of disk space. The WIN32 API headers take up another 9 megabytes or so, for a total of less than 20 megabytes.
Now download some of the latest development tools, including some of the application builder tools available and notice that often such downloads range in the gigabytes. Why? Because users code little, but simply “select” objects and define properties. Such development tools may give one confidence as a programmer, seeing all the wonderful things they can do, but are they really writing software or are they simply application builders using advanced tools someone else did a lot of coding on? Now, there is nothing wrong with this and even programmers use third party libraries, but there is a catch here. If companies who create development tools cater to the application builders rather than programmers, a by product of this is bloated software. It may even mean more bugs in software. Application builders tend to prefer large complex prebuilt objects, rather than smaller building blocks which they have to combine together. The smaller “building block” approach is usually preferred by programmers who require only simpler libraries which do the really hard things, while the rest they like to code themselves the way they like it. This approach tends to produce leaner, smaller and faster software. There is an obvious difference here. While programmers tools may be lean and small, application builders tools are not just big, but often are huge. If the development environment requires gigabytes of disk space, can one really expect to produce small, lean and fast software from them?
Another byproduct of application builders is the endless class libraries they contain. Without intellisense in their IDEs, users would never get anything done with them, because they often have endless class libraries to do most everything. But if one spends most of their time selecting objects, setting properties and calling methods, how much actual coding are they really doing? All it takes is one buggy class and application builders come crashing down. As a long time programmer, one thing I have learned is that there is no such thing as 100% bug free software. Sooner or later, those nasty little bugs creep in when you least expect it. Now programmers have an advantage in that when something breaks, they often are very quick to try the task using different code. Good programmers are the ones who often find the bugs in the development systems they use and pass it on to others. Also don’t think that even operating systems are 100% bug free. Good programmers many times will find even the weaknesses in the operating system itself and find workarounds. Now application builders are stuck with what is provided in their development tool. If it is broken, they are less likely to find workarounds. One buggy class in a library can bring an entire application crashing down.
A Lesson from Needlepoint
Have you ever watched someone doing needlepoint? One's first reaction often is “how boring, just sitting there all day one stitch at a time”. But the end, results are often amazingly beautiful. One stitch at a time requires a special aptitude. So does real programming. Initially coding is boring, time consuming. But for those who are experts at it, the finished product is often amazing.
Now this does not mean application building has no place. It does, but it is important to encourage more to learn real coding. It should be boring at first. Just like when some of us first learned BASIC on our Commodore 64. Type, type, type and all I get is a PRINT “Hello”. When it gets boring is when the experimenters get started. Change this line of code and see what happens. Change that line of code and see what happens. Try this, try that. Is there a way to make this go faster? In time, a programmer is born. A coder, a programmer!
