Tower of Babbling

When I started coding at my first job almost 20 years ago, it was at an OS/2 shop using C and Presentation Manager. I had several different languages in college so I wasn't too phased by the 1-2 week C training course we got. What I wasn't prepared for was memory management, C style string handling, message-driven applications, just to name a few.

I began my dislike of C early with the insanity called string handling. I was pleased when I found out that Joel agrees with me. Although there are plenty of people who will defend how 'intuitive' the string functions are, I knew there were much simpler ways to manipulate strings as long as you didn't need one larger than 255 characters, in which case using a char* buffer would be fine. Writing apps in something other than C was dismissed offhand with statements like, "C is much closer to the metal", "You don't have the run-time bloat of other languages", or "You have so much more control with C" which almost sounds like a masculinity test or something. Think lumberjacks and "my chainsaw is bigger so only the strongest can use it" type argument. Nowadays, this type of behavior would remind me of The Code Monkey.

Even 2 decades ago, it was possible to call code written in one language to call code written in another; in school we called assembly graphics routines from within Ada code for one class assignment. Notable exceptions are running compiled code from within scripts or executing a system command from within compiled code; but rarely do we write a library in C++ to use in our Java app. When Java first appeared and it was still slow, I never understood the resistance to writing the main app in Java and moving the bottleneck code into some C/C++ dll and called using JNI. It's like we use the "language X sucks at a, b, and c so we can't use it" as a shield that keeps us from having to design multi-language applications.

So, after all these years, what keeps us from writing multi-language apps?

An Apprentice of His Very Own

In my career as a developer, I reached a point where the amount of work that needed to be done was much greater than I had time to do myself. Budget realities aside, there was a lot of coding tasks like writing more unit tests or keeping various diagrams up-to-date that would be tedious but easy to accomplish as long as a basic understanding of development was present. Wouldn't it be nice to be able to afford to hire your own apprentice? Someone maybe still in college who had some exposure to coding but was still wet behind the ears enough to keep quiet and learn by osmosis.

At the time, I had visions of a helper who could take rough UML diagrams, like from scratch paper or from a white-board session, and update the project documentation. As each change came through, they would create new versions and archive old ones like a file clerk from decades ago.

First off, a fresh-from-college developer might consider that type of work as beneath him or her. I'd argue that learning the processes is just as valuable as learning how to code. Did they learn about version control, shared builds or managing a large code-base in school? Of course not, but experience with those types of processes are what most junior developers lack.

Secondly, if your job is consistently repeatable enough to explain to an apprentice, why are you there in the first place? The apprentice is much cheaper and easier to replace. More than likely, you job is one of those ones which is hard to explain because it relies on your experience and training to understand how to approach the problem and the possible/practical solutions.

Usually I stay away from comparing software with construction but in this respect, iron workers have a similar problem: how to bring on new blood without getting anyone hurt or jeopardizing the project. Even the most junior iron worker needs to understand how to do his small part and stay safe. The head iron worker needs to trust that his men won't need explicit instructions for every task and that when a crisis erupts, they'll understand what the priorities are without having to stop and have a meeting.

So, what you end up needing is someone who wants to learn, has the patience to listen, the intelligence to follow directions, the determination to keep doing hard work even when they don't know the importance of their contribution, and the wisdom to understand that not all knowledge comes from a book. The next step is to think about how to carve up your work so someone can help you with it. That will have to wait for another day.