Do you spend part of your time writing programs or trying to learn how to program? As you read about the advanced techniques that experienced programmers are using, you may feel as anxious as a do-it-yourselfer making abortive attempts at installing a new plumbing fixture for the first time. In this column, Danny Faught describes how even seasoned programmers can be anxious about their skills, and he encourages you to forge ahead.
I am a programmer, by which I mean I can write programs that do useful things and usually finish the task within a reasonable amount of time. I hear about all kinds of interesting technologies and techniques that full-time programmers are adopting, but I'm just a part-time programmer. How can I hope to keep up with all of the new stuff?
Obviously there are challenges associated with being a part-time programmer, and we're going to explore some of them here.
I write programs in the course of building and using test tools. But I also do many other tasks typical of a toolsmith who has the additional responsibilities of manual and automated test execution and analysis. I take time to read about the latest programming techniques and technologies, but because of all the other things I also have to learn about, I haven't been able to read in depth about many of the new technologies or apply all the new techniques. I use several different programming languages and tools, which makes it even harder to keep up. It's enough to give someone an inferiority complex!
I have a computer science degree and twenty years of programming experience under my belt, so I know the basics of algorithms and data structures. But I realize that the state of the art changes rapidly. The challenge is even more acute for someone still learning programming basics in addition to other responsibilities.
The Hackish Engineer
My approach is a mix of the pragmatic approach of an engineer and the bold, curiosity-driven approach of a hacker.
When I'm trying something new, whether it's a programming language I've never used before, a new library, or just a new element of a language I know, the hacker in me gets me started. The Jargon File refers to a "hacker" as someone "who programs enthusiastically (even obsessively)" and "enjoys exploring the details of programmable systems and how to stretch their capabilities." Thinking in this mindset helps me to find creative solutions.
Once I'm on track toward a solution, I switch to the more practical engineer's approach. Yet my hacker side doesn't let go easily--it desires to learn the technology and to come up with an elegant program. The Jargon File says a hacker is the opposite of most users, "who prefer to learn only the minimum necessary." In order to get a programming task done in a reasonable amount of time, I often have to learn only the minimum required to make something work--which means not necessarily squeezing it down to the least amount of code and possibly not using the fastest possible algorithm.
We can find at least one quality that is shared by the engineering perspective and the hacker, as defined by the Jargon File: Both require "a person who is good at programming quickly."
Context Switching
As I switch between projects, I also tend to switch between different tools and the communities that support them. I sometimes do a context switch several times a week, which can be a bit jarring, but at least all the technologies involved are fresh on my mind. But be warned: When I put a program aside for several weeks, it's harder to come back up to speed on it.
Consider these tips to help with context switches:
- Join mailing lists where people help each other learn and troubleshoot the technologies you're using. Participate actively while you're using that technology on a daily basis. When you put a project on the backburner and no longer have the capacity to follow the discussion closely, switch to a digest subscription where you can occasionally scan the messages but not follow it as closely as before. Later you can turn off the digest mode, so answers to any questions you might ask will arrive quickly again.
- Tie up loose ends before you put something on the backburner. If you have started to isolate a problem, give it a coherent description and save it. If it's something you need help with, post the issue to a mailing list and save any answers you get so you can apply them later. When you're coming back up to speed on the project, you can search the archives of the mailing list for your own questions to see where you left off. If you don't save your context, you'll end up tracking down the same problem multiple times.
- Keep your code where you can find it--both the "ready for prime time" items and your one-off and experimental code snippets. Put as much under revision control as you can. You'll be very glad to be able to refer this code later.
Embracing Your Limitations
I need to be realistic about my limitations, especially when I compare myself to someone who is honing her programming skills full time. My code may be more verbose than it needs to be, slower than it could be, or it may take longer to get it working. I may not use all the common idioms of the programming language or the popular design patterns. But as long as I'm producing useful code, that's okay.
It's important to keep the scope of the programming project in mind. It takes much more skill to write a million-line program than a ten-line program. As a toolsmith, my programs tend to be small. So I'll leave the enterprise-class applications to the full-time programmers.
It's comforting to realize that practically all technical staff is affected by the part-time conundrum to some extent. System administrators often spend some of their time automating their tasks. Developers may be required to document requirements, conduct system testing, or help with technical support calls, all of which take them away from designing and coding. Even developers who are highly focused can't learn everything about the operating system, one or more programming languages and their associated libraries, and the nuances of the network.
It's never too late to catch up on what's considered state of the art. It wasn't too long ago that I started using object-oriented programming in earnest and realized how much more maintainable and reusable my automation code became as a result.
Take Heart
Thanks for letting me get my programming worries off my chest. I feel much better now.
We may feel anxiety about the technologies that we wield, but we shouldn't let that keep us from using technology to make great leaps forward in productivity.
References
The Jargon File
