Showing results for 
Search instead for 
Did you mean: 
Create Post

New Coder: Getting Started and Finding Your Path

Level 13

You've decided it's time to learn how to code, so the next step is to find some resources and start programming your first masterpiece. Hopefully, you've decided that my advice on which language to choose was useful, and you're going to start with either Python, Go or PowerShell. There are a number of ways to learn, and a number of approaches to take. In this post, I'll share my thoughts on different ways to achieve success, and I'll link to some learning resources that I feel are pretty good.

How I Began Coding

When I was a young lad, my first foray into programming was using Sinclair BASIC on a Sinclair ZX81 (which in the United States was sold as the Timex Sinclair 1000). BASIC was the only language available on that particular powerhouse of computing excellence, so my options were limited. I continued by using BBC BASIC on the Acorn BBC Micro Model B, where I learned to use functions and procedures to avoid repetition of code. On the PC I got interested in what could be accomplished by scripting in MS-DOS. On Macintosh, I rediscovered a little bit of C (via MPW). When I was finally introduced to NetBSD, things got interesting.

I wanted to automate activities that manipulated text files, and UNIX is just an amazing platform for that. I learned to edit text in vi (aka vim, these days) because it was one tool that I could pretty much guarantee was installed on every installation I got my hands on. I began writing shell scripts which looped around calling various instantiations of text processing utilities like grep, sed, awk, sort, uniq, fmt and more, just to get the results I wanted. I found that often, awk was the only tool with the power to extract and process the data I needed, so I ended up writing more and more little awk scripts to fill in. To be honest, some of the pipelines I was creating for my poor old text files were tricky at best. Finally, somebody with more experience than me looked at it and said, Have you considered doing this in Perl instead?

Challenge accepted! At that point, my mission became to create the same functionality in Perl as I had created from my shell scripts. Once I did so, I never looked back. Those and other scripts that I wrote at the time are still running. Periodically, I may go back and refactor some code, or extract it into a module so I can use the same code in multiple related scripts, but I have fully converted to using a proper scripting language, leaving shell scripts to history.

How I Learned Perl

With my extensive experience with BASIC and my shallow knowledge of C, I was not prepared to take on Perl. I knew what strings and arrays were, but what was a hash? I'd heard of references but didn't really understand them. In the end—and try not to laugh because this was in the very early days of the internet—I bought a book (Learn Perl in 21 Days), and started reading. As I learned something, I'd try it in a script, I'd play with it, and I'd keep using it until I found a problem it didn't solve. Then back to the book, and I'd continue. I used the book as more as a reference than I did as a true training guide (I don't think I read much beyond about Day 10 in a single stretch; after that was on an as-needed basis).

The point is, I did not learn Perl by working through a series of 100 exercises on a website. Nor did I learn Perl by reading through the 21 Days book, and then the ubiquitous Camel book. I can't learn by reading theory and then applying it. And in any case, I didn't necessarily want to learn Perl as such; what I really wanted was to solve my text processing problems at that time. And then as new problems arose, I would use Perl to solve those, and if I found something I didn't now how to do, I'd go back to the books as a reference to find out what the language could do for me. As a result, I did not always do things the most efficient way, and I look back at my early code and think, Oh, yuck. If I did that now I'd take a completely different approach. But that's okay, because learning means getting better over time and —  this is the real kicker — my scripts worked. This might matter more if I were writing code to be used in a high-performance environment where every millisecond counts, but for my purposes, "It works" was more than enough for me to feel that I had met my goals.

In my research, I stumbled across a great video which put all of that more succinctly than I did:

Link: How to Learn to Code - YouTube

In the video, (spoiler alert!) CheersKevin states that you don't want to learn a language; you want to solve problems, and that's exactly it. My attitude is that I need to learn enough about a language to be dangerous, and over time I will hone that skill so that I'm dangerous in the right direction, but my focus has always been on producing an end product that satisfies me in some way. To that end, I simply cannot sit through 30 progressive exercises teaching me to program a poker game simulator bit by bit. I don't want to play poker; I don't have any motivation to engage with the problem.

A Few Basics

Having said that you don't want to learn a language, it is nonetheless important to understand the ways in which data can be stored and some basic code structure. Here are a few things I believe it's important to understand as you start programming, regardless of which language you choose to learn:

