Your Responsibilities on a Software Team
You will not see the word “team” much in this article. Software development is the work of collaborating individuals who work alone, when it is not the work of one person. Members of a team interact constantly; in software we meet to coordinate and then disperse and work alone. Any workplace that has developers in communication as they work is dysfunctional.
In the 32 years this writer has been paid to write code the industry has gone through many changes and frankly most of them, particularly in the last twenty years, have not been improvements. Wisdom has been lost, insights forgotten. Developers who can manage great responsibility and detail are no longer esteemed but are called “silos” when in reality they are your most valuable members.
Note that my subtitle does not include any kind of methodology roles: scrum masters, product owners, and the rest. That omission is not accidental.
I have written about this in numerous other articles on Medium and I will shamelessly refer to them not in hopes of more Partner Program dollars but to keep this article focused on the essential, however I do advise reading some of them. Let’s go.
Listed below are the responsibilities that lay at the foundation of collaborative work in software. Some of these will come again under the role sections below.
In no particular order
- Specification documents are indispensable. Even the smallest project needs a requirements spec, and any project with more than a fortnight of work and two people needs a functional spec. And everyone, repeat everyone, is responsible for reading them. Testing, however you do it, is based on these.
- Interruptions are corrosive to reliable work. Workplaces should be quiet as libraries, recurring meetings are symptoms of managerial disease. The primary responsibility of management is insulating others from interruptions and the primary responsibility of everyone else is developing work habits that minimize distractions and enable concentration and focus.
- Communication is paramount. Agree or disagree, speak or write, you must share what you know with everyone on your project. If you make changes in components then those changes must be communicated clearly and proximate in time. If you explain your changes three weeks before release and then say nothing at release then you have failed. Respond to communications, be repetitive if you have to, too much is better than too little.
- Disagreement is good. Too much management emphasizes “people skills” and team cohesion. But people are going to disagree, they are going to argue, but all sides of the debate are going to come away having learned more. Managers need to step in and spread oil on the waters when things go from technical to personal, as they will. People who can’t concede a point are trouble. Study the rules of debate, study logical fallacies, don’t commit them. Make your point clearly and neither crow your triumph nor resent your defeat. This is how we grow.
- Consistency is not its own virtue. Consistency is only a virtue when the standards are good. Easiest illustrated by something familiar to us all: code formatting. Perhaps 99% of software code is close to illegible, a problem that has gotten no better in three decades, yet we still accept the notion of “personal coding styles.” Coding standards documents within groups command one person’s preferred form of jagged clutter, so the formatting imposed on others is uniformly illegible. And formatting is just an example.
- Software development is solitary work. Meetings are for dependency management, strategizing, schedule planning, delegation of responsibility design discussion, code review. But whether it’s a manager planning the work of the next year, a developer implementing his designs, or a tester writing or running regressions, we work alone. Communication while coding is an impediment; forget pair programming, forget mob programming. Close your door. Focus.
We’re All Writers
The subtitle names four roles, to be discussed below. Note that the last one is “writer.” Well surprise, surprise. That’s everyone. Everyone in software needs to be able to read carefully and write clearly. And for a lot of people in our industry, maybe for most, this is going to be a challenge. Not many who have anything to do with software like to write, and a lot fewer write clearly and thoroughly.
You don’t have to be a Donald Knuth or a Saul Bellow. Maybe the group’s language is not your native tongue. That’s OK, the style and syntax are secondary to the information conveyed. Maybe the best you can do is copy and paste an interface definition into an email. Fine, then do that.
But communication by speech is unreliable. Attention wanders, people forget. It’s actually quite astonishing how a group of people can hear the same information yet remember it quite differently. FBI agents are instructed to make records of communications as they happen, not from memory.
If you see documentation as an impediment or as part of some obsolete “methodology” (I never heard of “waterfall” except from its detractors) then you have taken a wrong turn somewhere.
Your writer often freelances, working with clients whose designs are always a lot more vague than they think they are. I will not work without a spec, and since the client usually doesn’t have one it’s usually me who writes it. And development begins when the client has concurred with it. The alternative is argument about who said what.
If your workplace is communicating technically vital information by more than one modality (email, Skype, Asana …) or in a completely useless one like Slack then you have nothing but trouble before you. Documentation should be under the same source control as code.
Cultivating skill at writing will do you more good than studying the latest Shiny Object. When you write you cannot help but organize your thoughts and you will absolutely always run across holes in your designs that you hadn’t realized were there. You will have fewer bugs and you will have to revisit your work a lot less.
Read them. As best you can, write them. I can’t emphasize this enough.
Collaborate, Don’t Compete
The pity is that this even needs saying but it does. As with the abhorrent whiteboard interview many companies follow Microsoft’s lead and at Microsoft coworkers are competitors. The vile stack ranking system may have been thrown out seven years ago but under that coworkers were tacitly encouraged to sabotage each other; I experienced this personally when I took over another’s project and he gave me misleading information to waste my time.
But it doesn’t take something as brazen as stack ranking to give coworkers who nominally succeed together or fail together an incentive to act as showboats.
If you have a coworker who refuses to communicate you have a problem; take it up with him before you go to managers, give him every chance, but he can take you all down.
And then there is the case where it’s the manager doing a lousy job. Beware managers who speak in Buzz, these are practiced evaders.
It’s at this point that we need to mention Flow.
Summary: even before the PC revolution and the explosion of IT the few companies employing software developers had noticed that some of them were much more productive than others. Not by tens of percent but hundreds. Research showed that
software developers who were able to maintain states of prolonged and uninterrupted concentration were significantly more productive and did significantly better work.
It was recognition of this phenomenon and placing it at the center of management that enabled the phenomenal early days of Microsoft.
But somehow everyone forgot about this, the uninterrupted workday gave way to increasingly frequent meetings and other …. no, it was meetings.
Productivity dropped, frustration increased. But rather than return to what worked before we got what we now call methodologies, with more and more meetings and more and more process. Flow is a memory and many younger developers have never experienced it. If you read one referenced article in this one, read the one linked just above.
If we want to bring back the joy and the productivity we need to bring back the opportunity to focus.
But management of software development is currently dominated by the methodologies, primarily Agile/Scrum. I will not pretend these are distinguishable; in theory Agile embraces many potential approaches to a systematic structuring of development but in real life there is only Scrum.
Methodologies mean more meetings. We could compare and contrast Kanban and Scrum, whatever, but they all mean more meetings and that means more interruptions and that means that the halcyon days of Flow recede in the rearview mirror, and that is a goddamn shame. Developers under 40 have likely never known anything else and cannot imagine a workday that doesn’t begin with a status update meeting. Managers tend to embrace the methodologies and have never known just how much more productive we could be were we allowed to concentrate.
For junior developers who have yet to develop structured work habits these meetings may be of some benefit but for senior people they are impediments.
This is not my area of expertise; the only time I managed a team it was a stressful experience and enough to tell me that this is not where I wanted to work. So this section is from the standpoint of the managed, not the manager.
Protect Your Team From Interruptions
A manager’s primary responsibility is to get the obstacles out of your way so you can perform. And the obstacles that matter most are distractions and interruptions. Minimizing interruptions begins with minimizing meetings. It’s relatively easy to structure a workplace to let us concentrate on our work; that’s how almost all software companies operated thirty years ago.
But with more and more levels on the org chart populated by people who have never worked with code but who come from backgrounds in business, meetings are regarded as a productive use of time. This is rarely true.
If you are beset with recurring meetings then you have trouble; holding a meeting at 2 PM on Tuesday just because you always have a meeting at 2 PM on Tuesday means that the rest of Tuesday is shot. If you were in a good productive state, it is gone for the day. Recurring meetings are red flags.
If everyone is told to be at an early morning meeting requiring a rush-hour commute then your lead is an inconsiderate lout. Scheduling a meeting before 10 AM means you will arrive at work already peevish and weary unless you enjoy inching along in allegedly moving rush hour traffic.
Interruptions and distractions are the bane of productivity and quality work. Managers play the greater role in minimizing interruptions; those who report to them play the greater role in minimizing distractions. Turn off notifications, put on headphones, close your door.
I have had many managers and a lot of them were dishonest. When on his first day a manager tells you an obvious lie you’d better start looking around for other work because you’re in a no-win condition. It can take the manager’s manager a long long time to realize that his new hire is a liar and by then, as with a recent job I poured my soul into for three years, all the developers leave the company.
But let’s assume you’re working for a manager you can trust. He will stand up for you and protect you from the caprice of planners who hand down man-killer delivery dates that have his reports at their desks at 3 AM Monday morning, having started at 8 AM Sunday morning.
Push Back Against Unreasonable Schedules
Don’t agree to deliverables that have your reports putting in 80 hour weeks. It’s your job to push back against this kind of abuse. Do your job. The 60–80 hour week is unacceptable; younger developers can stand it for a few months but it takes its toll in stress. On the Vista project at Microsoft everyone looked haggard and weary and entire hallways resigned.
The S stands for “spec,” or specification. You know what the RTF stands for. Too many people in all phases of the industry don’t read documents, A lot of them have grown up on short attention span entertainment, never watching anything on television longer than a few seconds, playing electronic games all day, having what David Bowie called “one-inch thoughts.” They can read a tweet but have a very hard time finishing a book.
We who write have had to learn to use shorter paragraphs and more bullet lists. We have to keep the same in mind writing specs. OK, fine, we can do that, but reading them is as much a part of your job as writing code.
Part of the scrum methodology and TDD is an explicit deprecation of documents. I think this is really bad. Supposedly coding against verbal descriptions or using unit tests in lieu of documentation imparts flexibility; this is absurd. Anyone who tells you that the unit tests are the documentation is a fanatic, and fanatics are not reliable sources of information.
Stability is Job One
Customers will forget a slow-loading page if later it works satisfactorily. They’ll remember crashes a lot longer and will either angrily call tech support or leave bad reviews.
Developers’ first exposure to IT is the terrible whiteboard interview where they are inevitably told to write some screaming fast hyper-optimized code; small wonder they end up thinking this is their life’s work. They’ll break the rules to optimize code whose performance doesn’t matter because it’s part of the user interface.
Forget cleverness. Forget about speed optimization outside the 1% of the code where it matters. Don’t break the rules to run a microsecond faster. Write boring, stolid, legible code that never breaks.
There are two problems with code reviews
- They are absolutely critical.
- Hardly anyone takes them seriously.
Code reviews are a core responsibility and everyone doing a review should pull down the branch in which the changes are made and use the IDE reference listings to not only analyze the changes but see them in the full context and even perhaps in a debugger.
One of the most frightening fanaticisms around test-driven development is the widespread attitude (not drawn from the book but from people who take it way too seriously) that developers should be solely responsible for testing their own work. This is crazy. The same blind spots will show up in the tests as showed up in the code.
Code Reviews Don’t Work. Here’s a Better Idea
And don’t tell me about pull requests, they don’t work either
The same applies to code reviews. Whether over Zoom or in person, most attendees of a code review session are seeing the code for the first time and out of context. Code reviews tend to focus on formatting quibbles and other minutiae instead of the real context of the project.
If for example an existing function has been changed then a worthwhile code reviewer will examine every point where the function is used to verify its contract is still correctly followed. This cannot be done flipping through paper or reading a pull request.
Developers are usually too busy with their own tasks to give a code review the attention it needs. Calling a meeting is as much a waste of time as most meetings; code reviews are too vital a responsibility.
I review every commit in a project unless it has the vastness of an operating system. It takes some time. Sitting in a meeting flipping through pages fresh from the printer isn’t a code review, it’s checking a box
Ask any software developer what we spend the most time doing and you will probably hear “writing code.” If the answer is “trying to stay awake in meetings” then be sympathetic. But
the activity that occupies more of our desk time isn’t writing code, it’s reading code.
Even while we’re entering new code we’re reading its surroundings. As a matter of fact we spend more time reading code than everything else put together.
Knowing this one would think we would all be doing everything possible to make this easier and more reliable; alas, the opposite is closer to the truth. Most code is jagged, cluttered, poorly structured and approximately illegible.
The two primary issues here are formatting and structure.
As concentration at work became more difficult and then nearly impossible, developers’ work quality dropped sharply. But rather than return to what worked before, minimal interruptions, the new approach is a vast emphasis on testing. Test-driven development is an absurd fad
yet it is considered normal, even indispensable, and is rife with hot-eyed fanaticism. Its supporters quote statistics comparing TDD to no testing at all, which is dishonest.
Yes, some developers handed untested rubbish to QA departments who found bugs in basic functionality in minutes, and yes, that was irresponsible. Developers need to do some testing but the idea that developers should bear sole responsibility for testing their own work is crazy.
Test your work. I don’t recommend unit testing because it’s too much work and often requires creating fake data sets and making design compromises. Yes do some testing before throwing your work over the wall to testers.
But don’t lose sight of the fact that while it is essential, testing is secondary.
Developers and testers should work closely together. Core testing should be based on a functional specification that describes expected behavior and unprejudiced by knowledge of the code and implementation. This is Blackbox Testing and it was the standard before TDD adulterated development priorities.
Regression testing is a vital part of our work, assuring that our changes don’t break what has heretofore worked correctly, but that shouldn’t happen in the first place. The only appeal of unit testing is that regression testing is automated and can be done as part of the cycle. But it leads to zombie armies chanting in unison the false confidence of
When the tests all pass, you’re done.
A good tester is worth his weight in gold. But even someone who couldn’t code Hello World is better than no testers, or having developers do all their own testing, which is little better.
Software development has been corrupted by management paradigms and methodologies and the most important part of our work thirty years ago, unbroken concentration, has been forgotten. I’ve written about documents and code reviews but it is Flow that we need to restore to get back our productivity.
And our joy.
I am the quintessential “lone wolf” and autodidact. I am self-taught and I was hired in 1989 by Microsoft to do QA on WindowsNT; five months later I was a developer on that project. Before finishing three years as a developer I had singlehandedly written two entire Microsoft products in the SQL Server group.
I got my software development chops working in single-occupancy offices in groups that met once a week. And I watched all this go away.