There, I said it. Based on everything I've read about Agile (capital A) software development, it's sort of like the taste of coconut. You're either like "GIVE ME ALL THE COOKIES" or "OMGWTF GET THAT #$%^ AWAY FROM ME". This isn't a software development blog, and I'm just
I am going to talk about Agile, and software development, and PTSD. There's not much out there that I've been able to find that puts these things together. There's about to be a little more. I've been looking at Agile, and things agile, as a way to be more productive writing code at the same time as I'm learning to cope more effectively with PTSD.
This is, in a way, my end of summer report.
I have some experience with the waterfall model, as that's what I learned in Software Engineering a few years ago when I took the class. We spent hours and hours and hours on documenting requirements and design and schedules, and even more hours updating the documentation whenever anything changed-- which happened quite often. Ultimately, we built then project for the class, and then another project for our real world customer that was actually useful.
The military was a lot like that, in that a great deal of time was spent planning and forecasting. However, when the shit actually hit the fan, you took what you'd learned in training and applied it to the situation at hand. Many, many things carried forward into reality, but when we deployed to the Desert for real the situation wasn't exactly what anyone expected. What my customers there needed from the equipment I had to work with wasn't always easy to make happen, and was sometimes impossible enough that we had to come up with very different answers. I was quite honestly frustrated to no end in my Software Engineering class for the same reason. You can plan only so much ahead of time. (There's a 600+ page report written in 1993 about Desert Shield and Desert Storm, talking about what went wrong and what went right. It took longer to produce than both operations put together.)
It should be noted that I'm a hacker. I believe in, and value highly, the creative aspect of building a thing using software-- a thing that you might not have a 100% clear idea of when you start, but that takes shape as you think about it and play with it. Software doesn't start out as a living, breathing thing, but that's what it becomes.
In the Dot Com days (before the bubble burst), I worked for a company that built what amounted to cookie cutter web sites. Our customers were real estate companies, who paid a certain amount for a complete package that included an interactive voice response system (the number you see on the signs outside of houses for sale) and a website that listed all of the homes they had for sale. It was a chaotic environment; the words factory and sweatshop were often used to describe the pace. Specifications? Hah. No such thing. The graphics department would draw a mockup, and we'd cut it apart and add the interactive features and connect it up to the database. Programmers didn't talk to customers, ever.
We weren't even allowed to talk to customers. Requests for changes came through an account manager, then went through the technical services manager, who assigned them to a programmer. Questions went back through the same chain of command. Ever play the game where you sit in a circle and tell the person next to you a secret, and by the time it gets around the whole circle the secret is changed? It was exactly like that.
Often, several different programmers worked on each web site, and since there was no quality control process (and no source code control!), Shit Got Fucked Up A Lot. Someone would make a change to fix one problem, which would cause another problem that someone else would have to fix. I'd always make waves by testing in Netscape Navigator in addition to Internet Explorer, which almost no one there did. That was the extent of the testing method there.
Clearly, this didn't work either. You're probably not shocked to hear that the company no longer exists.
Fast forward now, to me being back in school and again learning about writing software. A couple of years ago I got into hackathons, where you build an entire project from scratch in 24 or 36 hours. Specs? What are specs? No such thing here either-- you start with an idea and refine it as you go. Maybe you don't even have an idea of what you're going to build when you get there. I usually don't know what I'm going to try to build until I talk to the sponsors and mentors that are there, and then I try to choose a new API or product that I've never seen before. If I'm on a team, I may have just met my teammates. If any situation ever required agility, a hackathon is that situation.
In CS classes, you're given a specific project to work on. The professor gives you the specs, and perhaps some of the code, and you write your program so that it passes the tests. Although you get some test data to work with, you don't get to see the tests that determine if your program works (and which determine your grade). Part of the challenge of the assignment (and in programming in general) is that you have to account for edge cases and make sure that your code always does what the spec says it should-- no more, and no less. When you think it's done, or when the deadline is nigh, you turn it in.
The ACM Intercollegiate Programming Contest (which I've participated in) works much the same way. If you use the wrong algorithm, or incorrectly implement the right algorithm, your program doesn't pass the tests. No balloon for you, but you can fix it and submit it again, albeit with a time penalty.
If you're really lucky, you have a professor or two (or even a class) that teaches you something about debugging and maybe even how to test software. There seems to be the assumption that if you do all of the planning up front, your software will be bug free. Hint: it doesn't happen. Yet, no one spends any time on the art of debugging. You never hear about test driven development, or user stories, or setting up a task runner to run automated tests, or even why you should consider doing so. (I know, not everyone thinks Agile is a good idea, especially some CS professors.)
I'm a hacker (I know, I already said that). I also work at a university help desk; we have 40,000+ users just counting the students here, so I'm going to go ahead and call it an enterprise. When something is wrong with software, it's my job to either find a way to get it fixed or find a way to make things work. Some software, frankly, sucks. Working at a help desk, I get to hear about the various ways in which software (and sometimes hardware) sucks. There are hackers, and a lot of CS students, that look at working at a help desk with a certain amount of derision-- like, ew, I'm a rockstar hacker. I'm not one of them. You don't really have a good idea of what people think is important about software until you're on the phone with them an hour before their final assignment of the semester is due and the damn software doesn't work.
If you add up all the time I've spent in the military, CS classes, the ACM Programming Contest, programming for money, help desk for money, hackathons, and hacking in general, it's probably a good sized amount. It's been in pieces though, and I want to make writing good software that people use into a profession. PTSD wants to mess that up, and the PTSD isn't going away-- it's not like a cold, where you just get over it and you feel better. It's a thing that interferes, and must be dealt with.
I promised I wouldn't try to sell you a book or a seminar-- and I'm going to keep that promise. There are, however, some aspects of Agile development (and/or extreme programming, etc.) that I've found to match up really well with both my experience (which you just read about), and my disability (which is PTSD). I don't claim to "know Agile", and I'm not trying to teach (or preach). What follows are the things from agile that I've been learning about, experimenting with, and finding useful over the course of this summer, in relation to overcoming PTSD and getting shit done.
The Job Accommodation Network has a list of ideas for accommodating employees with PTSD. I've been using this list over the summer as a guide, since it's what employers use as a guide. I've also been loosely following the principles behind the Agile Manifesto; I've honestly found that the things that make Agile what it is are directly applicable to making software development work better in the context of dealing with PTSD symptoms, for me, over the course of this summer.
Some things are easy to remember; some things are easy to forget. It's said in your very first CS class: comment, comment, comment. I leave notes and bread crumbs all over the place in the form of comments in code, because at some point in the future I'm going to look at this code and ask "what the hell was this joker thinking?", except that the joker was me.
I use the heck out of jsdoc to auto-generate documentation for my code; every time I run 'grunt test', I have a task that regenerates the docs for the the entire code base I'm working on. Especially as my projects have grown bigger, I often need to reference functions that I've already written to see what parameters they need, or what type gets returned.
If I find something wrong with how my app works, I open a GitHub issue and describe it in as much detail as I possibly can. This is something I've learned from working help desk, and from the military-- there's no such thing as too much information about what went wrong. Email helps with this when it's something I'm writing for someone else, because I can look up a past email if I need to remember what was said. Slack is also good for this because it's searchable, but more on Slack later.
I record lots of things, especially things I read online, using Evernote. Class notes go into a separate notebook for each class. I have a specific notebook for things that are work related. I also use tags religiously. I may not remember everything, but if it's important I probably have a copy of it.
When I have ideas-- whatever they are, whenever they are-- I have to write them down or they are lost. I keep a pocket sized Moleskine notebook and a pen assigned to it in a particular pocket in my backpack.
I need to work on exactly one feature or one exactly problem at a time, and equally important I need to be responsible for only one task at a time. Often, when I'm having trouble concentrating it's very helpful to be able to switch tasks to something smaller in scope. Having scores assigned to tasks rather than a set number of hours, as well as being able to pick from a board of tasks, are both very helpful here.
I need a quiet place to work. This doesn't mean absolute quiet all the time; I can manage in an open plan setting, provided that the people around me are people who like quiet too. Ambient noise is ok. Sudden, unexpected noises (phones ringing, doors slamming, laughter, and especially PA systems), are not. Nervous tapping of pencils or whatever drives me up the wall, so please don't make me sit next to someone that does that.
Sometimes I do need absolute quiet, to the point that I can appear antisocial. It's not personal, I just need quiet.
During classes, and now during meetings, I use a Livescribe smartpen. Yes, you are being recorded, and yes, I am taking notes. I'm not taking notes so I can one up you later on, I'm recording and taking notes because at some point in the meeting I'm going to lose concentration and miss something. It's going to happen. Later on, after the meeting, I'll review the recording and my notes and fill in the blanks.
If I have earbuds in, or headphones on, don't bug me. Chat me on Slack, email me, wait till later. I know programmers have bitched about interruptions since there have been programmers, but with PTSD it's even harder to come back to a task after being interrupted.
Automated testing tools are a godsend. I use Grunt to set up tasks that check code for syntax errors, check json for validity, enforce coding standards, create docs, move the right files into the right places, and a ton of other things.
If you ask me how long something is going to take, the answer is "I don't know". I can give you a bullshit answer, but it will be wrong. I don't have a very good sense of time. Two weeks ago, twenty five years ago, and yesterday are all the same to me. It's like being color blind, but with time. This is what happens with re-experiencing, you slip in and out of past events and the present. Assigning scores to tasks that show complexity, rather than how long something is supposed to take, is again a lot easier to work with.
If it's not on my calendar, it doesn't happen. Period. If you want to talk to me tomorrow, tell me today and make sure I whip out my iPhone, put you on my calendar, and set reminders for ahead of the event. I also set travel time reminders to make sure I leave early enough.
And, I still might be late. It happens. I don't like it, and you probably don't either, but some days I'm completely off sync and can't get where I need to go on time to save my life. Usually it's because I didn't sleep much (or well) the night(s) before, and overslept. It's not meant to be disrespectful. If I'm late getting in, I have no problem staying later so you're getting your money's worth.
I'm not big on meetings, but a scheduled weekly meeting (scrum, if you will) is a good thing because I know when it's going to happen and I can prepare for it ahead of time. Send me an agenda, even if it's just a simple outline.
I rely daily on my military experience to keep things straight, but PTSD can throw things off track very easily. If I get triggered, there goes concentration and time management and memory out the window. There are some times that I'll seem really disorganized, and it might take me a little bit to answer when you have a question about something I'm working on.
I mentioned this already, but I use GitHub to create descriptive issues when I find something is wrong, or I'm adding a new feature. Might go without saying, but I use git-- command line git, not the candy ass GUI version. :) When I'm working on projects alone, I create a new branch for every issue so I know exactly what I'm working on.
Post-it notes suck, to be honest. So do index cards thumbtacked to a wall. I'm much better with tools that a) are available on my iPhone, because it's always attached and b) I can have up on one of my monitors where I can always see it and interact with it without having to go look at a wall board somewhere.
I'm in love with Waffle.io, which integrates with GitHub function to make a really nice agile-y interface for tracking tasks in four columns: Backlog, Ready, In progress, and Done. Create a new GitHub issue, a card gets created for the issue in the Backlog column. Close an issue via a commit, the card gets moved into Done. I can't say enough about Waffle. It's been a lifesaver.
Trello has a similar interface, boards with columns, but it's not natively integrated with GitHub the way Waffle is-- Trello has been a lifesaver too, especially at work where I use Bitbucket for git for projects. Even without integration between Trello and Bitbucket, I have a Trello board set up for the project I'm working on with the same columns, a card for each issue.
I also use Evernote to keep a work log, which is set up as a notebook with a monthly log of what I've been doing at work every day I work. In the Trello card for a task, I include links to commits I make to the git repo. In Evernote, I include links to the Trello card (and if appropriate, the git commit).
The point being, if I lose track-- for whatever reason-- of what I'm supposed to be doing at any given time, I have bread crumbs to follow. If something's wrong, I have a place to look to see where things went wrong. I can roll back changes if necessary. If I'm distracted, I know where I left off.
Sleep (or a lack thereof)
I take medication that helps with nightmares. Sometimes it works a little too well, and I end up sleeping through all of my alarms and I wake up ten minutes after I was supposed to be somewhere.
Some nights, I don't sleep at all. This is a combination of things; one is that if I'm not feeling well I'll often work harder, in an effort to try to work through things. Sometimes, especially if nightmares have been an issue the past couple (or few) nights, I won't want to sleep because I don't want to dream.
Being up late at night when the world is quieter means that my body's clock is at odds with everyone else's. Therefore, I have the 1300 rule-- if you want to see me, talk to me, or otherwise get a response from me, do so after 1:00pm. Right now this works with my work schedule, but I don't know about the future. I'll deal with that when I get there.
Flex time is so helpful here.
Coping With Stress
Sometimes, I need to step away. I need to go outside and go for a walk, or I need to leave a meeting, or on a particularly bad day I might even snap at you or someone else. Usually, I can't explain it because I haven't yet come to grips with exactly why I'm stressed-- so no, I don't want to talk about it. Don't tie me to my desk. Being able to get up, go for a walk, stand outside for a little bit, go get a fresh cup of coffee, etc. without being hassled about doing so is really important.
Flexible hours are like manna from heaven. If I can't give you all of hours you want from me today, I will make them up. That being said, I often like working at night (sometimes very late at night) because the world is quieter and it's easier for me to concentrate on what I'm doing without so many people around.
I'm trying to exercise more, because it helps. It's just over a mile from my apartment to work, and I walk both ways unless it's dangerously cold outside-- my Misfit says I take about 10,000 steps a day.
I'm actively in therapy at the VA Hospital. I take medication. I practice mindfulness.
Interacting with Supervisors and Other Employees
This is a tough one-- technically, I don't have to tell you that I have a disability. Well, too late now. :) It's hard to admit that I have a disability because I don't want you to think less of me. I don't want you to think that I'm not a good programmer as a result of having a disability, or that you can't trust me or rely on me. Sad to say, there is a stigma often attached to PTSD, especially with veterans.
I am still learning how to deal with PTSD and work. In the past, I didn't know a lot about the complexities involved. I'm beginning to understand them, a little. The point is, much like developing software, I don't always know that I need an accommodation until I need it. Every workplace, and often every project, can be different.
Communication is really very important. I like being left alone to work, but keep me informed and in the loop. I want to be a valued member of the team. I want to contribute. As much as I might try to avoid interactions sometimes, it's usually because I'm stressing about things-- my PTSD flavored world view is that there's danger around every corner, and software development is no exception. Face to face meetings really help alleviate that.
I've been through a lot, and I can adapt to damn near anything, but it's better if you give me a chance to adapt after you've tossed procedural change at me. I like routines. If you upset the apple cart, it's going to take me a little bit to set things straight for myself. If you have to tell me something that you think I won't like, be direct. If you have an order to give me, give me an order. If it's a software issue-- you need something changed, something is borked and I need to fix it, you need an update on my project, a new project has come up-- that's cool. Change is constant. I know that software requirements change, and I like that, because it gives me useful work to do.
I already mentioned punctuality in time management, but I'll mention it again because companies like to use time clocks. I'm chronologically challenged. I will do my best to be on time, but sometimes my sense of time slips to the point that I'm not. Flex time isn't just a fringe benefit, it's often the difference between me being productive and me not being productive.
Don't sneak up behind me. Don't stand behind me. It's okay to look over my shoulder, but say something so I know you're there. If you have a question, and you need an answer right now, ask. I might not like being interrupted, but I'll like being surprised when I realize you're standing behind me a lot less.
I'm a combat veteran with PTSD who also happens to be a hacker. I'm passionate about writing software that people use and find valuable. What I am not is an expert on any of this. I'm learning as I go along, with the help of the people I work with, the people I hack with, the people around the net that write about things, the people that write the tools that I rely on, and the people at the VA Hospital.
When I first started this blog, there wasn't much real information available about being in college and PTSD (there's a little bit more now). There's less about being a veteran and software developer, and damn near nothing about being a combat veteran software developer with PTSD (again, there's a little bit more now).