The software company

  1. Do you have and use whiteboards?

Software development requires communication and brainstorming. Software management requires keeping track of tasks. The whiteboard is the perfect tool to satisfy both needs. You can’t brainstorm on a piece of paper, and if you like SCRUM methodologies you need a surface for you task stickers.

A technology company that does not provide whiteboards is seriously limiting its employees ability to communicate and describe abstract concepts in easy to grasp, easy to remember pictures. I would think twice accepting a job in any company that does not have whiteboards.

  1. Do you invest in your own tools?

Any technology product builds on previously established tools. In the startup phase, these tools are external ones, either opensource or commercial products. As the startup grows, so does the need for specialized tools, such as a deployment infrastructure, a specialized library for core business tasks, classes and functions to reduce boilerplate, documentation. You must invest in these tools because they increase the velocity of development, yet investment in these tools is considered waste because it does not generate revenue. Truth is, your developers are customers too, and specifically they are customers that consume money. The more they have to fiddle with your own broken tools, the less efficient they will be. Invest in your tools, or your ability to deliver will be crushed under their ineffectiveness.

  1. Do you understand s = v * t?

The most basic law of motion tells you that in order to cover some distance, you need time and speed. The interesting, and rather trivial point out of this equation is that once you fix one term, the remaining ones

Velocity depends on many different factors: your team effectiveness, how good are your tools (internal or external), how complex and research-glazed is the task you have to address, new hires entering the team, context switches, but barring disruptive shifts in tasks, your team’s velocity is pretty much a constant. This leaves

Menacing your team of layoffs, or proposing incentives will not change velocity. It will just increase time (they will work overtime), but this affects velocity (people are tired, introduce more bugs, skip over important details) so the net result is less motivated individuals and a lousy product.

  1. Do you respect your employees?

Software developers spend 8 hours a day in front of a computer. Respecting them Respect comes in many different forms.

  1. Do you plan ahead?

Employees get sick, or leave. Do you account for that? Do you account how to react to the increase in amount of employees? who trains them? who buys and installs their computers?

  1. Do you have loose, but full code ownership?

Any software developer or manager has his own opinion on this one. Code ownership has always been a hot topic. Those in the field of Agile tend to favor collective code ownership. I propose that every brain works in a different way, and establishes different rules and conventions to build something. Those who claim shared code ownership encourage sharing of these conventions, but in practice, for large codebases, these conventions are too many. Some redundancy is good, but in practice you should leave the code in the hands and brain of the person who built it first. He knows the rules of its own universe, he aderes to them and is hopefully more consistent than a bunch of people acting on it.

Coding is not wikipedia. Wikipedia does not rely on logic to build a meaningful narrative. Coding requires correctness and logical consistency.

  1. Do you encourage removing obstacles?

employee has a problem and can’t solve it. What should he do? Spend one hour in front of the screen trying to figure it out. ask the other guy who in 5 minutes knows the problem and fixes it. Disruption.

  1. Do you track progress with a physical medium?

Nothing is more frustrating not to know how far you are, what needs to be done, what is still pending. I’ve seen plenty of times when things pile up due to urgency.

We are sensory driven animals. We manipulate objects and having objects represent what needs to be done is essential.

  1. Do you have a technical lead and a project manager?

Conflicts arise from poor management.

  1. Do you ask relevant questions at the interview?

I lost count of how many times I’ve been asked to traverse a tree depth first at a job interview. The problem I have with this kind of question is that they are irrelevant. I have 10 years of experience in scientific coding, and never in my own career I had to traverse a tree depth first. If I have to, I use networkx. No job position for a senior level coding requires you to be able to traverse a tree depth first.

What is then, a relevant question for a job interview? There’s only one. “Show me and explain me some code you wrote, and eventually add a small feature for me during the interview”.

  1. Is the team involved in the interview process?

Any hired person must mix well with the rest of the team. If management is excluding the team from the decision process, it is disregarding the most valuable contribute in selecting the candidate, or asking the important questions considering the state of the current codebase. Does management know we desperately need someone that is a wizard at gdb, because we are plagued by low level crashes since a year? Will they keep that as a checkmark during the interview process?

  1. Do you keep up with technology?

Sooner or later, something of your hardly implemented solutions will be implemented better by some external product. It is time to move away from your internal product. You are delegating problems. I’ve seen plenty of times when stubborn developers clinged to their own file format when HDF5 offered the experience of a full research team whose goal is to deliver the most performant file format for scientific storage. Your business is in developing scientific software, not in developing file formats. Ditch your file format. It made sense 10 years ago, now it’s time to move on.

This is also important because people working for you are not only here for the money. They are also here to learn new techniques. Using internally developed tools does not enrich their curriculum, and if they don’t want to become irrelevant on the job market, they are not going to like it.