Your Coding Skill Is Not Enough
By: Shawn Grover
Tags: Careers, Startup, Programming

You need some other skills too

Photo by Arian Darvishi on Unsplash

I did it. I have learned enough about programming and technology to be considered an expert in some circles. Awesome! But as I look out from what I thought was “the” summit, I see other peaks around me that are just as important to my career. Let’s explore some of the other topics we developers should also work on.

Programming skills are not enough on their own.

Soft Skills

It is well known that “soft skills” are important for an employee. Soft skills are defined as people skills, social skills, communication skills, etc.

Human Resources has been trained to look for these skills in potential candidates. As a result most software development courses also include training in communications.

So this is an “easy” thing to see and train ourselves for.

Prove your skills

Almost all of the projects I’ve taken on have been “internal” proprietary projects for someone else. I don’t own the copyright on the code for those projects. That means I can’t ethically or legally use that code. Assuming I still have access to any such code.

I also can’t use code snippets from those projects to demonstrate what I know. The snippets are a bit of grey area when it comes to copyright, so I try not to touch that code for any reason. That keeps my conscience clear.

Copyright is a deep topic. There is fair use that might apply to code snippets. And the idea is fair game to be talked about— just not the code that implements the idea. The laws are likely different in your area, so we’ll just assume hands off to keep things simple for our discussion here…

That leaves me with little public material that can provide any evidence of my skills or expertise.

If you look around at the developers in your circle of contacts, this may sound familiar. I feel it is pretty common with most developers.

The problem then is how to demonstrate your capabilities to people outside your immediate circles? What evidence do you have to back up your claims?

This can be solved by writing about development. (I’m feeling a little meta mentioning that in this article.) Writing only does so much though. Providing code in some way is a great additional resource. Writing articles about the code you wrote is a great way to bring attention to that code and get feedback to help you grow as a developer AND a writer.

If you have a full time role and a young family who demands your time, that leaves precious little opportunity to tackle coding projects on the side. But code still needs to be written and posted somewhere. So a balance is needed.

My recommendation here is to create a pet project and use GitHub to store your repository. Treat this project as “production” code. Do everything that a production project would do — branching, pull requests, unit testing, documentation, etc. Dedicate at least a couple hours a month to work on that project. Adjust that time to fit your own needs of course. The goal here is to regularly contribute changes to the project and have it improve over time. If a project dries up or there just isn’t anything more to contribute to it, start another one. Pick something different that showcases a different aspect of your skills/experience.

Alternatively if you don’t want to create your own project you can contribute to an existing Open Source project. Your GitHub profile will show your contributions there as well as to your own projects. Or better yet, contribute to Open Source AND your own projects if time permits.

The idea is to show consistent contributions over time. Because the project(s) is/are public, your contributions can be reviewed by others when needed. Anyone investigating YOU will see you are an active developer and have code samples to checkout.

Do not use your research projects for this effort. A research project often has quick and dirty code in it — just enough to allow us to get to the thing we were researching. If you post these as public projects, make sure they are clearly marked or separated in some way so they are not confused with the “production” projects. It would be awful to have research code inadvertently give the impression of a sloppy coder. I suggest using private repositories for your research projects, or placing them on a different server or account (perhaps BitBucket for example).

To help with my research efforts, I place ALL my projects into a “swamp” directory. Where needed, I use a private repository on BitBucket for these research projects (or GitHub now that they offer private repos without charge). Then when a project matures enough or can otherwise be considered production ready, I “raise it from the swamp” into my main projects directory. Occasionally I have to “drain the swamp” and clear out older projects that are dead or no longer needed. This is me having fun with my own process though, you may choose to be more formal if you’d like.

Domain Expertise

A business application is the codification of the business rules involved. Once an application is completed and moves into the maintenance phase, the logic, decisions, and expertise represented by that application is an implementation of how your company applies the “domain knowledge” involved.

For example, consider the ordering process for an e-commerce system. We often describe this as 1) place order, 2) collect payment, 3) ship product. Anyone who has dealt with Magento or other e-commerce platforms will know that is a rather simplistic “order flow”.

