This week’s topic bridges the two worlds I work in so they may be introduced to each other, lovingly caress each other and curl up into a fetal position to talk about criticism. For anyone that doesn’t know me, I have a very steady career in software development and I write in my spare time. Why would I do this? Why does anyone do anything? Fun and profit. I develop software because it is fun and profitable, and I write fiction because it is also fun and I hope to make it profitable one day.

Let’s talk about melting these two worlds together and discuss something everyone really hates: criticism. Let’s face it, you’ve written a 690 page single spaced manuscript that you believe has flourishes that would make Oscar Wilde beam with pride and you don’t want to be told otherwise. You need to be told otherwise. Unless you plan to never get that epic published, you need criticism. There isn’t any need to fear it, but you DO need it. I learned this about my own manuscript recently. It has stuff wrong with it, parts I’m sure I will discover drag. I took over a year to write it, and I’m very defensive of it because of that work, but it needs more work.

This process seems like something that the writing world isn’t new to and you guys have it down pretty good. You have folks that are fantastic editors, subsets for content and creativity editing, folks that can help you with flow and contradictions. All of this available at a price, and it should be as time is a valuable commodity. It also seems like you guys have it down to a nice scene for remote criticism or are generally pretty nice to each other in face to face critique and reviews. Well done, points for humanity there.

Let me welcome authors and writers to the software development world and introduce you to what can persist as a pure nightmare. There is a lot of information to follow, you may get bored, but there are questions for you at the end. To start with, I should be clear about one thing and some people will fight me on this. Writing code is an art form (collective gasps from readers). It really is, ask any programmer you know and they will tell you they’ve seen code that is ok, code that is the purest emblem of beauty and science wed together in a compiler, and they’ve seen code that is complete and utter shit. Walk through any museum and you’ll see the same thing. Walk through any library and you’ll pick out books that you describe in that exact manner. Developers just have a different view of code as art.

Along with that world of code as an art form, you have critics, and we are ALL critics. Some of us are harsher than others. Silicon Valley fans that don’t work in development may be surprised to hear this, but that argument regarding tabs vs spaces is real and can bring out some extreme opinions from two very similar developers. How variables are cased is another one that sounds petty, but can derail an entire week of work (var thisIsAGoat vs var ThisIsAGoat vs var this_is_a_goat). Syntactically, those were all the same goat, but they will fight you.Now that some opening salvos have been fired, let’s talk about criticism. There’s good and there’s bad. The bad is actually a wretched process of agony that will give you severe anxieties and increase your alcohol tolerance.

The Process

So here’s the process. As a developer, you get the requirements, you think through how a feature will work, how data comes from point A and goes to B. You write some tests and write some code. Eventually, it’s done and working, the specifications are met and you are ready to deliver this thing you’ve built. This process varies, but if you are in a good environment then they’ll want to do code reviews.

A code review can be a simple or complicated process, depending on the people and organization. It’s just a process for at least one other person to look through what you’ve built and answer some basic questions. Does this meet the specifications? Does this match our coding style guide? Can anything be written better? Are there some glaring mistakes?

I’ve worked at a few different shops over the years, here are some examples of how it worked well for me personally.

The Good

What’s worked well to me, and this is becoming more common, are review systems. It sounds like overhead and process and all that crap nobody wants to deal with, but trust me, when you read the bad you’ll understand why it’s worth the overhead.

If you come to my blog and have had any experience with Git/Github, you may already be familiar with their pull request process for bringing in new code and performing reviews at that point. For my non-programmer readers, when you want to deliver new features/code, you don’t just save it and it goes straight into the program. If that’s what you’re doing, then I hope to any higher power you hold as a creator that you are the sole developer on that product and project.

Back to how it works, you are requesting that this thing you’ve made/changed get merged into the original code base. In Git, it’s a pull request. There are other tools if you have other code repositories. Some of the best that work with code repos automatically that I’ve seen are Jet Brains UpSource, Atlassian Crucible and there’s an open source one that comes with Phabricator called Audit. They have slightly different user interfaces, but they boil down to the same set of features.

1. I can show the differences between my code and the existing code
2. Parts that I’ve deleted are shown and it’s clear they are being removed
3. Parts that I’ve added are shown and it’s clear where they are being added
4. I can give some information about the change happening
5. Others can view my review
6. Myself and others can make comments on the same lines of code and the UI will put them on the screen in such a way that it is clear where the person is talking about something with a code
7. The commenting helps me facilitate a discussion about the code and can help me resolve issues or make tasks to fix any issues.

