This is your brain. This is your brain on computers.

6 Things Every Student Should Know Before Starting a Software Career

You know what they say about hindsight and vision: it’s 20/20. We didn’t have the luxury of reading this blog post before we started our careers, but you’re fortunate enough to have that opportunity. There are many things that every student should know before starting a software career, but we want to focus on the top six that we feel are requirements to being a good software citizen regardless of the projects on which you work.

It’s unfortunate that most information technology and computer science academic programs don’t dedicate more time to many of what we consider to be essential skills. We find that employees are too often required to learn even the earliest basics while on the job.

This is ultimately unfair to the individual and the businesses that rely on the education system to prepare people for employment. The individual suffers because they are required learn primarily through spotty mentoring and trial and error. The business suffers because hiring employees that can hit the ground running is nearly impossible.

Yes, there is domain knowledge within each business that is unavoidably learned while on the job, but many basics to being a good software engineer are simply unavailable at colleges and universities except in only narrowest of studies and electives.

So if you’re a current student or someone looking to get into the software development industries, you would benefit greatly from reading and applying the advice that follows.

Let’s go.

Source Control is Required

There are few hard-and-fast rules when it comes to software development. One of those few is that understanding and applying source control is non-negotiable.

But why? What exactly is source control?

Try to remember back to a time when you had to write a big essay for school. It was a constant struggle making sure that you constantly saved your changes, didn’t lose your work through computer crashes, and properly transport it to whomever you needed to turn it in. Maybe you made a mistake and you want to undo your changes, but those changes were saved last week. How can you know what exactly changed last week?

If it was tough for one person to write one essay (in a single file) to be turned in to one person, then can you imagine what it’s like for potentially huge teams to manage hundreds (or more) of files across the globe?

That’s how the software industry works. Software is written in text, over potentially long periods of time, and through the collaboration of many people and teams. Sometimes those teams are literally distributed around the world.

The solution to that logistical nightmare is source control.

Source control helps with:

  • Provides single, central source of truth for software development teams to reference.
  • Visibility of what state a product or feature is in because that state is enshrined in the source control repositories.
  • Facilitates collaboration between distributed teams and accelerates product releases by maintaining a source of truth.
  • Enables parallel development paths for developers working on the same product simultaneously.
  • Reduces conflicting changes when developers are working in parallel by preventing conflicts from arising in the first place.
  • Allows a team to check the completely history of tracked files, revert specific changes, and comment on those historical items.
  • Paired with distributed remote services like GitHub and Bitbucket, the repository becomes an effective backup of your work.

The craziest thing about all the positives listed above is that taking advantage of source control is painless, free, and can be built directly into your existing workflows without harming productivity.

Graphic showing local vs remote Git repositories.

By far the most popular choice to enabling source control is through a tool called Git. Its primary use case is to track and coordinate work between programmers and software developers, but at the end of the day, Git can also be used to track changes to any files such as images, movies, and more.

Git’s main goals are speed, integrity, and support for distributed, non-linear workflows. That’s a mouthful, but it basically means that Git is fast, accurate, and allows teams of developers to work on many features and fixes simultaneously without wrecking each other.

If there’s anything you take away from this section, it’s that you should read more about source control fundamentals, download Git, learn the fundamentals of Git, start experimenting with your own projects, and eventually build up a portfolio of personal projects to show off to job interviewers.

Software Development Lifecycle (SDLC)

Products and services are only as good as the team that builds them. Teams are only as good as the efficiency of the people that comprise them. Efficiency is only as good as the processes that define the workflows.

We can hear you now. What exactly does that mean?

In a nutshell, software development starts and ends as the result of a process that we call a “lifecycle.”

The most common stages of this cycle are:

Diagram showing standard SDLC.

(1) Requirements gathering and analysis: This is the first stage of the cycle where stakeholders define exactly what it is they want to be built. For example, your computer science teacher gives you an assignment description sheet. Or maybe you’re working for a company that wants a new website built to allow customers to sign up for food delivery. In both scenarios, the requirements are gathered and described.

(2) Design: In the second stage, someone has to figure out how to design and build the requirements. Going back to the school scenario, imagine what you would first do after reading the assignment details. You probably started thinking about how to tackle the problem. You might ask yourself, “What recent lessons are applicable? What algorithms are needed? What language should I write this in?”

(3) Development and testing: After you have a path forward, it’s time to put your fingers to the keyboard and actually develop something. This is the step that everyone thinks of when they imagine being a software developer or programmer. Unfortunately for people who enjoy this step, it can sometimes be the shortest one depending on the project. After you’ve written code and get to a working solution, the process of testing that solution begins. Development isn’t complete until all testing is considered successful.

(4) Implementation and delivery: Now there’s a tested product or feature sitting in the source control repository. Users can’t use the product like that, so someone or something has to deliver the product to the end user. Depending on the product, that can be a web server, mobile phone, or a desktop. The product is compiled, bundled up, and sent off to wherever it needs to ultimately be. There’s more on automating this step later in this article.

