10 things you need to know as a Software Engineer beyond coding

As if writing code itself wasn’t hard enough, when you get into a real job as Software Engineer, it can be overwhelming what is expected of you. After 15 years of working in Software, I have learned that there is so much more than simply writing code to being an engineer.

Here are 10 things you need to know about as a Software Engineer beyond writing code:

1 — Project Management

It is one thing to build a software solution that solves a particular problem and it is a whole other thing to build a software solution that solves problems on a deadline. Too many times, software engineers do not understand what their role is in terms of the business project cycles. This can lead to cost, scope, and time problems if original estimates about development were wrong or technical difficulties prevent moving forward.

There are two basic ways that projects are managed:

This is where you find terms like Waterfall thrown around. Imagine a world without software or the internet, how did companies build skyscrapers? They planned out the projects, the dependencies, the designs, the timelines, the permits, etc., etc., etc. The cycles tend to be longer, work breakdown structures are used, and usually have a dedicated PM that tracks everything.

Welcome software and the internet, and businesses still operate with planned projects, so it influences how they approach software. It is important to understand at least the basics of how these projects run, as not all software is built using Agile methods.

Common methodologies one might run into:

Waterfall, PMI-Project Models, Spiral

Common keywords from planned projects:

Work Breakdown Structure (WBS), Gantt Charts, PMBOK, Project Charters

This is where you find Agile methodologies, that deal with managing chaotic change. Software is particularly prone to wicked problems where things change very quickly and requirements cannot stay locked for long periods of time. The cycles tend to be shorter, priorities change frequently, and work comes in the form of backlogs.

Common methodologies one might run into:

Scrum, eXtreme Programming, Lean, DSDM, Scrumban, Kanban

Common keywords from iterative projects:

Backlogs, Standups, Retrospectives, Grooming

Software Engineers need not be experts in project management, but their effectiveness as an Individual Contributor at an organization will go up the more they can run projects, and operate within existing projects.

2 — Estimation

How long do you think it will take before it is done? Perhaps the hardest question to answer in Software Engineering. There are a lot of little pieces that go into building out Software and estimating your work is key to being a successful Software Engineer.

If I could think of the most common phrase I’ve heard in all my years, it would have to be along these lines: “It is done, but this feature is not done”; “It is done-done-done”; “It is done, but I need to do document it”; “I’m done, but it is not done done yet.” I think you get the picture.

One of the things that makes estimation so difficult is that work itself is Knowledge Work. Software Engineers are Knowledge Workers. This means that each person has a different level of knowledge with the software system.

Some of the ways that Software gets are estimated are:

Planning Poker — Each team member casts a vote on effort, and then a consensus is reached by the team on the effort. Uses story points as the measure.

Wideband Delphi — Experts anonymously submit estimates and a consensus is reached.

T-Shirt Sizing — Using S,M,L,XL size categories for tasks.

Function Point Analysis — Analyzing the amount of units to be built and comparing that against past results.

Expert Judgement — Seek out experts for their opinion based on their expertise.

Bottom up estimation — Estimate all items in the Work Breakdown Structures (WBS) before project start.

Software Engineers who are good at estimation are the ones that make software projects and products successful! Knowing how long it will take you to code something is almost more important to your job than writing the code itself.

3 — Requirements

You have your development machine all setup, and configured, and ready to get down to business: writing code. How do you know what you need to work on?

Depending on how your company operates, you may receive requirements from Product Owners, Project Manager, Directors, Managers, Sales, or other team members. These can come in many forms and it is important to understand the basics.

In Agile Projects, requirements usually come in the form of User Stories or Use Cases that are put into a Product Backlog. The User Story/Case will contain the requirements for the work, and if well written, all the test conditions that need to be met.

In Planned Projects, you may receive requirements in more formal documents, such as a Software Requirements Specification (SRS) or a Systems Design Document (SDD). They may come from the Work Breakdown Structure (WBS) and contain additional documents as needed from the project repository.

There will be times in your career as a Software Engineer where you will be required to build the requirements documents, in whatever form they take. Take the time to understand what makes a high quality requirements document and your job will be a lot easier.

4 — Documentation

Software changes a lot over time, and documentation is one of those topics that can cause a lot of headache. Maybe some method got deprecated in leu of some new method, and all the documentation is out of date…frustrating! Maybe some old code breaks and there is no documentation at all around it… just as frustrating!

This is not a discussion about self-documenting code. This is about documentation for your business. Documentation is an Art form, and there is a balance to be struck between how much to document and how deep. There are UI documents, Code documents, User documents, Design documents, Compliance documents, and the list goes on.

As a Software Engineer, how much do you need to write? As much as needed, but as little as possible.

My OPINION on documentation for Software Engineers:

Documentation should be written primarily for the next person that is going responsible for that software system. Pretend like they know nothing. Keep it simple, keep it clean, and keep is small.

Software Engineers need to know how to write basic documentation. The better you are at this skill, the more well respected you will be when you leave your current role.

5 — Operations

As a Software Engineer, you are building software that is going to be used by someone or something, somewhere in the world. The more you know about how Software runs in production systems, the better off you will be.

Things you should be aware of, at the very least:

Is it running in the cloud, in a data center, on the users desktop, in the browser?

Who is responsible for supporting Production issues?

What operationally awareness does your software need?

Long gone are the days where Engineers simply throw their software over the wall to the operations teams. Continuous Integration and Continuous Delivery (CI/CD) pipelines are becoming the standard, and code is shipping faster than ever before.