scalar variablea way to store a single value, e.g. a string (letters/numbers/symbols), a number, a pointer to a memory location, and so on.
array / list / collectiona way to store an (ordered) list of values, e.g. a list of colors ("red", "blue", "green") or (1,1,2,3,5,8).
hash / dictionary / lookup table / associative arraya way to store data by associating a unique key to a value, e.g. the key might be "red", and the value might be the html hex value for that color, "#ff0000". Many key/value pairs can be stored in the same object, e.g. colors=("red"=>"#ff0000", "blue"=>"#00ff00", "green"=>"#0000ff")
zero-based numberingthe number (or index) of the first element in a list (array) is zero;  the second element is 1, and so on. Each element in a list is typically accessed by putting the index (the position in the list) in square brackets after the name. In our previously defined array colors=("red", "blue", "green") the elements in the list are colors[0] = "red", colors[1]="blue", and colors[2]="green".
function / procedure / subroutinea way to group a set of commands together so that the whole block can be called with a single command. This avoids repetition within the code.
objects, properties and methodsan object can have properties (which are information about, or characteristics of, the object), and methods (which are actually properties which execute a function when called). The properties and methods are usually accessed using dot notation. For example, I might have an object mycircle which has a property called radius; this would be accessed as mycircle.radius. I could then have a method called area which will calculate the area of the circle (πr²) based on the current value of mycircle.radius; the result would access as mycircle.area() where parentheses are conventionally used to indicate that this is a method rather than a property.

All three languages here (and indeed most other modern languages) use data types and structures like the above to store and access information. It's, therefore, important to have just a basic understanding before diving in too far. This is in some ways the same logic as gaining an understanding of IP before trying to configure a router; each router may have a different configuration syntax for routing protocols and IP addresses, but they're all fundamentally configuring IP ... so it's important to understand IP!

Some Training Resources

This section is really the impossible part, because we all learn things in different ways, at different speeds, and have different tolerances. However, I will share some resource which either I have personally found useful, or that others have recommended as being among the best:


The last course is a great example of learning in order to accomplish a goal, although perhaps only useful to network engineers as the title suggests. Kirk is the author of the NetMiko Python Library and uses it in his course to allow new programmers to jump straight into connecting to network devices, extracting information and executing commands.


Go is not, as I think I indicated previously, a good language for a total beginner. However, if you have some experience of programming, these resources will get you going fairly quickly:

As a relatively new, and still changing, language, Go does not have a wealth of training resources available. However, there is a strong community supporting it, and the online documentation is a good resource even though it's more a statement of fact than a learning experience.


Parting Thoughts

Satisfaction with learning resources is so subjective, it's hard to be sure if I'm offering a helpful list or not, but I've tried to recommend courses which have a reputation for being good for complete beginners. Whether these resources appeal may depend on your learning style and your tolerance for repetition. Additionally, if you have previous programming experience you may find that they move too slowly or are too low level; that's okay because there are other resources out there aimed at people with more experience. There are many resources I haven't mentioned which you may think are amazing, and if so I would encourage you to share those in the comments because if it worked for you, it will almost certainly work for somebody else where other resources will fail.

Coincidentally a few days ago I was listening to Scott Lowe's Full Stack Journey podcast (now part of the Packet Pushers network), and as he interviewed Brent Salisbury in Episode 4, Brent talked about those lucky people who can simply read a book about a technology (or in this case a programming language) and understand it, but his own learning style requires a lot of hands-on, and the repetition is what drills home his learning. Those two categories of people are going to succeed in quite different ways.

Since it's fresh in my mind, I'd also like to recommend listening to Episode 8 with Ivan Pepelnjak. As I listened, I realized that Ivan had stolen many of the things I wanted to say, and said them to Scott late in 2016. In the spirit that everything old is new again, I'll leave you with some of the axioms from RFC1925 (The Twelve Networking Truths) (one of Ivan's favorites) seem oddly relevant to this post, and to the art of of programming too:

         (6a)  (corollary). It is always possible to add another
               level of indirection.    
     (8)  It is more complicated than you think.
     (9)  For all resources, whatever it is, you need more.
    (10)  One size never fits all.
    (11)  Every old idea will be proposed again with a different
          name and a different presentation, regardless of whether
          it works.
         (11a)  (corollary). See rule 6a.  

I've avoided coding - I can do it, but it's not my "cup of tea."

But, more and more coding in some form or other is becoming almost a necessity for any area of IT.

Level 15

I think I have finally found a point in life to get back to my life in coding.  As a computer scientist coding has always been enjoyable to me.  Thinking it is time to freshen my skills.  I am fluent in PHP but thinking python needs to come to the top of the list.


I actually enjoy coding....cut my teeth on Basic, learned Pascal in college as well as some assembly (which I hated) and then various other scripting languages on various platforms (TACL, REXX, OPS/REXX, CL, BASH, c-shell, korn shell, perl) etc.  Perl has been my goto when possible.  It works as a CGI backend to a web page, standalone application, event processing (look at a perl application called SEC SEC - open source and platform independent event correlation tool ).  I have written 1000+ line  applications in perl that have solved requirement issues for PCI compliance back when there was not a tool  for the job. 