(5) Documentation: This is the step everyone hates. Everyone directly involved with the product’s development are extremely familiar with how that product works. But guess what? No one else does! Writing documentation helps developers that have to maintain and fix the product in the future. It also helps users of the products understand how to accomplish their goals.

(6) Evaluation and analytics: Finally, there’s no way to know if the product is succeeding without tracking performance and user metrics. It’s not enough to ship something to the world and then move on if you’re expecting continuous use. Understanding how the system is performing and how users are actually behaving within the product is key to improving and fixing any problems that arise.

You might be saying to yourself, “But I was able to complete my assignments with just doing the development step!”

And you would be wrong.

  1. Your professor gave you the requirements. (requirements)
  2. You thought about how to solve the problem. (design)
  3. You wrote the code to meet your design. (development)
  4. You packaged and delivered the assignment. (delivery)
  5. You explained to your professor how to compile, run, or use your assignment. (documentation)
  6. Your professor evaluated you on the success of your solution. (evaluation)

The problem is that the SDLC isn’t presented to students like this in class. There’s no explanation that this is occurring and needs to continue occurring into your eventual job activities.

Being a good software engineer requires understanding (and sometimes participating in) every step instead of isolating yourself into the cave of development.

Just What is Product Ownership?

Software is ultimately a product. Sometimes that product can be free. Other times that product can be purchased via a subscription or one time payment.

Regardless of how the product is obtained, there is always a person who owns that product. No, we don’t mean the owner as in the person that purchased the product.

Instead, we mean the single and sole person responsible for the trajectory of the product’s development and management of its backlog of features, fixes, and debt.

But to understand that, we need to know what a backlog is in the context of software development. According to scrum.org:

…the Product Backlog is an ordered list of everything that is known to be needed in the product. It is the single source of requirements for any changes to be made to the product. 

— What is a Product Backlog?

And further as it relates to the product owner:

The Product Owner is responsible for the Product Backlog, including its content, availability, and ordering.

— What is a Product Backlog?

From that description, if we reference back to the section on the SDLC, we can easily see that the backlog fits into the first stage: requirements. The product owner is essentially the single point of responsibility for maintaining the product backlog. As long as the software product exists, so too does the backlog and its owner.

So how does this relate to you as a developer?

As a developer and eventually a technical leader, it is your responsibility to maintain a relationship with the product owners to understand their needs and the product’s needs.

Think about that for a second because it’s important.

You will be responsible for putting your hands on a keyboard and physically communicating to the computer how you want it to behave to meet the product requirements. If you can’t communicate with or don’t understand the product owner, then it will be impossible to successfully implement the required features and fixes.

As a technical leader, this ability becomes even more important as it will be on you to translate from non-technical requirements to technical speak for the engineers responsible for doing the development. If things don’t click between you and the product owner, more than just the product will suffer; so too will your team.

Tips for working with product owners as a developer:

  • Understand the product, its roadmap, its backlog, and the owners of that product
  • Keep lines of communication open so that productivity stays flowing
  • Raise flags immediately if you or your team doesn’t understand the product requirements
  • Contribute openly to requirements gathering and analysis sessions to keep product owners honest
  • Direct all backlog modification requests to the product owner to force their accountability

Collaboration & Communication

This is the first section that isn’t specific or limited to software development. We will obviously focus on applying these skills to the software industry, but it’s generally applicable to any walk of life.

If there’s anything we’ve learned while working in the industry for decades, it’s that humans are notoriously awful at communicating. People say things they don’t mean and hear things that were never said. We are quick to emotions and slow to reason. We preach one thing and do another.

Additionally, people are plagued by the fundamental attribution error where we constantly excuse our own possibly bad or accidental behaviors but don’t give the same courtesy to others who suffer from the same issues.

If we can’t even communicate with each other on a base level, how can we be expected to effectively collaborate on complex products and projects on which the world has come to depend?

Fortunately, it’s not all doom and gloom out there.

As humans, we have the ability to reason, create, invent, and achieve. As such, we’ve created hosts of processes and tools to assist in bridging the communication gap that exists between us.

In the software industry specifically, there has been no shortage of efforts dedicated to facilitating better collaboration.

Tools to improve collaboration and team cohesion:

  • Basic email for general communication
  • Microsoft Office for shared document and writing
  • Google Docs for shared document and writing
  • Slack for real time chats
  • Microsoft Teams for real time chats
  • Jira for project and backlog management
  • Confluence for documentation
  • Trello for project, task and backlog management
  • Git for distributed source control
  • GitHub for remote distributed source control
  • Bitbucket for remote distributed source control

Processes to facilitate successful projects and guide people in the right direction:

We won’t go into all of those in detail as it would require much more time than is allotted to this article. The point was to illustrate that there are a lot of options out there to facilitate communication and collaboration of complex projects.

And don’t go running off to learn everything there is to know about those tools. Many of them are picked up on the job naturally as you get the hang of the normal SDLC at various businesses. At the very least, we suggest learning Git and using GitHub to build a portfolio of your work.