Having these software tools to do this may sound like abstracting a face to face interaction that could be more beneficial. I get that, I really do. In smaller organizations, that may be better, just sitting down with another dev and explaining it, hashing out issues and get the whole process over easily. The abstraction to a tool is better in my opinion though for a number of reasons.

1. People don’t always have the time to sit down right now to review your code
2. The commenting is kept and I have a log of what to do, not a random sticky note or a bit of chicken scratch that I can’t remember what it means the next day
3. The review is now an archivable piece of documentation that we can revisit if new bugs occur or we want to replicate something
4. People are people and they get anxious, not everyone likes to just sit down and hash things out in close quarters
5. The other team members may not be in the room, or same city or even the same continent

Using a tool for doing the code review as an online process, I’ve had other devs ask leading questions like, “why did you do it this way?” And that’s fine, I can take a few minutes, look over the code again, search for best practices and see if maybe there was a better way to write something. I get the opportunity to admit I’m wrong gracefully and commit to fixing the issue. Or I respond and it’s teaching my reviewer something maybe he or she doesn’t know or hasn’t encountered before.

In other situations, devs may not go with leading questions. They may start the conversation as, “this is a bad way to do this because of x, please rewrite this to do y instead before we merge.” That’s fine too, it still facilitates the same discussion and I can always defend what I’m doing and push it back if I feel I am right. The point is that we still had the discussion and more than one person knows what is being brought into the larger project.

This process isn’t perfect, and I’m sure many a Github project has had to deal with trolls in the reviews. I can see where the way the commenting can roll, it would be easy for a troll dev to come into reviews and start flaming devs with just adding unhelpful comments like “lol, noob”. That’s not likely to last long though as that dev will just get blocked from projects and people will move on.

The Bad and ugly

I’ve only really dealt with this at one place I’ve worked. The process sticks with me still after having left them nearly a decade ago. I would follow most of the same steps as before. Requirements, development, ready to merge. Instead of a tool though, I had to schedule a code review. I needed to:

1. Book a room
2. Invite at least one other developer
3. Invite my supervisor
4. Invite the department head
5. Prepare for hell

At the code review, I would have to explain what it was I was trying to do, go through the bug ticket or requirements documents. Once we all knew the requirements, I would literally have my code on a projector walking through everything I changed. At any point, people could stop me and ask questions.

This may not sound too bad at first, but our department head seemed to believe in two philosophies: the Socratic method and give a person just enough rope. If he saw something, regardless how minor, he would stop and ask something like, “on line 54, why did you do that?” “Why did you choose to use a string instead of an integer?” “Why is that an array?” “How will that facilitate concurrency?”

He would lead you on with these questions and eventually you would get to the answer he was trying to pry out of you like a molar with a twisted root. That whole process can take a while and I grant you that you will learn something. I learned a lot through this process. I do believe it did make me a better developer overall. The process did help take me from code monkey to developer/engineer. At the end of it all, I would still have drinks every Friday with every one of these people as well, though that may have been part commiserating and part reinforcement into Stockholm syndrome.

So, if it worked to make me a better developer, why is it bad? Are you kidding me? Of course it’s bad. That company had a higher turnover rate of developers than anywhere I’d been. Yes, it made me have a thicker skin and made me a better developer, but almost at the cost of turning me into the Socratic dictator as well. It doesn’t work with everyone, hell it barely worked well with anyone. Survivors of that company still agree that it was a miserable process.

It took a lot of time (some review sessions required multiple meetings), scheduling was hell and you couldn’t even be sure that everything was always answered or fixed as it wasn’t actively recorded. It was also very traumatic. Some developers would leave in tears. Literally, it would break them down.

You’re rambling, what’s the point?

Yes I’m rambling a bit, but I’m doing some crossing over in my career for writing as a side project and wanted to see if I could bring some of that back. I have been working in software development for nearly 15 years now. I did some creative writing classes a decade ago and wanted to get back into writing. I’ve been working on my side project of a novel for a bit over a year now. I’m finally at a point where I’m doing revisions, editing and rewrites.

I have no idea what to expect in the writing community from that process aside from what appear to be happy interactions by people in some critique forums and examples posted by some professional editors. So, writers that may be visiting, here are your questions

1. Are there any tools you use for this process or is it mostly review/notes in MS word?
2. How many editors/review sessions do you generally work through?
3. How often do you end up scrapping the whole thing and do a complete rewrite?
4. What are your horror stories of the process?

Honestly, at this point in my career, I feel like my skin is probably thick as dragonhide, but what should I expect? I’m fine with people telling me something is complete crap if they can give some solid backing, but will they?