As promised, this is the seventh (and final) part of a short series to provide some quick guidance for people who would like to reach out feelers into a possible software development career. As I mentioned in the first post, a lot of this material is recycled from some of my old Quora answers, updated for current times and the tone of the blog. More and more of it turns out to be new, the longer this goes on.

Pre-Social Distancing Meeting

To finish off this series (for now, at least), we’ll talk about the non-technical issues involved in being a programmer that aren’t related to formal education.

Note that I already covered some small parts of this when I wrote about colors and continued talking about graphic design tips in general. That is somewhat non-technical and will come in handy, but because I covered some of that ground there, I won’t repeat it here.

The Non-Technical, Non-Education Side

Everything so far has been a relatively straightforward process. Even if you have obstacles in your life that make it more difficult to program well, you can come pretty close to overcoming almost any deficiency with time, trial, and error. By contrast, these are your “soft skills,” which isn’t a reference to the difficulty (a distinction that a surprising number of podcasters and writers seem to have trouble understanding), but rather to the simple fact that you need to be careful not to cause any damage when solving a problem.

That is, “hard skills” can be simplified to brute force. But you can’t really “iterate on” communicating with a person. You can’t bore your colleagues into being interested in your idea.

Obviously, this can’t ever be a complete list. Every job and every project is unique. Every team has its own struggles. And you might get into situations that most people never see. But this should be a start.

Writing Comments

The most code-related interpersonal skill is commenting your code. Just about every programming language has the ability to add free form notes to your code for whatever purposes you please. And many programmers, unfortunately, will do exactly that, commenting whatever comes to mind.

The worst comments are the sort that provide information that already exists somewhere else. Some terrible comments follow.

x = x + 1 # Add one to x

# This is a fix for ticket #1234
x = 17

# The following is a bubble sort
for i in 0..numbers.size
  for j in i..numbers.size
    if numbers[i] > numbers[j]
      store = numbers[j]
      numbers[j] = numbers[i]
      numbers[i] = store
    end
  end
end

# We shouldn't be doing this; it's stupid
x = 18

In the first case, the comment is explaining the programming language. In the second case, the comment is cluttering the code with information that’s easier to find in the version control system. In the third case, the comment names the algorithm used with no context. And the last case doesn’t tell us anything useful except that the programmer was having a bad day. Each of those examples, by the way, are based on comments I’ve seen recently.

By contrast, a good comment saves a colleague the time needed to contact you with questions. The comments I find most useful are those that explain why the programmer wrote the code that they did, and why the alternatives weren’t used, such as the following hypothetical example.

# We need the list of numbers ordered in descending order, so
# we need to sort it.  We can't use the in-built sort method,
# though, because we expect to need to sort multi-dimensional
# information in future versions, and it will be easier to
# handle that with custom code.

This explains the intent of the code (making it easier to find bugs) while also providing an explanation to a future maintainer as to why they shouldn’t just replace the code, with conditions where replacement makes sense. Other comments that people will silently thank you for include the following approaches.

# 17 is the minimum number of hours a franchise can employ
# someone.
x = 17

# The following code comes from
# https://answer-site.invalid/q1234567
# under an MIT license.

# Whenever you change the next line, you'll also need to
# test the autoCorrect() method to make sure it handles
# the new data.

Simple enough, right? We have an explanation of what something means, where it comes from, and invisible dependencies. It takes some work to take a step back and think about what questions a person might have, but that’s not difficult.

Asking Questions

Speaking of questions people might have, we all need help. None of us programs on our own, and you shouldn’t expect to, either. But asking for help is difficult for two reasons. First, it shows vulnerability and most of us were raised (incorrectly) to believe that vulnerability is some moral weakness. Second, we don’t want to waste the time of the person we’re asking.

You’re on your own for the first problem, beyond just being aware that humans are social creatures who are more powerful in groups than alone. But for the other issue, structuring the request goes a long way to maximizing the chances of getting help without imposing. Consider the following format.

  • Start with a headline, the simplest, shortest explanation of what you want to do. If you can explain the problem in a few words, it’s easier to get the attention of someone who’s busy.
  • Explain why you want the result you want. A lot of the time, we overlook much simpler solutions and fixate on an approach that isn’t as good. Going through what you really want in human terms can open up that discussion.
  • Give the details about your problem, like anything special about the data or any constraints.
  • Provide your attempted solution. If you can reproduce the problem you’re having in a smaller program, supply that, instead. More often than any of us would like to admit, you might find your solution while creating that simplified version.
  • Explain your expectations in your attempt and the results you see instead. Most people are not going to run the code you provide, and will instead just read through it, so comparing the expectations versus reality helps focus.

If you’re submitting this to a Q&A site or a bug-tracker, they might have a specific form to fill out with most of these pieces, but if you get in the habit of gathering all of this information first, getting help through e-mail or in person (assuming we ever set foot in offices again) becomes much easier.

Writing in General

We all need to be better writers and most of us need to write more deliberately. Especially as more jobs become remote positions, you need to make sure that your intent comes across to the people you’re communicating with. That responsibility ranges from the smallest written works (a text message or a tweet) to the largest, and from the informal to the formal.

How do you get better at writing? By writing! You need to listen to feedback, too, but that feedback gets incorporated into writing.

The obvious advice is to always write with a specific audience in mind, a person you can visualize having a conversation with. That solves the problem of knowing when it’s OK to use jargon or abbreviations. It also helps keeping from seeming rude, something that generally happens when a person abruptly acts overly familiar or overly polite without escalating or deescalating the relationship; visualizing the relationship in concrete terms makes it hard to overlook such breaches of trust.

