Monday, July 21, 2014

Getting Started In Software Engineering - Guest Post

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 beyond that.

The core of software engineering is thinking logically since that’s how computers approach their day-to-day operations. Regardless of your age, I think the best place to start learning these logical chains of thought is a program from MIT called 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 targeted information.

Once you’ve outgrown Scratch and have gotten comfortable with the ideas of OOP, it’s time to pick a language. My suggestion is to go with 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 of programming.

About J.T.:
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.

No comments:

Post a Comment