Jeff Atwood - Effective Programming. More Than Writing Code

Id argue that the people whoneedto learn to code will be spurred on most of all by honesty, not religious faith in the truthiness of code as a universal good. Go in knowing both sides of the story, because there are no silver bullets in code . If, after hearing both the pros and cons, you still want to learn to code, then by all means learn to code . If youre so easily dissuaded by hearing a few downsides to coding, there are plenty of other things you could spend your time learning that are more unambiguously useful and practical. Per Michael Lopp, you could learn to be a better communicator . Per Gina Trapani, you could learn how to propose better solutions . Slinging code is just a tiny part of the overall solution in my experience. Why optimize for that?

On the earliest computers, everyone had to be a programmer because there was no software. If you wanted the computer to do anything, you wrote code. Computers in the not so distant past booted directly to the friendly blinking cursor of a BASIC interpreter . I view the entire arc of software development as a field where we programmers spend our lives writing code so that our fellow human beings no longer need to write code (or even worse, become programmers) to get things done with computers. So this idea that everyone must know how to code is, to me, going backwards.

I fully support a push for basic Internet literacy. But in order to be a competent driver, does everyone need to know, in detail, how their automobile works? Must we teach all human beings the basics of being an auto mechanic, and elevate shop class to the same level as English and Mathematics classes? Isnt knowing how to change a tire, and when to take your car in for an oil change, sufficient? If your toilet is clogged, you shouldnt need to take a two week in depth plumbing course on toiletcademy.com to understand how to fix that. Reading a single web page, just in time , should be more than adequate.

What is code, in the most abstract sense?

code (kd)

1. A system of signals used to represent letters or numbers in transmitting messages.
2. A system of symbols, letters, or words given certain arbitrary meanings, used for transmitting messages requiring secrecy or brevity.
3. A system of symbols and rules used to represent instructions to a computer

The American Heritage Dictionary of the English Language

Is it punchcards? Remote terminals? Emacs? Textmate? Eclipse? Visual Studio? C? Ruby? JavaScript? In the 1920s, it was considered important to learn how to use slide rules. In the 1960s, it was considered important to learn mechanical drawing. None of that matters today. Im hesitant to recommend any particular approach to coding other than the fundamentals as outlined in Code: The Hidden Language of Computer Hardware and Software , because Im not sure well even recognize coding in the next 20 or 30 years. To kids today, perhaps coding will eventually resemble Minecraft , or building levels in Portal 2 .

But everyone should try writing a little code, because it somehow sharpens the mind, right?

Maybe in the same abstract way that reading the entire Encyclopedia Brittanica from beginning to end does . Honestly, Id prefer that people spend their time discovering what problems they love and find interesting, first, and researching the hell out of those problems. The toughest thing in life is not learning a bunch of potentially hypothetically useful stuff, but figuring out what the heck it is you want to do . If said research and exploration leads to coding, then by all means learn to code with my blessing which is worth exactly what it sounds like, nothing.

So, no, I dont advocate learning to code for the sake of learning to code. What I advocate is shamelessly following your joy . For example, I received the following email once:

I am a 45-year-old attorney/C.P.A. attempting to abandon my solo law practice as soon as humanly possible and strike out in search of my next vocation. I am actually paying someone to help me do this and, as a first step in the find yourself process, I was told to look back over my long and winding career andidentify those times in my professional life when I was doing something I truly enjoyed.

Coming of age as an accountant during the PC revolution (when I started my first real job at Arthur Andersen we were still billing clients to update depreciation schedules manually), I spend a lot of time learning how to make computers, printers, and software (VisiCalc anyone?) work. This quasi-technical aspect of my work reached its apex when I was hired as a healthcare financial analyst for a large hospital system. When I arrived for my first day of work in that job, I learned that my predecessor had bequeathed me only a one page static Excel spreadsheet that purported to analyze a multi-million dollar managed care contract for a seven hospital health system. I proceeded to build my own spreadsheet but quickly exceeded the database functional capacity of Excel and had to teach myself Access and thereafter proceeded to stretch the envelope of Access spreadsheet capabilities to their utmost capacity I had to retrieve hundreds of thousands of patient records and then perform pro forma calculations on them to see if the proposed contracts would result in more or less payment given identical utilization.

I will be the first to admit that I was not coding in any professional sense of the word. I did manage to make Access do things that MS technical support told me it could not do but I was still simply using very basic commands to bend an existing application to my will.The one thing I do remember was being happy.I typed infinitely nested commands into formula cells for twelve to fourteen hours a day and was still disappointed when I had to stop.

My experience in building that monster and making it run was, to date, my most satisfying professional accomplishment, despite going on to later become CFO of another healthcare facility, a feat that should have fulfilled all of my professional ambitions at that time. More than just the work, however, was the group of like-minded analysts and IT folks with whom I became associated as I tried, failed, tried, debugged, and continued building this behemoth of a database. I learned about Easter Eggs and coding lore and found myself hacking into areas of the hospital mainframe which were completely off-limits to someone of my paygrade. And yet,I kept pursuing my professional goals and ended up in jobs/careers I hated doing work I loathed.

Heres a person who a) found an interesting problem, b) attempted to create a solution to the problem, which naturally c) led him to learning to code. And he loved it. This is how its supposed to work. I didnt become a programmer because someone told me learning to code was important, I became a programmer because I wanted to change the rules of the video games I was playing , and learning to code was the only way to do that. Along the way, I too fell in love .

All that to say that as I stand at the crossroads once more, I still hear the siren song of those halcyon days of quasi-coding during which I enjoyed my work. My question for you is whether you think it is even possible for someone of my vintage to learn to code to a level that I could be hired as a programmer. I am not trying to do this on the side while running the city of New York as a day job. Rather, I sincerely and completely want to become a bona fide programmer and spend my days creating (and/or debugging) something of value.