Less obvious advice is to review everything before you send it and (as I’ve mentioned before) take advantage of tools that will do the hard work of recognizing clichĂ©s or mismatched verbs. It’s always trendy to dismiss spelling and grammar as a shibboleth of sorts and, while technically a valid interpretation, isn’t going to stop a colleague from dismissing you because you can’t spell.

If nothing else, you should at least consider starting a blog documenting the various tools you’re learning along the way. Not only does that give you the practice of writing on a regular basis, but the blog then becomes a place for you to refresh your memory when you need to return to a tool after some time away. On top of that, if it was useful information to you, it’s probably useful information to somebody else. That’s a lot of use out of a blog.

Helping Others

The blog is a starting point on the path to realizing that there’s only so much you can accomplish on your own. Human beings don’t scale economically, because there are only so many hours in a day. If you want to be the sort of person who wants to contribute more to projects, you’ll want to think about how you can enable others to do more work as well.

This may involve supplying information to people (as with blogging, teaching, or speaking), taking on the boring tasks on a project, providing a safe environment for people to vent, introducing people who have similar interests to each other, or any number of other interventions.

Estimation

You should be able to figure out how long things are going to take, because that tells you how much a task will cost, making it easier to understand when it’s worth arguing for or against a certain plan.

My rule when estimating is to break the task down into pieces that will definitely take less than an hour, when you’re starting out. As you gain experience, half a work day is probably a better threshold. Regardless, for each of those sub-tasks, you want to think about the best-case scenario where everything works on the first try, but also the worst-case scenario, where every difficulty you can imagine delaying you comes to pass.

Then, the most useful rule I’ve ever found is to realize that every task has three parts:

  • One third of your time will be spent designing and planning.
  • One sixth of your time will be spent doing the specific work.
  • Half the time will be spent testing, debugging, and fixing what you’ve done.

You can (and probably will) mix up when these pieces happen, but I haven’t found a case where someone has “cheated” those guidelines on a project that successfully made it to a customer; it just drags out the time fixing things. So, once you have your estimate, multiply it by six, because your estimate only accounts for the work. Or only three, if somebody else is responsible for testing, but still be aware that they need as much time as you do. (The time you spend on the estimate qualifies as design, since you’re thinking about how your solution will be structured.)

When you work on a task, it’s useful to estimate it (even if nobody cares about your estimate) and keep track of where your estimate went wrong, so that you can improve your plans in the future. It takes extra time to do this, of course, but we spoke about reputation, last time, and it’s hard to go wrong being known as the person on a team who can see earlier on when the project is starting to fall behind.

Negotiation

Yes, you should negotiate your salary and benefits for a job, if you want to maximize the amount of money you earn. But on a day-to-day basis, you’re more likely to need to argue for (or against) a feature or a deadline.

As mentioned above, it helps to have numbers on your side, which is one reason that estimates are so important. But you also need to understand your colleagues well enough to be able to pitch your idea in a way that actually speaks to them instead of merely hoping that they agree with you.

It’s tempting to lie or otherwise trick someone into agreeing with you, but that always results in a more adversarial work environment, and you don’t want that. Instead, just argue the merits, but make it clear to each person involved in the decision what benefits they’ll see from the change.

Visual Design

As mentioned at the top, I have almost an entire post on how to get by on designing things without having a real background.

Ethics, Accessibility, and Inclusion

Probably since the first human learned to speak, we’ve been arguing over whether technology is “political.” If you think about it, though, technology is obviously political, because a design embodies the values of the designer in the project’s context.

However, I can already hear the screaming. You’re about to say that it’s possible to design something with no regard to values at all. But that’s wrong, because value-based decisions are being made whether they are deliberate decisions or unconscious accidents.

Because of that, it’s worth making sure you’re thinking about your values (and the values of the organization), starting with ethical frameworks.

To be clear, I am not recommending that you study everything from Aristotle to Nietzsche to decide on some prescriptive world-view. Many have tried that and precisely none of them have succeeded. Instead, I’m talking about the basics, like being familiar enough with the ACM’s Code of Ethics that you can push back if an employer asks you to do something you’re uncomfortable with.

Likewise, give thought to making your work more accessible (since we will all suffer various kinds of physical and psychological impairments in our lives) and making sure that terminology or images don’t exclude people from the product’s audience.

Taking Care of Yourself

That stereotypical nerd working twenty-hour days and refusing to bathe? Those people do (basically) exist, and
nobody wants to work with them, because they can’t focus and cause themselves other health problems.

So, do all the things that you know you’re supposed to do.

  • Wash up regularly,
  • Wash your clothes and linens regularly,
  • Figure out what you need to get a good night’s sleep regularly and do it,
  • Avoid overworking,
  • Try to get into shape,
  • If you have any medical or emotional problems, talk to a professional about resolving them,
  • Eat better, and so forth.

If you’re not doing those things, your brain won’t give you its best results. If you can only do one of those things, start with sleeping, which will give you more productive time in the day and more clarity, giving you the opportunity to look at the other issues.

Where to Go from Here

I’m wrapping up this series for now, just as quite a few states and municipalities (probably inappropriately) will start lifting their self-quarantine orders. But there is—of course—a lot more that can be said. Probably any of the headings above could be spun off into their own posts.

More to the point, though, if this is something you’ll stick with, you have projects, arguments, communities, and jobs ahead of you. By all means, keep me informed of how it’s going, in the comments or by any of the other means to contact me.

Good luck!

Credits: The header image is Untitled by WOCinTech Chat, made available under the terms of the Creative Commons Attribution 2.0 Generic License.