Actually, May was the five years, but I’m behind a few months. Here’s a lot of my opinions.

This code is not your code

This code is not your code. It’s not your manager’s code. This code is the property of your employer. This shouldn’t detract away from the concept of ownership for your work. My intent is that our perspective shouldn’t be so narrow. We shouldn’t be concerned with whether a project succeeds or fails, we should be concerned with whether the business succeeds or fails. A project and code isn’t created for the sake of artistic mathematical beauty, it’s created for a purpose and that purpose is part of a greater goal.

This code is not your code. This code isn’t purely your code until you leave a company. This code is written for your teammates and it is as much a set of instructions for them as it is for the computer.

This code is not your code. You are not the code you write. Your value as a person is not dependent on whether you write the best code out there. You are not innately a better person than anyone else if you do write the best code out there.

Biases on a “minimum level”

Anyone who has ever been on the software industry job market knows that interviewing is a roll of the dice. Each interviewer has their own personal biases, what they care about, what they consider required, and in general what the “minimum level” is. We might complain a little bit about the existence of such unknown things, but then it’s easy to go about our jobs, to read blogs and articles online, and to judge other people for what we view as the “minimum level” required before we consider their words.

Articles and posts titled like “Five things every web developer should know about image compression” inundate my news feeds. Most of these articles are solid, they focus on the five important things to know and usually inform me of something I didn’t know before. This is a great thing, I’m learning. My problem with these “minimum levels” as defined by the author is that there’s not a strong likelihood that an arbitrary and productive developer will know all these things, so is it really “minimum level” if someone is productive without that knowledge?

I’m less and less inclined to judge someone because they don’t know what I consider an important part of a particular tech stack. I still occasionally make this mistake out of habit, but I’m doing better. The point is that there’s no minimum level of knowledge required to become a software developer or to talk about any topic or to claim competency in any topic. If someone cares about something, they’re going to learn about it and they’ll be amazing at it in no time. If you didn’t get the hint, I was also saying that computer science degrees aren’t a prerequisite.

Can’t know it all

All knowledge is useful, but perhaps some knowledge is more useful than others. It is folly to claim knowledge and mastery of all areas of software development, and of both practical and theoretical applications of computer science. And yet, many people in this industry of software development claim this.

Once upon a time many years ago, to know it all was my goal. A deliberate conquering of each computer science topic didn’t seem too far out of reach, and then I began studying. The more time that I spend in this industry, the more I try to attain a calm acceptance of merely superficial knowledge in many topics.

I’m really saying nothing more than the obvious: the time available for increase of knowledge is limited. Make deliberate choices of in-depth study. Whether you care to become a specialist or to become a generalist or to decline the choice of labels, spend some time in self-reflection and decide what your goal is.

Specialist or generalist?

I decline a single label because I want to choose both: I like to be a generalist with a few distinct specialties. My tech stack has been varied and wide even in the short time I’ve been working full-time as a software developer. On paper, I don’t have the years of experience for most tech stacks I’ve worked on to pass most HR Dept.’s screenings. So I like to pick and choose a few areas I really care about to really focus on.

Claiming a label for yourself is a tricky business for you’re claiming a definition of who you are. Further, other people’s definition of what makes a specialist in a certain area will be radically different.

Instead of claiming a general label, it’s quite possible to zero-in and become even more specific: “I’m a specialist in the cloud” might become “I’m a specialist in application development and life-cycle on Azure PaaS offerings”. To become even more specific and more unique, combine multiple things you know “I’m an Azure developer with experience in the healthcare industry”. Combining multiple technologies or domain knowledge could bring out some unique opportunities.

At the end of the day, technologies will change. Changing specialties is a lot of work, albeit hopefully not a frequently recurring one. My end goal is to keep working, to keep getting better, and to build a reputation not on any set of technologies but upon who I am as a person and my capacity to learn. Making connections, meeting people, and being consistent is the best avenue of continuous gainful employment.

What someone knows

When working with someone, a strong temptation might exist to estimate someone’s knowledge and abilities based only on what you see in front of you. Such estimation is often a mistake. We don’t always know someone’s strengths or weaknesses, we don’t always know someone’s experience in other areas. My summary here ties in with above paragraphs: someone is not purely the code they create, especially under the highly variable restrictions, requirements, and boundaries that may be present in any job and situation. If possible, give someone the benefit of the doubt and don’t presume that all you need to know about them is in the written words before you.

Do you care about what you do?

