At this point, you’ve probably already read part 1. This means that you know the basics of what coding is. A better question is: Do you know how to get a job? Knowledge is only part of the battle in the software development industry. I’ve been using this great website called Pramp. Pramp is a website where you get paired with other people and do mock interviews. Technical interviews are very challenging. Pramp gives you what you need to succeed. On top of that, companies are using Pramp to find competent individuals for real jobs. People have used Pramp to get positions at Facebook, Microsoft, Twitter, and more! I promise you won’t be disappointed, so check Pramp out!
Can We Automate That?
One of the big reasons companies develop software is for automation. Automation is enabling something to happen automatically without you having to dork with it. With software, we can write an application that has code that will execute the same thing over and over again. This means that something that used to be a complex process can be made very simple using software.
The whole idea behind self driving cars is automation. I would argue that the reason self driving cars are most likely to sell is because of automation. Why would any modern, busy individual want to drive when they could automate the process?
Even the buzzwords like AI and machine learning are rooted in automation. For the uninformed, AI is artificial intelligence and allows computers to make decisions. Machine learning is a method of AI that let’s computers learn from historical data.
If I wanted to do something like fraud detection, no-one has to look at my transactions to see if something is phishy. Machine learning uses data to automate this process and say “Yes, this is fraud,” or “No, this is not fraud.” This means I can swipe a credit card and get approved or denied immediately depending on whether or not it’s likely to be fraud. Obviously, this is not perfect. Many of us will go on a trip, swipe our card, and get denied. That being said, I believe the process is still improving and is much better than other options. Automation is still more effective than manually checking for fraud or waiting till fraud is reported and having to deal with it then.
Automation software often has a very specific goal. This means that the software can often be refined to a point where the automation software is actually better than a human at a particular job. Not only because it’s faster, but because software is much less likely to make mistakes. This means that the software can do more of a job than a human could, allowing the company to scale. By automating processes, a company can focus on things of higher value (such as growing their company).
Another example of automation is when you sign up for a website you automcatically get a verification email for you to verify your account. This is another example of automation.
Software comes down to one question: What can I do to make the user’s life easier? The user in this case would be the customer, or the person using my software. 99.9% of the time, the answer is automation. As a software developer, I want to create software that does something that typically takes the user a long time and is cumbersome, but my software does it quickly with only a click of a button. If the value my software adds to the customer’s life outweighs the cost of the software, people will buy it! As a result, a piece of the software development life cycle is finding out a problem people have that software could easily fix. If I automate the process in code, I make a ton of money. That’s a very money-centric view of how typical software development works. I’m by no means trying to say that this is the only reason you should develop software, all I’m saying is you should expect to find that kind of attitude in the industry.
Software Engineer VS. Software Developer
As an aside, I wanted to briefly talk about job titles. Is there a difference between software development and software engineering? Short answer: no, not really. Long answer: kind of (read on).
There are a ton of job openings for both software developers and software engineers. At first glance, it seems they are asking for the same requirements: “Entry level software engineer, 5 years of experience required.” Or, you may find a position for a developer: “Entry level software developer, 5 years of experience required.” Either position you take, you’re more than likely going to be doing about the same thing. From what I’ve seen, a software engineering role is possibly harder in that you may be expected to have some knowledge of traditional engineering, you may also take a small step back and focus a bit more on software architecture, design patterns, “engineering” the solution, etc. That being said, many software developers do all of this too.
Why am I even bringing this up? I kind of forget why, honestly. But it’s good to know. The main thing to takeaway from this is that many use the titles software engineer and software developer interchangeably, but you may tend to hear software engineer when talking more about designing solutions than building something with a particular programming language.
The challenges of Engineering Software
We’ve talked about the why of software (💰💰💰), but now let’s talk about the how.
A software engineer is forced to generalize his or her solutions. I’ll do my best not to overcomplicate this.
Generalizing is when you try to think of every possibly input and output, rather than some specific example.
One big reason I am glad that I went through a traditional bachelor’s of science is that I received training in math that I would likely have never have pursued on my own. I went into the program thinking I would dread the math, but ended up benefiting a lot from the material and actually had really good grades in Math.
One takeaway I got from the math is that it helped teach me, practically, how to generalize.
If you think of something in math, such as f(x) = 2x, we’re saying that for any input, we get twice the output.
This is a general solution, rather than saying we input 2 and get 4, we say we input x, and get 2x.
This skill was practiced even more when I got to proofs. To prove some general rule, you have to think of how to prove that in the general case (meaning without the use of an example to prove your point).
I’m by no means saying that going through a bunch of math courses is the only way to succeed in software engineering. All I’m saying is it is a good way to practice techniques that directly translate to coding software.
Let’s look at generalization when it comes to input for our code.
Dealing with Input and Output
If you consider our code to be a black box (meaning all you need to worry about is the input and output), you’ll quickly see the vast number of possible inputs. A developer must not only consider what happens when the user puts in something expected, but also when the user puts something totally meaningless. This is especially true for applications that take user input in the form of commands or text.
There are multiple ways to deal with the possible inputs. The first way is to restrict input. The most common way of restricting input is by going from a CLI (command line interface) to a GUI (graphical user interface). A GUI is able to restrict possible inputs by giving the user a limited number of options to select from. This will work in many cases, but not all (specifically, don’t expect this to work with web development).
The second way to deal with the possible inputs is to validate every input. This is something not often required in school projects, so it is often not well taught. This means that if you expect a particular type input, you must check if the input is valid. If it’s not, the input is rejected and the user must be asked again for another input. Expecting a number? Reject strings. Expecting a a letter? Reject numbers. Etc.
Hard Coded Data
One thing that kills generalization is hard coded data or values. Something is hard coded when it is typed out in the source code. Hard coded values destroy generalization because once the software is delivered to the customer, that value is permanent. The only way around this would be to change the value in the code and deliver an update to the user.
Whenever possible, data should be placed outside of the source code. This can be done in a text file, some sort of configuration file, an excel file, a database, or asking the user a question. The hard coded value is then replaced with code that reads the value from the file or asks for user input.
In this situation, the configuration file is also delivered to the customer with the final software. We can change the way software works by changing the values in the configuration file instead of having to give them a whole new version of a software (imagine having to get a new version of Microsoft Word every time you wanted to change a setting).
Here is an example of hard coded data:
This is a better:
You can clearly see the potential for garbage input here. What if I put “pizza” as my name? It’s vital that we validate all input prior to processing it to do something useful.
Once we are able to take input, we can begin branching the possible paths in our program. For example, if we have a game that you must be 13 or older, we can ask the person for their age. If they say something less than 13, they are rejected, if they say greater than 13, they are given access. Branching is most easily done with an if statement.
As you begin to understand more on what coding is, how we write software, and how to design and engineer solutions, you’ll begin to see that the vast amount of knowledge required can be overwhelming. Because of this, I thought it would be useful for me to recommend some resources that could help guide you through the process.
Because this blog series is looking at general software development / engineering, I am listing some resources that will help you think about how software is built sucesfully, what things to understand when going into software engineering, and some of the top books for different types of projects.
For everyone – Cracking the Coding Interview. This single resource has helped me tremendously. Not only does this book go over technical questions and answers, but it gives a lot of context as to why technical interviews work the way they do. This summarizes the most important stuff covered in a 4 year computer science program. In my opinion, this content of this book is useful beyond the interview. I’d highly recommend it as the one resource to guide you through your computer science education. Although this book can be more challenging at times, it will at least be a good guide on what you should understand, which will ultimately help you know what you need to research.
For everyone – The Agile Samurai – This book was a tremendous help to me when I wanted to understand more about the software development lifecycle. It guided me on how to get actual software out the door. This is a great book if you need something to casually read as it is not very technical, but tremendously helpful! I actually listed to the audiobook.
For those interested in C – Programming in C – This book is a basic introduction that will guide you through coding in C. This is a great resource if you are interested in doing more lower level programming. By that I mean you are closer to the operating system and have a lot more to worry about. That being said, lower level programming often helps you understand things at a much deeper level. I’d highly recommend reading this for even only an hour a day. You will make progress on your understanding of C.
For those interested in C++ – The C++ Programming Language – Highly rated, highly known in the industry, I’d recommend this book to anyone who wants to really understand C++. It was authored by the creator of C++ (Bjarne Stroustrup). This would be a great read if you are interested in lower level programming with more universal capabilities (like object oriented programming).
For those interested in Python – Python Crash Course – This is a book that will give you what you need to know on Python. This would be a good place to start if you want to build applications but not get so tied up in all the syntax. Python is a perfect programming language for beginners as it is very intuitive and easy to read. Not to mention that Python is very popular and is becoming even more so with the rise of machine learning, deep learning, and other varieties of artificial intelligence.
For those interested in C# or Java – Murach C# or Murach Java – I own and have read numerous Murach books. One unique thing about these is that they break each section up into one page of text and one page of code examples. This makes going through the content very simple. I read through Murach C# from cover to cover and I loved it. It took me a really long time, but was totally worth it. Why would you want to go for C# or Java? Primarily because the language is C++ like in syntax and object oriented programming, but it is managed. A managed language deals with a lot of the memory with features like garbage collection. Not to mention C# and Java can be used for web development and various other solutions (such as Xamarin for cross platform mobile app development).
Lastly on the list we have Swift! Swift is the language for iPhone development. So if you’re looking to make the next big app, consider looking into learning Swift. The book listed is a great option because (at the time of this writing) you can get the kindle version for like $3.
And here is my video What is Coding Part 2:
I hope these resources are helpful. The journey here is not yet done though, check out part 3!