Software Engineering Basics

Note: The target readers of this post are people who are first heading into the software industry. I wrote it because these are what I did not know when I entered my first job.

I have worked at Orion Health for just shy of two years, and here are a list of things that I find to be useful knowledge. Some of these concepts are trivial and are understood in minutes, but I hadn't heard of them in university so I'm noting them down here.

Code Reviews

Unlike university, at work, after you write code and want to check it in, you should get it reviewed (where I work this is a must). This is where someone else looks over the code you have changed, decides whether or not it is alright, and then allows or denies you the commit. This lets you have a second pair of eyes look over your code to check if what you have done is:

• well designed/written (clean code is really valuable)
• correct (you should have tests, but you may also have missed certain cases)
• does not contain anything malicious

Build Server

When working on a project, source artifacts have to be transformed into their built artifacts before they are used. Your source artifacts may be code, rich graphic formats, and so on. The built artifacts may be jars, static/shared libraries, executables, rendered graphics. A build server is a server dedicated to run builds.

A build is an automated process that is configured to retrieve the source artifacts (typically from a repository), run commands to build the relevant artifacts, and potentially run tests against them. Larger builds may deploy the built artifacts into a deployment environment. Builds can be scheduled to run periodically, whenever there is a change in the source artifacts (perhaps through repository polling), or manually.

Deployment Environment

A deployment environment is somewhere you put the output artifacts as they would be in the real world. This is just a computer that is set up as you would expect it to be on anyone's computer when they are using the software. For application developers, you may have multiple computers set up - each with a different version of an operating system (windows xp, vista, 7, 8; mac os; ubuntu), and you would try out your application to see if it works on each environment. For web developers, you may use multiple browsers of different versions to see if things look and behave correctly.

Tests

Tests are extremely useful. In university it seems pointless writing the expected output of your code given some input, but at that level, things are much easier than at work.

The faster a test can run, the quicker you get feedback, and fast feedback is highly valued. Tests may be unit tests which run against small sections of code, integration tests which test the interaction between modules, or system integration tests, which test the functionality of a fully deployed system.

Dependency Management

Software has versions. That's why there are software updates. If you are an application developer, you may be writing version A of your application, and you may be depending on version X of a library. After you release version A of your application, you start working on version B, C, D and so on.

One day someone discovers that there is a bug in library version X. Suppose in application version C you start depending on version Y of the library. This means that anyone with version A or B of your application must update to at least version C in order to have the bugfix.

This of course gets complicated when your software is made up of 10 layers of libraries depending on other libraries.

Support

Support is the part of work where you help someone turn on their computer. This role may also include:

• helping someone configure the software correctly
• figure out why the software isn't working
• telling someone your software doesn't do what they want

Typically this is the part of work that lets you experience how the users of your software are actually using it.

Issue Tracking

Issue tracking is a system which lets you track work. This may track bugs in your software, new features, documentation requests, and so on. See this eclipse bug for an example of a bug ticket using the Bugzilla issue tracking software.

---

There's more, but judging from my own attention span, a second post is more useful.


azriel

On Goals

Every one needs the basic necessities to live. A common and generic path is to find a job and live. But is the career that you take strictly in line with what you choose as your goals? Paraphrasing, disregarding all the routine life tasks, what do you wish to accomplish as your own? What are you doing with the time that you can call your own? Do these two align?

Here is a picture of what a week may look like for me:


look out for a future post on time

It is obvious the majority of my time is dedicated to work, but of the time I have outside of work and necessary happenings, my HeroQuest project and exercising both show up as regular activities. These are the actions I take to achieve two of my goals:

• create a game that is recognized globally
• keep fit

Understand that I did not take up software engineering to realize someone else's dream. I chose it to build my own. It is true that I have the option of working on the heroquest project full time. However, it is not a time-critical goal, and by working in an established software house, I have gained far more skills than I would have otherwise.

My point is that outside of my job, I have established goals, and am actively pursuing them. If all I do outside of work is relax, then my life would purely be defined by work. It is not negative, but working for someone else does not turn my own aspirations into reality.

If you do not already have a goal, or are not taking any actions to actually bring it to life, then please do so. The effort is worth it.


azriel

On Git

More geared towards a technical audience, I have recently been using git at both work and for my hobby project. Initially I was reluctant in moving away from subversion, but after a 2 week experience of using git, I can say it's not that much of a jump.

It's not difficult to find the commands to execute - there's good documentation, and stack overflow provides nearly all the answers. The more challenging part is getting used to vi.

Try git.


azriel

On Handwriting

azriel

On Faith

The point of this post is to answer why I choose my faith, not a statement of whether or not I am a proper christian.
This does not address whether science brings us further than religion.

When we are young, we readily believe most anything we are told. As we get older, we learn to rationalize, and decide whether or not to believe in things based on what we already know, who the person is that is presenting, and how the information is communicated to us.
Faith is to believe in something imperceptible. The first question is to answer whether or not there is a god.
Here's a list of arguments that are sufficient to convince me of the existence of one or more divine beings:

• there must have been a starting point for everything (stack error argument)
• intelligent design (creation rather than chance)
• natural conscience/morals
• human intelligence above animals

The next question is which "truth" is the real truth. Some of these have gods for things that express power or glory (e.g. sun, moon, war), or human desires (e.g. love, lust, food, wealth). Others argue that one's merit determines where they go after death. Christianity is based on forgiveness from a divine being, not merit or power. This point is crucial in my choice of faith in Christianity.

Forgiveness is something that has no personal gain. Apart from requiring humility, it is purely for the benefit of the one with the fault to know that even though they have done something they should not have, they are no longer held accountable (although there may still be consequences). So, when a divine being masterminds a plan in order to forgive his creations for their sins, I must believe this god as God.


azriel