Hi there. My name’s J.T. Evans, and I’m an aspiring author that pays the bills with a Day Job as a lead software engineer. I started programming for my grandfather’s real estate rental business in 1980 when I was seven years old. All I had to assist me in my efforts were my trusty TRS-80 from Radio Shack and two books on how to program in BASIC.
Things are much easier these days, even with the growth in complex
technology. There’s this thing called the World Wide Web, which I’m sure you’re
aware of since you’re reading this on a web site. When I get stuck in my
programming efforts, I always turn to Google (and a few other resources, listed
below) to help dig me out of the hole that I’m in. It’s rare that I crack a book open
for research, but when I want to learn a new language or technology, I almost
always turn to a book on the topic.
So where to start in learning software engineering? The advice I’m going to
give you assumes that you know the basics of working a computer, but not much
Scratch. It’s packed full of tutorials, examples, and has a great user
interface for building out your programs. There are some limitations to it in an
effort to keep things simple for the beginner. Don’t be discouraged if you think, “Is
this all computers can do?” Once you’ve reached the limits of what Scratch can do,
it’s probably time to move on to a full-blown programming language.
Now comes the problem of which language to pick from. If you visit this
page on Wikipedia, you’ll see there almost 50 different categories of languages, and
hundreds to pick from! Don’t get overwhelmed. Many of those languages are for
specialized purposes or were created as a class assignment in college and were
released “into the wild.”
My suggestion is to use a language that is “object oriented” since you’ll
rarely find a programming job these days that doesn’t require that kind of
approach in development. Object oriented languages encourage properly
structured sets of information and the code that operates on that information to be
placed together. A good tutorial on the basics of object oriented programming
(OOP) can be found at Oracle’s tutorial site. The examples are written in Java, but are simple enough that the concepts can be ported to any decent OOP language.
Googling specific questions about OOP and its ideas can also help find more
Python. Python has
been around since 1991, is very robust, has tons of online support and books, is
supported by a wonderful community, and has countless libraries and modules
that you can put into play in your own code. It also runs on every major operating
system out there (and quite a few rare ones as well). There’s also a great
beginner’s guide as well.
I also recently found out that Python is the #1 language used in universities
for teaching people how to program. If you’re about to graduate high school, now
is a good time to jump into Python. If you’re still in elementary school, middle
school, junior high, or similar, then things might change between now and when
you hit college. That’s fine. I’ve personally gone through almost a dozen
programming languages in my life. That’s the exciting part of being a software
engineer. The learning and forward growth never stops! Almost everything I’ve
learned in one language has made it easier for me to pick up the next language and
run with it.
So, now that we’ve picked Python, how do we go about learning the
language? Well, I’ve already linked to the to the support, community, books, and
beginners guide. I’d suggest starting with the beginner’s guide, and when you get
stuck, jump into the documentation specific to the area you’re working in.
If the documentation confuses you, don’t get frustrated. Sometimes it’s
written by people that are so close to the topic at hand, they can’t see the flaws or
shortcomings in what they are trying to say. This is when I would suggest turning
to Google or other research resources. My favorite site for finding help from
others is StackOverflow. Just a word of advice: Chances are, someone else has
encountered your problem and asked a question that has a great answer attached
to it. Use their search to try and see if this has happened. If you can’t find what
you’re looking for, then feel free to ask away!
One thing I always do with a new language is to find a project to code. This
will push me to try things outside tutorials and walk-throughs. It will also keep me
interested in the process, as I will have a goal in front of me. Something I like to do
in new languages is to write a recipe catalog piece of software. It’s pretty
straightforward, but you can get really fancy with it if you like. It involves objects
(the recipes, the ingredients, the tools) and actions on the objects (add, delete,
adjust quantity, replace with another ingredient, search, sort, filter, etc.). Give it a
shot, and try to write something to track your recipes for yourself.
Once you have a firm grasp on the language of your choice, how do you take
things to the next level? This is where finding some “coding buddies” comes in. It’s
rare for a software engineer to code in isolation. More often than not, a software
engineer is on a team and must play well with others. This means dividing up the
work, writing specifications, sticking to those specifications, interoperating on a
personal and technical level, and hitting deadlines. Of course, this is describing a
work environment, but it also describes open source software projects.
Free/Libre Open Source Software (FLOSS) is a concept you may have heard
about, but just in case, I’ll describe it in brief. In the early days of computing, the
source code to software was kept super secret. This prevented people from
stealing, borrowing, or using trade secrets and such like that. This idea of keeping
things secret still exists in many industries and governments. However, in the early
1980s a movement started up to create software in which the source code was
shared with the world for all to use (with certain limitations) in order to improve
upon software capabilities.
In 1983 The GNU Project was started by Richard Stallman, who also went on to found the Free Software Foundation in 1985. With Stallman’s efforts joined with
many others, FLOSS became a reality. The efforts were mostly grassroots for
several years, and then Linus Torvalds released Linux in 1991, which ignited a
slow-burning fuse of open source innovation. By the end of the 1990s, open source
efforts were popping up every day. Today, there are countless projects in endless
areas that are open source.
My tip to you is to find a project that you can be passionate about. If you
find several, pick one. Just one. This will allow you to focus your efforts instead of
spreading yourself too thin. Most software projects have a bug list or a to do list or
a feature request list of some sort. Find those lists, and target something easy to
add or fix. Download the software’s source code from their open repository, and
get to work! Remember that a key part of contributing to an open source project is
communication. Contact the project maintainer and ask if you can help. Let them
know specifically what you would like to help with (name the feature or bug that
you would like to do) and ask permission to assist.
Most of the time, project leads are spread a little too thin, and they’ll gladly
take your help. The next step is to write the code according to the project’s
standards and to the best of your ability. Part of the software engineer’s life is
something called “peer review.” This means that a peer of yours takes a look at
your new code and finds places where it could be improved, altered, modified, or
fixed. They are not doing this to demean your abilities or efforts. This is to ensure
that the best possible product rolls out the door at the end of the day. Peer reviews
are a fantastic opportunity for learning. If the person doing the review does their
job right, they won’t just reject the code with a brief note. They’ll take the
opportunity to explain why the code needs to be modified. This will help you learn
and grow and improve. Take advantage of this. I’ve been programming for 34
years, and I still learn things from peer reviews.
If you can’t find a project that will take you on (which would surprise me),
then perhaps it’s time to find a mentor who will work with you individually to help
you grow and learn. Most large enough cities have one (or more) computer clubs
you can join and learn from. This is a great chance to meet like-minded people,
make some friends, and maybe find a mentor.
One final thought is that to tell you that software engineering is not
something you will learn overnight. It’s very much like chess. Learning how the
pieces move is relatively easy, but mastering the skill can take years of dedication.
I’m not trying to discourage you with the amount of work ahead of you, but to set
some expectations. This will help get you through the dark days when you seem to
write nothing but bugs (this still happens to me). Just look forward to those days
when you create something that runs just like you want it to! Those are the exciting
moments that I look forward to in my job of software engineering and in my hobby
J.T. Evans arrived on this planet and developed into an adult in the desolate,
desert-dominated oil fields of West Texas. After a year in San Antonio, he spent a
year in the northern tundra of Montana. This yearlong stint prepared him for the
cold (yet mild compared to Montana) climate of the Front Range of Colorado. He
has thrived in the Mountain State since 1998 with his lovely Montana-native wife
and newly created son. He primarily pays the bills by performing software
engineering and other technocentric duties. Like most writers, he dreams of
earning enough income via publications to drop the day job and prosper.