One of the things about coding is that knowing different languages gives you options and a differed perception which allows you to approach the problem from a different perspective.  Yo can think of various ways to solve the issue and then choose the correct language to use.

One thing about coding and having to support said code...keep it simple, granted it may not be a elegant and crafty for those who want the minimum lines, but you want both internal and external documentation.  The key here is it needs to be 3 AM friendly... Can you debug that 4 layer deep imbedded function call at 3 AM easily or do you code it out over more lines so you can see what you are getting at each step of the way ?  At 3AM the latter is easier to understand and trace.

Log your key steps in execution, log pertinent info so when something is amiss you have the data to figure out where it went awry...

Level 20

Interesting on how you began... for me it was Applesoft Basic on an Apple][+ computer but... the real learning happened when I went to summer school (I was 12) and learned to use Apple Pascal!  This we the first time I entered into what I'd call a real structured programming language... as many of you might remember Pascal was kinda a learning language with much more spelled out vs. C BUT!  It was the perfect lead into learning C.  After getting used to C the hardest part came in college... learning C++ and the idea of "object inversion"  No longer did we write just many procedures but now there were OBJECTS!  And with objects instead of functions we had methods!  C with class!  The principals of Encapsulations, Polymorphism, and Inheritance.

Oh and Jfrazier​ I loved assembly language... being a computer scientist is all about understanding what the machine is doing at the lowest hardware level and no one really writes machine code per se so assembly it is!  I always was in awe of really tight assembly language code... it doesn't get any faster than that!  It was one thing I really liked about C... you could just inline some assembly and let the compiler and linker figure it out for you.  Learning about lex, and yacc was fun!  Psydocode means you don't really learn any language but the fundamentals that underpin every language ie. algorithms.  All the rest is just syntax.

In college to kill two birds with one stone since I had the same professor for C++ and Algorithms I implemented a dictionary in C++ (also using templates so any data type could be passed) and stored the dictionary data in a red/black tree.  I was always fascinated by the different trees... hight balanced AVL tree was one that was tough... it always seemed the books would explain most of the parts of the tree functions but often left the delete OUT!  This is because the delete function in more complex in trees are NOT simple at all.


I had started with VAX was not great.  IBM assembly was better...

Level 20

I first learned assembly in college on DEC Vax!  We had to write some C and assembly and then link them as an exercise.  My assembly book was for a PDP-11 but we actually used newer DEC Vax.


DEC 11/780


Nice Write up


Interesting read. I started with BASIC on the original TRS-80. And yes, that is a cassette recorder for storage.

Image result for trs-80 model 1

TRASH-80??? I miss mine so! Did you have the cassette deck to load games? Did you ever play the game Volcano? It is still one of my all-time favorite games EVER! I found an emulator for it on the 'Net a few years ago but now its gone. Wow! Thanks for the walk down memory lane!!!

I took coding classes in college. I tried it and failed. I did a 3-day crash course study trying to comprehend Java and after 3 days it wasn't sticking. I was so frustrated I picked my chair up and threw it against the wall. It's legs stuck and the chair hung there. I knew I could never be a coder.

I admire your ability to break this stuff down and absorb it.

Level 13

BBC BASIC was somewhat unusual in that like C, it too allowed assembler (6502 assembler in this case) to be inserted within your BASIC code. I always thought that was a genius thing to have added, especially when dealing with a computer which was running relatively slowly (clocked at 2MHz).

Level 13

I do not miss cassette tape storage. Not for a second 😉  The ZX81 and the BBC both had cassette-based storage (though the BBC also supported 5.25" floppy drives if you bought the right ROM and the drive hardware), and I remember distinctly the annoyance in particular of waiting for Level 9's "Return To Eden", a text-based adventure which was much larger than the BBC's 32KB of RAM should have allowed, and it crashing at the last moment. The only up side to this was that to make the wait more tolerable, they added a loader which played music to you while the game loaded.

Specifically, they programmed part of Vivaldi's "Winter" from the Four Seasons, and I am consequently STILL enamored with that tune (in particular as played by Yehudi Menuhin and the Camerata Lysy). I maintain that whomever was responsible at Level 9 was a real music lover, and did a great job given that they only had three 3 note polyphony to play with (well plus some noises, but I'm not sure how useful those are). If you need something to take your mind off whatever you're doing (jump to 1m40s for the music to start):

Level 13

By the way, I never did manage to complete the game. Sad.

Level 14

I miss VMS and DCL!!!


I also learned basic on a trash 80 model 1 with the cassette...I think it was about 60 baud

Level 13

I think for a lot of engineers (but not all, of course), coding may be just another extension of the logical way they already work. Anyway, if you have managed to handle PHP without gnawing your own leg off, I think you'll do well with Python

Level 13

I see we are going to need somewhere to store all those sandals...