Placing an order can be different for your organization and may involve seeing if inventory is available or if more has to be acquired. Or maybe the warehouse local to the customer does not have stock, but some remote warehouse does and a transfer order is needed.

Collecting the payment can have its own workflow. What happens if the payment is tagged as fraudulent? Or the payment is just rejected for non-sufficient funds? What if a customer is paying on a terms account? What if they want to pay at the door? What happens to the ordering process in each case?

The information that goes into HOW to place and complete an order is domain expertise.

If you built an application from the ground up, you are now the “domain expert” for all things related to that application. If you contributed to an application over time, then you have some domain knowledge relevant to the application. Either way, that domain knowledge or expertise gives you some credibility. More so if the application is well received and important to the business.

Ideally, you would have had some domain expertise in the project BEFORE you began coding it. Maybe you have developed a few e-commerce applications and that is why you are chosen to build this next one. Or maybe you have a previous career as a warehouse worker, so you understand the logistics needed for this new application.

It is too easy for developers to become domain experts in development only.

To truly excel at your career (in my opinion), you might want to pick a particular topic — e-commerce, logistics, business management, etc. And then focus your programming career on projects related to that topic. This will give you a huge boost to your credibility when discussing roles that may need that expertise. Without that focus, then the business may feel you are a capable coder but missing that extra thing that makes you ideal for the role.

Once you are working on a project you WILL gain domain expertise over time. At least for the way this organization does it. Look around and you will find people that are considered too important to fire or let go because they are the only ones who know how it all works. Or perhaps that person is just aware of the decisions that went into the projects that are being maintained now.

I’ve worked for a number of companies, and freelanced for quite some time. In all cases, that domain expertise, or lack of it, is what sets me apart. Being able to start with a core understanding of the tasks at hand before applying any coding considerations is what makes you uniquely qualified, compared to those who only have the coding expertise.

Understanding Business Needs

As developers we need to understand what it is we are building. We call these requirements. Given a good set of requirements we can go build a system to meet those requirements.

What is missing is WHY these are requirements. What are the business decisions that lead to the requirement? What are the business managers really asking for? Being aware of these considerations improves the chances the project is successful.

In my experience, I find an easy way to highlight this is to ask the question “what VALUE does this feature/requirement provide?” Understanding a business value is not always a logic thing and so may not be immediately clear to a developer.

For instance, we might be asked to build a login system. A developer may think the value being provided is that only authorized people can execute the tasks — typical security concerns. A business person may see that a little differently — they know security is important but are focusing on the “integrity of the data” as a value. We developers see “data integrity” as something different — usually related to well defined databases, foreign keys, indexes, triggers, etc. But to the business person, they are referring more to the amount of confidence in the data, the auditing/logging capabilities of the system, etc.

Understanding what the business is REALLY trying to accomplish in the big picture is just as important as understanding the immediate requirement. Understanding the actual business need may define a new feature request as inappropriate to the intent of the application. A developer who can create code that caters to the immediate need AND the larger goals is a valued member of the team.

Wrapping Up

It is sometimes important for developers to know how to use linked lists to create a binary tree, how to efficiently structure your data, or when to apply more hardware versus revising code to deal with a performance problem. But none of that matters when it comes to domain expertise, proving your capabilities, or understanding what the business is trying to do. Not unless you are building programming tools for other developers, of course — in which case, programming expertise IS the domain knowledge, and defines the values.

Adding those areas to your repertoire will give your career more focus. Without those areas, you will move from project to project, starting over each time with the domain knowledge.

I for one, have spent most of my career becoming really good at writing code, or making the computer do my tasks for me. My domain expertise is programming and technology. This has had a definite impact on my career as I built applications to solve the business needs of each new project. The projects sometime feel like I’m starting over as a junior and have to work my way up again.

Hopefully this article helps newer developers avoid some of the pitfalls I’ve encountered, or provides food for thought if you have already established your programming career.

Thanks for visiting!