Life is short. This overused colloquium is often repeated, often glossed over, and grown so stale that the phrase is just white noise. You should spend your time doing what you care about and believe is a worthy endeavour.

To spend your time on a worthy endeavour is the most that can be asked for. As a software developer, I am fortunate to spend my time in activities I enjoy: solving puzzles. I care about what I do.

I care about doing the best that I can in my job. But I don’t care about any one aspect of software development enough to make it my life goal and what I want to be known for. Software development is a means to an end, to help accomplish a goal. I care more about the goals being achieved than a purity of software development. I care about adding value.

Sometimes, I see a “thought leader”, or whatever buzzword name, that genuinely cares about what they talk about, who would talk about it regardless of whether anyone listened to them, and who would be exactly the same person without an audience. I look at them and I see the foundation of a new school of thought. Someone who wouldn’t be the same without the audience, might not be the greatest source of original thought.

Many diverse topics, both software and not, exist in this world and anyone may be excited about any odd topic. Yet very few people are self-starters and willing to care about something without direct influence. It seems to me that most people that care about something, do so because someone they look up to cares about it, or because they wish to fit an ideal. This goes way beyond software development: most things are important because someone chooses to care and think it is important.

To talk about what people find satisfaction and purpose in life is an odd diversion, but we talk about these people all the time: they are the short-list of people we want to work with again and who we look up to in our industry. I love to work with people who have chosen to have a passion for what they have chosen to do. A sincere person is worth their weight in gold.

People are the most important thing

As methodologies of increasing work output trend in the software development industry, they all seem to have one aspect in common: defining the important channels of communication. Communication isn’t an ignored part of the software world, but I’ve seen many times where we try to find solutions for talking that don’t involve talking. A technological solution won’t fix an organizational problem. People actually working together is the most important thing towards success.

Minimalism

In software, every code dependency, package dependency, service dependency, and tool dependency is a potential liability. The code could be bug ridden. A package’s usage license may be incompatible. A service may be discontinued with no compatible alternative.

When I was much newer to the software world, I heavily subscribed to the philosophy of “there’s a package for that” and I wanted to add all sorts of dependencies to more quickly make software. The particular piece of software I was working on had existed for a dozen years, was expected to last for many years more, and still exists now. I wasn’t considering the long-term aspect that software could outlast what it depends on and that taking each dependency should be a purposeful and known acceptance of the gain against the liability.

Minimalism is a purposeful and known acceptance of the gain against the liability, an awareness. An awareness of how we build our software systems has much to recommend itself.

When asked something

Both at work and elsewhere, I’m often asked questions, no surprise I’m sure. My first thoughts is usually to answer the question as best as I can. I don’t always consider if it’s the right question, if I should answer it at all, or if I can suggest an alternative. To consider deeply the motive for any question, is a great strength to anyone.

Many project managers and leaders I’ve worked with over the years were fearsome because they controlled the narrative, they were informed, and they asked the right questions to get their required outcome.

Harper Lee wrote the below in To Kill a Mockingbird and I’ve often heard repeated that sentiment.

Never, never, never, on cross-examination ask a witness a question you don’t already know the answer to, was a tenet I absorbed with my baby-food.

Do not answer questions blindly, consider if they are the right questions, the reasons for that question being asked, and who is hearing the questions and answers. Many purposeful people are building a narrative towards their vision, learn to be aware of these.

Planning for the MVP

The minimal-viable-product (MVP) is a product with the smallest set of features to be useful. I like building the least amount required for utility, it allows for an early demonstrated win. But do we actually plan work towards the minimal-viable?

Minimal-viable doesn’t mean you get to do the same process as before and it’s suddenly and magically cheaper and faster. Doing the minimum-viable is hard because it requires hard decisions to be made about what to cut, and truths to be found about what’s actually required to get value. The minimal-viable is a known acceptance that not every case will be covered and that can be hard in case someone’s toes gets stepped on.

Do we plan minimal-viable work with the full recognition that it might not the end-game architecture? Further down the line, costs of rework might be known and necessary and even planned for. A hard choice in doing the minimal-viable, is that less cost is being paid now to ship a product, and in return the costs might be higher later to “fix it” or finish it. That’s not always the case, but it’s a cost that could also appear if pivoting.

Summary

Some of what I’ve written above is a departure from how I once thought. Some is a clarification of stuff I’ve always thought. The rest might be conjecture. I hope that you find something useful in my observations, even if it’s only a contrast to your own viewpoints.