As a Software Engineer, understanding the basics of Production Operations will increase your value to your organization, by improving inter-team communications and your holistic understanding of the entire technical cycle.

6 — Basic Systems Costing

I own it, I’ll say it: I love Microsoft SQL Server. It is hands down my favorite database to work with. T-SQL is awesome, and the engine just works. It is simply a powerful tool.

It is also surprisingly expensive to run in a production environment, especially when you get into having 100–1000s of CPUs and hosts. The license costs make it an expensive tool.

Not all companies are willing to spend a lot of money on licenses for software and require alternative options. This is where having even a basic understanding of how costs occur in Software Systems will benefit you as an Engineer a lot.

License fees, they are only a piece of the puzzle. There are support costs, operational costs, hardware costs, people costs, and the list goes on. Architects and executives are usually the ones that set the direction for costs, and it is not necessary a Software Engineers job to cost solutions.

The more you know however, the better you can demonstrate value to your organization.

Everybody wants to upgrade their skill set or work with their favorite tool. Knowing the financial impacts of choosing one technology solution over another is more important than ANY one tool, framework, programming language, or toy you want to use on the job. Always bear this in mind as new tools become available.

7 — Working with other people

You would think this wouldn’t be needed, but it is. Software Engineers work in isolation a lot of the time. It is research and development, so yes, lots of alone time.

Software Engineers work with other Software Engineers surprisingly well, and that is mostly due to shared interests and specialized knowledge. What is needed, is the ability to work with non-software professionals. This is an area where I have personally seen a lot of failures (myself included).

Many times you will be asked to work with an End User, a Product Designer, an Executive, or a Sales Person, and they probably don’t know anything about Go, C#, Javascript, SQL, etc. and nor do they care. Their job is to use the Software, and provide value in the way they provide value. Your job is collaborate with them to work through whatever is needed.

Knowing how to talk about technical things with people that are unknowing of technical things is an Art form and it takes work. The classic golden rule is simply a good place to start: Treat other professionals like you want to be treated as a professional.

8 — Task Decomposition and Analysis Paralysis

Writing software is hard, and there are a lot of decisions that need to be made. It can be overwhelming at times, especially when deadlines loom, and the pressure is on.

Software Engineers tend to be perfectionists, they want their code to be perfect. We want all the unit tests written, every edge case covered, top-notch performance, and all the technical things we aspire to be good at.

This can create situations where you simply get stuck. Maybe the model in your head didn’t work out in reality. Maybe the software cannot be decoupled the way you want it to be. Maybe there are a lot of unknowns about underlying tools or frameworks.

Whatever it is, chances are you will get stuck in Analysis Paralysis. This is where you fail to move forward due to trying to make sure things are being done correctly. This is common among Software Engineers, I have seen it in Jr. developers to Sr. Architects.

“Give me one more day/week/month and it will be done” … they might say, and say again and again as time passes.

When situations like this happen, it is important as a Professional to know how to pull back, and reassess your position. The most effective way to break down your paralysis is to start performing Task Decomposition.

Task Decomposition is the process you use to break down larger components into smaller pieces of work. If your estimate as a Software Engineer is any more than a few days, chances are it can be decomposed further.

As a rule of thumb, break things down to at least 1/2 days worth of work. This allows you to make progress on smaller tasks and adjust as needed when requirements change. This will get your head out of the bigger picture problem of having a giant task to achieve, and allow you to move forward.

Getting stuck for long periods of time will reflect poorly on you as a Software Engineer. Do not let perfect be the enemy of good enough. Always remember to ask for guidance from other team members if you get stuck!

9 — Technical Debt

This topic has proven to be the most contentious in defining.

Here is how I define Technical Debt:

Technical debt (also known as design debt or code debt) is a concept in software development that reflects the implied cost of additional rework caused by choosing an easy solution now instead of using a better approach that would take longer.

Technical debt can be compared to monetary debt. If technical debt is not repaid, it can accumulate ‘interest’, making it harder to implement changes as time passes. Unaddressed technical debt increases software entropy. Technical debt is not necessarily a bad thing, and sometimes (e.g., as a proof-of-concept) technical debt is required to move projects forward.

Essentially, Knowledge Debt.

Technical debt is a byproduct of making decisions, and all decisions have a cost. When estimations do not meet reality, decisions must be made to maintain alignment with business needs. These decisions can have long lasting ramifications for Software Engineering teams and the ecosystems they work in. Be aware of what Technical Debt is.

10 — Legacy Software

Let us start with: All companies have Legacy Software to deal with. Even a startup has Legacy Software within six months time. It is a fact of doing business in Software.

Software exists for a reason, and that reason is usually to serve a business function. Sometimes, a really simple piece of software becomes embedded in Business Processes and gets used all the time. It may never need to be changed, but it still exists and needs to be maintained.

This is something less experienced engineers seem to struggle with. They get in at a company, are given a legacy tool to maintain, and they want to improve it, upgrade it, update it, and change it. The Software Engineers job is to MAINTAIN it.

Whether Engineers like it, or not, they have to maintain legacy systems. Always remember, ALL software at some point was brand new. Your ability to work in existing technology solutions will directly impact your ability to deliver value to your organization.

These are the 10 things I feel that all Software Engineers should know about beyond writing code.

Best of luck in all of your development efforts.

A Data Wizard

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store