Documenting Your Professional Life
How leaving a trail of document breadcrumbs can give you insight into your professional life
Hello, The Unexpected
Recently, a friend and I met for coffee. While we chatted about various topics, the inevitable subject landed upon my current job search. He and I had worked together in the past, and shared many of the same interests. Our careers, however, were taking us both in different directions. The realization that my career trajectory was shifting came on the heels of my time spent, in my basement, drinking endless cups of coffee, searching for jobs.
During this new, stressful, and mildly exciting job hunting phase, I began to gather assets and information about myself. For once in my life, I realized I had actually done something right: over the course of my career as a web developer, I had kept notes, records, documentation, and writings on most of the work I’d done. Very little of this was formal, but it was a cache of resources upon which I could quickly draw, enabling me to rapidly ramp up my website, resume, and brand.
As I poured over the morgue of resources I’d compiled over the past ten-or-so years, an observation emerged about my professional self: I realized I wanted to shift my career trajectory to focus on what really ticked my boxes. Let’s explore this a bit further.
I have no idea what lies in the future, but I do know I can inform that future.
I had been fairly happy doing my most recent job. It was comfortable, I had a tight-knit team, I knew the product intimately, and I felt like I had accomplished something when the day was over. What I hadn't realized is that I wasn’t really doing what I was best at. In many areas I was being limited or stifled.
Enter my life’s documentation: the pudding in which I found my proof. As you know, wisdom and insight is attained by life experience. It is the ability to look back, learn from history, course correct when needed, then take those lessons into the next challenge. What I didn’t initially realize when I would bang out even the most mundane document, is that it would be another exhibit in my mounting career evidence.
So there, in my basement, deep in my job search, I sifted through my work and writings. As I did, I noticed certain themes emerge. I tended to write a lot about a particular angle on a particular subject. The design work I saved tended to also relate to a particular "thing". Found within even the most mundane docs—notes on how I installed a particular framework, or the bloody tales of making an app—I was able to parse a bigger picture.
In a rare spell of self-awareness, I realized that the jobs I thought I should be going for were in fact not the jobs I should pursue. This allowed a course-correction. I compiled an updated view of the direction I wanted to go, what I wanted out of my career, and even the types of companies I wanted to work with. This new understanding of how I’d grown gave me an ability to enter conversations with prospective employers with a drive and awareness that showed a confidence not only about my career, but also about myself.
Please don’t get the wrong impression. In the beginning, I didn’t realize all the saving, writing, and documenting I was doing would lead to a professional epiphany. Nor did every document I authored contribute to this experience. Some stuff was just simple record keeping. But taken as a whole, it has all proven beneficial, regardless of how mundane.
I also realized that the more I do it, the more it begins to feel like a natural, integral part of my process. Now, I do not feel like I’m doing a task to it’s fullest if there is no form of documentation.
Furthermore, documenting helps me ask better questions. As a UX Designer, questions are integral to providing the required, accurate experience. I’ve found that the more I document any given project, the more I learn what questions to ask. The answers, then, often lead to greater, more impactful outcomes.
Of all things listed here, I do this the least. It’s like flossing. You know you need to do it. You know it keeps you healthy...but you’re just shit at it. When I do write, or journal (I hate that word), I find it extremely cathartic. The challenge is quieting your mind and the world around you enough to get going. I’m not here to tell you how to do this, there’s an internet full of articles telling you what you should do. I boil it down to just articulating whatever it is I’m feeling at that particular moment, beit personal or professional. I often find myself, after a little time, writing away with abandon. It feels good, but I rarely do it. Hence, the human condition.
I’m an adjunct instructor by night, and I love coaching and teaching, so perhaps the desire comes a bit more quickly to me, but that doesn’t mean teaching necessarily comes naturally. If I find I’m learning something new, such as setting up a [retro gaming system](http://christanfergus.com/RetroPie-Gaming), or learning how to build a plywood desk, I immediately open up a Google Doc and start documenting my process. This accomplishes two important things:
- I learn much better. Writing about my experience solidifies those neural pathways
- You have a trail of proof of all the crazy things you just did, because trust me, you'll forget
I make sure to write down every detail, whether big and small, what resource I got what info from, etc. I record lessons learned, specific code commands, and most importantly what did not work. I then repeat the process as I continue down the rabbit hole. The document often looks like the scrawlings of a serial killer (admittedly I’ve never actually seen a serial killer’s scrawlings, but go with me on this one) but there’s priceless info in there.
If I’m feeling particularly with it, I’ll then go back and write a new doc outlining only the successful steps, as if I were to give this to someone to replicate. I cannot tell you how many times this has saved me valuable time when, in the future, I inevitably have to do the same process in another environment, or return to a project months after I’ve touched it and have forgotten everything!
This is hard too. I don’t have pretty, organized, cutesy Dribbbles I can share. I generally have scruffy amalgamations of various levels of production, all of which evolve until the final, beautiful reality is realized in the BROWSER. Whether this is good or bad is best left for another post, but suffice to say, a compilation of coherent designs that tell a story can be hard.
I tend to simply keep track of any renderings by keeping as organized as possible, that way I can revisit in the future and worry about organization then.
It’s worth noting that this can be even more of a challenge if you work for a company that is not too hot on you using designs produced for them. Typically, if you work for a company, they own your work, not you. Simply ask permission to use the work. Often permission will be granted. Often you’ll be asked to show how you’re going to use the work and get approval. Usually, that’s all it takes.
There’s another option, however, that can greatly benefit you and employers: case studies.
A good case study tells a story. Present the problem, present the approach, tell how you solved the problem, show how your approach made a difference. In my experience, case studies have proven the most beneficial to both my own growth, and has enabled colleagues and prospective employers to understand my process. Of all I’m writing about here, I assert that case studies have had the highest return on my time investment over everything else.
Case studies allow you to undergo a serious project retrospective. In many cases, you learn what you did well and what you didn’t. You often gain unexpected insights. You then carry that experience into the next project. Without a thorough retro, you may forget or simply overlook valuable learnings.
Bosses and future employers also love case studies. A well-written, to-the-point case study has sparked many lively discussions. Some companies even allow you to share case studies, raising awareness of their product or brand.
They don’t need to be long, arduous pieces of literature. This is what put me off originally. They can be short and to the point as long as the content is rich and meaningful. Over time, however, I found a format that worked for me, and that format was fairly short and to the point. Here’s a loose framework:
- Describe the problem/requirement
- Present the solution
- Research performed
- Cite the solution
- What the final solution looks like
- What monetary/user/etc. benefits were achieved
- Conclusion and looking forward in the future
Keep them on target, full of info, and to the point.
Version control is your friend. Git is your friend. Github is a great industry-standard-free-repository-friend. Regardless of the version control system you use, if you’re a developer, version control is a vital. Listen, it documents for you! Get that? It provides you a complete history of every code change you make, and all you have to do is write the code!
Beyond this, a well-formed README file can be another valuable resource. When you return months or years later, and you need to remember just what in the hell you were doing, a solid README is priceless.
If you ignore everything else in this article, do yourself a favor and document your project in your README. Describe your project’s dependencies, installation requirements, installation procedures, and any other information. True, your package files or code structure could lend you some clues, but why waste your time with all that? Your README is as much for you as it is for other developers. Even if you do not plan on others using your code, write as if you were creating a product for someone else to use, and that someone was a brand new noob to all this coding stuff.
You’ll thank me later.
I don’t sit down and specifically write blog posts. What you see on my site are the results of all the other ways I write and document. If I turn it into a post it’s because I want to share my experiences. I’ve lost count of how many times I’ve been searching the interwebs for an answer to an obscure question, only to come across a developer’s obscure website with the exact answer I needed. Wouldn’t you like to be that person for someone else? I know I would.
Share your knowledge and experiences. They may be personal to you, but nearly always they can help someone else.
With all this documentation talk, it should be clear that if you do this, you’re leaving yourself a creative, professional trail of historical breadcrumbs. There is no real formula that should dictate how you document. Figure out a way that suits your process best. This is well-illustrated in these articles outlining famous writer’s schedules.
If you look at the above links, you can see that no one had the same process, but all were effective in their own way. And that’s where I’m at. My experience looking for work and ultimately finding a new, great job, has not made me complaisent. Instead, it has spurred me on to continue my documentation. I have no idea what lies in the future, but I do know I can inform that future. Do as little or as much as makes sense for you; just do something. Your future self will thank you.