For the past month or so, I've been working on a Coursera specialization in Project Management. The specialization is comprised of 4 courses, the last of which is a capstone project. The capstone project is designed to force students to use and apply what we've learned in the previous 3 courses in a practical setting. Needless to say, it's difficult emulating a practical setting in an online course, so I've gotten the go-ahead from my manager to use an upcoming roadmap item as the basis for my capstone. I can't even begin to explain how exciting that is. I'm only a couple weeks into the capstone project, but I've already learned a number of things about myself, the project, the process, and management.
Project management requires a whole different kind of thinking
I'm a software developer by trade, training, and practice. I know that when I'm developing a new feature, there's a lot of thinking that goes into implementation and how to lay out my code. As a developer, I also have to be aware of technical constraints and do a lot of learning to keep up with best practices. At a high level, there is some overlap between these thoughts and those a project manager would have, but the differences are, as I am currently finding, even greater.
Where development is focused on the implementation details, project management is concerned with the bigger picture. Why are we taking on this endeavour? What are the risks and considerations upfront that we're aware of? What resources are available to us to "get 'er done" in time? What are the successes we want to achieve by completing this project? And how much will that all be affected if a necessary change arises? Some of these questions are posed to developers as well, but the fascinating thing is that the type of answers will be drastically different.
As I'm working on my capstone project, coming up with answers to questions like these, I'm finding myself thinking about the other departments and their involvement in these projects. No longer are these questions just about implementation, but about the entire endeavour of releasing a new feature -- and that's exciting as heck!
Project management is different from product management
... which isn't to say that the two do not share some commonality. There are numerous articles out there that provide answers to the query "difference between project management and product management", and oftentimes business analysts get included in these articles as well. There is good reason to wonder about the overlap between these roles as they focus on similar skills, both interpersonal and management. However, there are some disparities between these roles that should not be ignored or glossed over. I saw an analogy by Derek Morrison that highlights the difference between the two:
“A Project Manager is like a mid-wife -- he/she delivers the baby, hands it over to the mother and moves on. The baby being the product and the mother being the Product Manager.”
Again, there is definitely overlap, but there is a clear separation in the roles that focuses on two concepts: time and context. Projects are inherently temporary; they have a start and end. In managing a project, the context you are dealing with is the project itself -- its objectives, perceived risks, and changing complexities. The product lives on with, ideally, no end in sight. Products are born from the results of projects, and so management of them extends beyond what happens on a project level. Conversely, product managers find the business needs and plant the seeds for projects based on those needs.
Project management entails a lot of documentation
Documentation is important, and this importance spans across multiple disciplines beyond project management. In our case, documentation is the main output of a project manager, aside from the project deliverables themselves. There are a number of documents required for my capstone project: project charter, work breakdown structure, activity sequence diagram, risk management plan, milestone schedules, and many more. Coming from a development background, it's mind-boggling to think that so much documentation is necessary, but I'm finding that as I flesh out the details of my chosen project, these documents are all crucial to the development of the project. In creating these documents, I'm being forced to think and analyze several dimensions of the planning process. These documents also serve as a consistent medium through which ideas can be disseminated.
"But," you exclaim, "there's documentation in development as well! How is this any different?" In essence, it isn't different -- in both instances, information is disseminated in the form of documents, and the nature of these documents is technical. The difference lies in the content and the sheer importance of the documentation. For developers, the world changes so quickly sometimes that documentation goes out of date quickly. This isn't to say that project management documents don't go out of date, but rather that since these documents are the main, tangible output, it's easier to maintain them. In fact, it becomes a core part of your role to update them to facilitate communication. Documentation updates for developers are always going to be second to the code, there's no doubt about it.
I enjoy writing documentation, a lot
I love reading, and though this doesn't always translate into a love for writing, I love writing, too. I've always had a passion for writing fiction, but technical writing is enjoyable in a different way. It feels good to get thoughts, ideas, and details out. In terms of my capstone project, working on each of its deliverables has made me realize just how important documentation is to me. Maybe this stems from my love for reading and writing, but I think there's more to it than that. There's a certain art to technical writing, and though the "technical" descriptor doesn't conjure any particularly romantic or dreamy visions, there's still something to this idea of taking dry, jargony technical terms and making them palatable.
That being said, what is most paramount is my desire to move forward, to get going with this project. So far the deliverables have been incredibly thought-provoking, and my existing view of product features is being flipped on its head. There is more to a project than just the feature it produces, and there are so many moving parts to a project that need to be managed.
Communication is a project's life force
It's a well-known fact that communication is the key to unlocking so much in this world. We all live in our own heads so much of the time, and the only way to break out of there is to communicate. As much as documentation is a part of a project manager's role, communication is even more so. This is something that was mentioned throughout my specialization, but never did it become so clear as when I was drawing up the project charter and exploring what the project objectives were. I touched on this briefly earlier, but communication between people is what keeps the project moving. There's an inherent feedback loop built into the process that isn't called out specifically, but is what facilitates it all. No matter how big or small a project is, there needs to be communication.
I've still got almost an entire month to finish up my deliverables, so stay tuned for future PM musings as I puzzle my way through this capstone. It's been an enjoyable journey so far.
Let me know in the comments or on Twitter if you have any other pearls of project management wisdom.
At work, we love Slack. I won't say that Slack is flawless or the most perfect software out there or even that we all universally love Slack, but it's certainly served us quite well at work. At my previous workplace, we used Skype for our "watercooler"-esque conversations, and I must say that I much prefer Slack to Skype for this use case. Never having used HipChat, I can't speak to it, but this is a blog entry about Slack and Slack-based productivity tips so let's not dwell on other software.
Getting back to the topic at hand, how have I found ways to slack less with Slack?
This seems like the most obvious one, but it's one that I tend to forget about from time to time. If you get down to it, Slack is a glorified IRC client with a hip UI and some extra features. What Slack has done is fostered a community of developers to write integrations for their own product, and that in itself is kind of amazing, as well as the fact that its a growing community. They recently revamped their integration library, but the revamp didn't take anything away from it; it's a sizable compendium of integrations for other software and products to feed into the giant feed that is Slack. For those of you who use Emacs and like to live inside Emacs, I find the productivity gains to be akin to that (more on the Emacs thing at a later date).
One of the best integrations we've paired with Slack are the IFTTT bot, which can post things based on triggers from a variety of other software, the Email integration, and the Google Calendar integration. All 3 of these have become incredibly useful for pushing information to us at crucial times. But how is this different from pumping notifications into your e-mail? In Slack, you can pipe these integration feeds into specific channels, which limit who is notified as well as offer a common space to discuss items that come in. In short: integrations + Slack = 
Slackbot is initially your Slack guide and helps you set up your account, but if you give it the chance, it is so much more than that. Your "Direct Message" conversation with Slackbot is a scratchpad for testing out formatting, a place to check that /giphy taco won't give you something completely inappropriate, and a spot for leaving reminders for yourself. Outside of your private conversations with Slackbot, you can also use the /remind me command in any channel to set time-sensitive reminders for yourself (the reminders themselves will only be visible to you). Bonus Slackbot productivity tip: Slackbot can be programmed to respond to certain trigger words. With some creative thinking, you can make this useful for channel-wide reminders or just general brevity. And for you programmers out there, Slackbot can be configured to be even more interactive if you set up the integration.
Using integrations can result in being a member of a great number of channels. One neat feature Slack has included is the ability to star a channel -- this also applies to private channels and direct messages. By starring a channel, you are adding it to your list of favourite channels. The terminology can be off-putting, but once you have starred some channels, the real decluttering magic comes in by turning on a simple setting. Under "Preferences", you can navigate to "Advanced Options" and pare down what is in your Channel list to only the channels you have starred. But wait! I still wanted to look at those other channels sometimes despite the inferior, not-star-worthy content in them! This leads me to my next tip...
Keyboard shortcuts are fantastic, and you should use them. Herein lies the answer to the question we had above. The shortcut that I use the most is the one for the Quick Switcher, which allows you to quickly move to a different channel. Suddenly, it's okay that I've hidden all these other channels because I can still access them in a matter of seconds. Besides, if there's activity in them, they'll show in the sidebar anyway, but they'll be hidden whenever there isn't any activity in them.
I'm not sure what that monstrosity of a word is that I just typed, but it's what Slack calls their emoji reactions feature. On the surface this is just another fun feature that provides some chuckles every once in a while, and upon some reflection, is not a bad way to provide or solicit some basic feedback. Again, with some creative thinking these emoji reactions can be used for one feature that has been highly requested of Slack: voting. There is no polling or voting mechanism in Slack. However, you can use emoji reactions to act as a simplified voting system; our developers have used it in the past to decide on an image asset to use.
Even in its most vanilla form, Slack is a great communication tool for teams. With a little bit of effort, it can be so much more: e-mail feed, status/notification system, personal reminder, feedback solicitor, the list goes on. Leave a comment or hit me up on Twitter if you have some Slack productivity tips of your own!
Re-Logic (fairly) recently launched Mac & Linux versions of Terraria with version 1.3.0.8. This was big news that finally made it possible to run and host a Terraria server on a Unix machine! Hurrah! Lucky me, my boyfriend helped me set up a server on a Ubuntu box I have hosted on Digital Ocean. It turned out to be incredibly simple, but I'll outline the process anyway.
First off, you want to create a droplet that has enough CPU and memory. This took us a few tries as we wanted to save as much money as possible. Of course, you can go for a more powerful server, but the most basic one we were able to use was the 2GB RAM, 40GB SSD server. At the time that I had created the server, its price point was $10/mo, but looking at the options now, the price point seems to be $20/mo. Another important point to note is that the Terraria software for Linux is only supported on Ubuntu.
At this point, I'm assuming you know how to ssh into your box & are comfortable with some basic bash commands. My next step was to install a handy tool for running processes "in the background". There are a number of ways to run processes in the background, but my preference is for screen. It creates "sessions" which are like separate bash consoles. This keeps things tidier. To install screen, you run:
That's really all the setup I suggest prior to installing the Terraria server software itself. The rest is simple.
Let's go to the home directory and download the server software. At the time of this entry, the most up to date version of the software can be downloaded from here.
cd
wget http://terraria.org/server/terraria-server-linux-1308.tar.gz
Then we decompress the software using tar.
tar -xzvf terraria-server-linux-1308.tar.gz
I recommend starting a screen session at this point and running the server software in a session. Why? Because you will be able to let the server run in the background while you do other things on the server (like backup World files) and logoff your Ubuntu box with the server software still running. In our case, we are going to create a screen session named "terraria". This will make it easy to resume the session later. The last steps to get the server up and running are to run the server script!
screen -S terraria
cd terraria-server-linux-1308/
./TerrariaServer
This should bring up the prompts to configure the world you want to host. Once you are done that, you can detach your current screen session by pressing Ctrl + A, and then D. If you want to resume the session, you can do:
And there you have it! You now have a Terraria server hosted on Digital Ocean! If you've got any tips or tricks to make the process smoother (or better), leave a comment or hit me up on Twitter.
I took the time a couple weeks ago to revisit my .vimrc and rethink how I use Vim as my main text editor. This also involved switching from using the default Terminal.app to the more customizable iTerm. Although I use MacVim for most of my work, I do like to edit code on the fly from the terminal, and I quite honestly was fed up with how Terminal.app wasn't displaying my Vim colour scheme correctly. It's petty; I'm petty.
Colour schemes aside, I decided to really sit down and evaluate what my hurdles with using Vim for development were. Overall, I found that I missed the autocomplete suggestions that are typical of IDEs, and I found that when I was editing large files, it was hard to navigate and remember method names. After doing some research, I settled on installing and trying out the following Vim plugins.
Based off of Powerline, Airline adds a nifty status bar to the bottom of Vim. The best parts of it include telling you which mode you're in (e.g. normal, insert, visual, etc.), what Git branch you're on, and the file type. It's quite handy, and is part of the reason why I switched from Terminal.app to iTerm.
As much as I love using NERDTree to browse directories, it can be troublesome trying to find a file when you are unsure of its path. CtrlP allows you to search for a file, assuming you know what it's named.
Finally! A syntax checker! I should've installed this long, long ago. It uses pre-existing syntax checkers (like Rubocop, rubylint, etc.) and supports multiple languages. I am highly enjoying using it so far. I can already feel myself coding smarter.
This plugin solves my issue of being lost in long files. Granted, files shouldn't be ridiculously long in the first place, but this is not a perfect world, so we make do with handy plugins like TagBar. TagBar lists all the methods in a sidebar, which you can then use to jump to the start of a method.
As well as having an awesome name, YouCompleteMe is the autocomplete that I have been a-hankering for. I am loving it and its simplicity. It makes writing code that much faster.
I was already a fan of NERDTree, NERDCommenter, and a few other plugins, so I've left them out, but I try to keep a repository up to date with the contents of my .vim and .vimrc here, lest I lose my current setup, but should anyone be curious, this is my setup: MoreVimLessVigour
It's only been in the last couple of years that I've acquired an affinity for tea. This in part is due to my attempts to lose weight and change my diet to improve my health. Now that I've amassed a small collection of teas, I drink tea at least once a day. It isn't a necessity (though the caffeine in some teas is great for work mornings), but tea tastes wonderfully fresh and clean. Sorry, coffee. 
The tea that I'm reviewing today is the Jasmine Blossom Green Tea by Stash Tea, a company based in Oregon. I first had this tea at Cheesecake, Etc. -- my go-to dessert hangout -- as part of the most fantabulous tea latte I've ever had: the Shanghai Fog. Similar to a London Fog, it's a combination of jasmine tea, frothed milk, and vanilla. The drink was absolutely divine, and I was thankful that the teabag was left in the drink so I was able to hunt this tea down and add it to my own collection.
Stash is a relaively easy to find brand in grocery stores. I have seen their teas in Safeway's flyers, and on shelves in London Drugs and Nester's Market. Of these three stores, the prices seem to be lowest at London Drugs. The box design is basic, but it gets the message across. There are twenty teabags in a box, and each is individually wrapped with brewing instructions.
One of the first things I noticed about the tea was how fragrant it was. It's a jasmine tea to the core, and it's apparent in the rich floral aroma. There is nothing spicy about this tea, so it is basic, but that is why it excels at being a pure, cleansing tea. The tea's colour is a slightly orange yellow -- nothing particularly earth-shattering to note. Now, the flavour is what makes this tea unforgettable. After initially having it in that Shanghai Fog latte, I had cravings for this tea, and it's clear why. The jasmine flower takes centre stage immediately on first sip. It's fragrant and floral without being overly floral, and somehow it still remains slightly sweet. I have had this tea with milk, honey, vanilla, and also without, and I must say that it is most enjoyable in its pure, unadulterated state. There is already such a fullness of flavour that it is completely unnecessary to add any supplements.
I had better stop this review before I completely go overboard, but I've gotta say that this is my favourite tea, and I am not saying that lightly.
My recommendation? Drink this tea if you'd like something floral, sweet, caffeinated, and full-bodied.