You know what they say about horses and water. In this regard, people aren’t that different from horses. We too often ignore advice from the seasoned veterans around us and instead believe that we have the answers.

At the end of the day, it’s up to all of us to take advantage of the opportunities and resources presented to us and put them to good use.

After all, without effective communication, how will we build the future?

Importance of Good Project Management

Projects are not the same as products. A project may include new features, changes, and decisions that affect one to many products.

For example, let’s say you have a two products that allow customers to purchase clothes: a general website and a mobile application. The website has one product owner, and the mobile application has another product owner. Don’t remember what a product owner is? Read the section in this guide about product ownership to refresh yourself.

For the first quarter of 2020, the business executives have decided that they also want to start selling shoes to customers. To accomplish this, project managers are tapped to put together a plan including high level requirements, timelines, estimates, costs, checkpoints, and stakeholders.

But the project managers may not necessarily know which specific products and services need to be updated to support this new ask. That’s where collaboration with product owners comes into play.

Product owners receive the high level requirements from the project managers, turn those requirements into something that can sit in the product backlog, and work with technical leadership and teams to understand exactly where and how the necessary changes can be made.

The relationship between project management and product ownership doesn’t end there. Success requires constant two-way communication between the two.

Here some scenarios that display the relationship:

  • Project management contacts relevant product owners to discuss requirements (in this example, there are two product owners to contact)
  • Product owners discuss requirements with technical leadership
  • Technical leadership provides feedback to product owners
  • Product owners work requirements into product backlog
  • Product owners communicate development estimates and team availability to project management
  • Project management puts that feedback into their timelines, estimates, and costs
  • Project management establishes checkpoints to keep product teams honest

Let’s take a look at the diagram below to visualize the organization. Here we can see that project managers can interact with multiple product teams during the lifespan of a single project.

Note that this doesn’t mean to imply that product teams are managed by project managers. We know, the “manager” title is misleading. Project managers typically don’t manage people and instead manage the project.

Diagram showing relationship between project management and product teams.

As a developer, understanding where you fit in this organization is key to your success. You don’t exist in isolation and must make it part of your daily activities to keep this in mind to remain successful.

Yes, it’s true that project managers and product owners keep a lot of the back and forth separated from the developers. If developers were inundated with every minor detail regarding daily requirement changes, timeline shifts, and cost changes, they would never get any of the actual work finished!

But understanding that developers play a critical role in a larger picture goes a long way to gaining trust from non-developers and ultimately leads to personal and organizational success.

Automated Build and Deploy Processes

Here’s a sad but funny (in hindsight) story about a situation in which the author found himself when he first started developing software.

A team of developers at a popular defense contractor was to build and maintain a web application that provided a modern user interface for a 25-year-old database system.

When updates were made to the application, this was the established process to release those changes to the users:

  1. Pull the latest version of the application from the source control repository
  2. Compile and build the application
  3. Copy the output files to a shared folder
  4. Log in to the web server
  5. Delete the existing application files
  6. Copy the output files from the shared folder to the correct web server folder

And that process was repeated by a single person every time there was a new version. If that sounds manual and error prone to you, then you’d be correct.

During one deployment, a developer performed this process and made a mistake during the fifth step. Instead of deleting the application files, the developer deleted all files on the drive that hosted the applications. Needless to say, we had a big problem.

If we had known more about automated builds and releases, we might have been able to avoid constant problems and delays caused by this awful process.

Yes, a developer having the ability to delete everything was obviously bad. But the fundamental problem here is that the process was manual and relied on the good graces of a human.

But now we know better, don’t we! These days, we can use tools like Jenkins, Bamboo, TeamCity, Travis CI, GitLab, Azure DevOps, and many more to accomplish build and release automation.

Using those tools, we can take our manual build and release processes, create the automated versions of those processes, and remove all manual access except to only the most trusted administrators. This effectively removes humans from the equation which is a huge benefit for efficiency and accuracy.

Diagram showing CI/CD pipeline.

Like we cautioned in a previous section, don’t go learning all of those systems all at once. Whatever team you join will most likely already have something setup that you can learn. And in the case that you’re starting a new team, research a few, pick one that seems good to you, and run with it.

The main takeaway here is that you should automate any process you find yourself repeating. This is especially true for those that directly affect the success of your products and services.

Further Reading: If you’re interested in learning more about continuous integration / continuous deployment (CI/CD) and general DevOps culture, check out this great article for more details.

Justin Skiles

Justin Skiles

Justin has been developing enterprise application software for over 10 years primarily using Microsoft stacks, Azure, and various open source tools. He has most recently been trying his best as a Manager and Director of Software Engineering in the health care industry.

Share the Knowledge

Share on facebook
Facebook
Share on twitter
Twitter
Share on linkedin
LinkedIn
Share on pinterest
Pinterest
Share on facebook
Share on twitter
Share on linkedin
Share on pinterest

Follow our updates

JOIN OUR SUBSCRIBERS

GET FREE UPDATES

Keep Exploring. Choose Your Path.

Follow Us

GET THE NEWSLETTER

Recent Posts