This way the files are available whenever I switch computers and they are automatically backed up.
I keep several text files in a directory: 1. A backlog. This is roughly similar to a scrum backlog. It's disorganized and needs to be, because it's important that I can easily put stuff in here when an idea comes to me without having to get distracted organizing things.
2. A plan. I periodically select a few things fro mthe backlog and organize them into a chunk of work that I plan on doing next. I put checkboxes like this [ ] next to each item, and when I finish the item, I change it to this [x]. The item that I am currently working on looks like this [.] to indicate it's in progress. That way when I get interrupted for 2 hours or a day and come back, I can easily see what I was doing and get back in the groove.
Periodically I move everything I have completed from the plan text file into a file like history/2012-12.txt. I put a date right before the items I put in. This way I can go back and see what I completed on a given time period.
Also into the plan file I will put notes of issues I'm researching, which can occasionally be useful to go back and look at a month or more later. Those notes get moved into the history file when that chunk of work gets completed.
The benefit of this approach is that I can use this method even when I am traveling on the train, and it let's me easily switch computers and keep working. I find my to do list to be just as important as my code, because it's very hard for me to be productive on a large project without continuous planning.
Keep a simple list of things to do as a backlog and maybe another list of "would like"s. I personally use SimpleNote and Notational Velocity for both.
I've found that the first 80% I can generally get done pretty quickly; most of the design and architecture is in my head and always running as a background task. I use Evernote to organize TODO's (always at the top of the list), and have little discussions with myself about stuff like features, UI's etc.
Life.Gets.In.The.Way.Restart. Arrrrgh. Inevitably. Back to Evernote and pick up where I left off. It gets much harder during that last 20% (which usually takes me more than that first 80%), because the jump from Proof of Concept to Product is brutal.
Do.The.Worst.First. A friend of mine, Sid the Sailor, used to talk about "painting the windowsills when the whole house needed cleaning"... especially combined with that last 20%, I have a tendency to go down rabbitholes (hey maybe I'll use RabbitMQ for this)... so, back to Evernote, and add the TODAY list - what's most important to get done. Then, suck it up, and do it. These often require very long late night sessions since it can often take hours for me to get started and get the momentum up to deal with the pile of poo. (Cause if it was fun it woulda been done).
Invite.Others.to.the.Party During the process, unless it's Top Secret(tm), invite others to take a look at what you're doing. Early on it's nice to get some approval, later on, it's nice to get some feedback about usability. Be careful to avoid party poopers since you don't need to be discouraged - this shit is hard enough already.
Launch.the.fucker. I have trouble with this one, because it's scary. It also generally means I'm going to end up with a pile of feedback (or bug reports) from a bunch of pissed off strangers. I really don't like it because it means work, and lots of it. It's the chasm between a brain fart and reality. And I get faced with the ultimate reality of "Hey maybe this sucks and I've just wasted a huge amount of time".
Now, in "practice what I preach mode", you might want to check out xlogs - http://xlo.gs - it provides logfiles for Amazon AWS and more. and i'm just launching it now :)
I have one big project, so I have a Trello board for that, with lists for: Today, Tomorrow, and then future work by discipline (it's a game, so things like: gameplay, rendering, art, design, etc.).
Every morning, the first thing I do is check my today list. If it's empty, I move some things from the tomorrow list in. Then I fill up the tomorrow list with things from the future work lists.
This means I have a list of all the work I need to do, but I don't explicitly plan more than a couple of days ahead - things are too variable for that.
Once tasks (in the today list) are done, they get moved to a 'done' list that I can review later.
It's simple, and seems to work fairly well for me.
[1] https://workflowy.com/?ref=45b58c2.tw (disclosure: referral link gets me 250 more list items a month)
That way, when you wake up, you can dive right into it and try to accomplish at least one thing a morning, if not two. This helps you get up rested and put your highest and best energy into your side project and it can be fruitful.
I have a separate dev user on my machine that has no email or any other distraction and I keep my browser clean and purged.
This means it's a pain in the a*se to login to sites I visit in normal life.
Tools I use: I try to stick with an IDE like Eclipse. I know they're sorta frowned upon, but I like convenience. I use Git, personal preference. Some spreadsheet program for managing tabular data, like milestones, word processor for keeping a journal, and a scratch pad or whiteboard for scratch-work.
Tips I've accumulated after a while:
* Milestones help you focus your efforts for the "session"
* Design documents and whatnot sound like a lot of paperwork, and it is, but they are incredibly useful to have and keep around.
* Try to not intermix phases of development. Don't do design and requirements gathering or design and analysis at the same time. Do things in order. It keeps things clean and separated.
I keep shuffling how I organize tasks. There's by-project, where I list all the things that need to be done to complete something. But I also have to keep some context lists like "next time I'm working on the website" or "next time I feel like doing a bunch of Photoshop work" for those tasks that keep getting put off.
I also keep a wall calendar (just a big sheet of white paper) with post-its for each deliverable. They keep slipping, but at least I can see how many weeks are left until external events.
When things get really unproductive, I walk away from the computer and sit down with a notebook or stack of index cards/post-its and dump everything that needs to be done. For tasks that are stuck, I try to apply Merlin's idea of visualizing what it will feel like to have it done: http://www.43folders.com/2005/10/16/43f-podcast-the-to-have-...
In a side project with so few hours per week, I think anything more complex than this is overkill.
So, I use:
1. RescueTime to track where my time has gone - after seeing exactly how much time gets sinked into FB/Twitter/App.net sor tof activities I, somehow unexpectedly for myself developed a particular type of anxiety - if I stay on those pages for roughly over a minute it freaks me out and I close it immediately. (I guess it's the realisation of wasting time is freaky).
2. PivotalTracket - to manage the priorities of tasks and to measure my "burn rate".
3. Evernote - I try to stick to the following procedure when reading/watching anything new: 1. Take short notes on stuff being watched/read. Express things using my own words, NOT copy pasting or typing same stuff I just read. 2. Create actionable items from what I read 3. Break those actionable items into PivotalTracket tasks
This helped to reduce the unnecessary news intake dramatically - in the very beginning of each article that I start reading I ask myself - "is it worth taking notes on?" if not - close the tab.
Thanks!
Do you take notes on almost everything? How extensive are they usually?
I've always felt like it's too time consuming to take notes (especially in my own words) but also recognize the likely increased retention advantage from doing this.
For instance I just finished reading a Brennan Dunn's book "Double your freelancing rate" and published the summary in here: http://blog.nimblegecko.com/notes-on-double-your-freelancing...
Or here are the notes on second week of Coursera "how to reason and argue" course - https://www.evernote.com/shard/s42/sh/cf6b1dd3-51aa-4bc0-b94...
Hopefully it gives you an idea on how extensive that is.
2. After I finished writing down the note, I copy its contents into a separate note in Evernote and delete everything that I cannot turn into an actionable item.
For each actionable item I add a tickbox (Cmd-Shift-T).
3. Then I estimate how long it's going to take to execute on that item and add a ticket into PivotalTracker. I normally try to group tickets by epics (product, marketing, consulting etc).
Hope it helps.
Lists are good - things to do both "must have" and "would like" - plus "yet to be tested" as things develop. Anything you cant just keep reliably in your head.
Carry a notebook around to jot ideas and sketches when you are doing other things.
Generally though, I find that having a site out there and people using it is the best motivator to keep pushing forward. It creates a real sense of urgency and priorities, and you simply won't have the luxury of not focusing on the important stuff that affects people's experience.
Every Friday morning, I step back and evaluate my progress: I write a paragraph about what I did during the week, a paragraph about the overall sentiment of the feedback that I got during the week, and a paragraph about where the project stands in comparison to its long-term goals. During this time, I also go over my task list and add, remove, or reprioritize tasks as needed to make the list reflect reality.
In the past I tried something similar to scrum (have a master list of everything I needed to do). But since I do have a day job and other responsibilities, I found that seeing a massive list got too overwhelming. Now I focus only on what I can get done now, not worrying about the pile of things waiting to be done.
To me scrum and similar practices provide value when you are at least two people, and it gets better when you are more.
More recently, at work, I've been using a Trello board, as I'm sure many others here do.
it's an open source project, so this not only helps me having a clear idea of what I'm meant to be doing, but it also helps others to contribute to it, by giving a precise idea of what can be worked on at any given time.
I take pleasure with taking things out of my todo list. I noticed that big tasks that will take about a week to accomplish should really have their own board with tons of small "cards" for each tiny task. I break the 1 big task into very small tasks that I should be able to accomplish in 15 minutes to 1 hour.
This drives me forward because the side project work becomes a game.
The reason behind this is that I might go for a few weeks without even looking at the code and then when I come back to it it's like picking up someone else's work...
I also have boatloads of unit tests so that I don't have to be as terrified about making big sweeping changes, and try to add tests along with every "feature" I put in.
1) Take one project at a time.
2) Make a vision document, basically what features I want in full fledged version of my application - Plain text document on my desktop.
3) Reduce the number of features to minimum required for MVP and make a to-do list for MVP - plain text document on my desktop
4) After 2 & 3 is done focus only on actual work(coding/designing) ticking off to-do items one by one.
A todo list app can also be useful, but only if using it is something you use out of habit. That's why Github issues fits nicely with me, because it fits with my natural workflow (filing issues or scouring issues of software I want to use).
The most important part to me is to make sure that I'm only doing things that actually matter. So when I'm thinking about adding a feature to my product, I first try to see if that feature should actually be the highest-priority thing, or if my customers can live without it. And it helps to zoom way out, too. Often, programming is not the wisest way for me to spend my time. Sometimes it makes a lot more sense to spend time on, say, marketing, or on education, whether that be programming-related education or something else. Abraham Lincoln said, "If I had eight hours to chop down a tree, I'd spend six hours sharpening my ax." A lot of the time, sharpening your ax is the most effective use of your limited time.
I've found the following books helpful when it comes to time management and overall effectiveness. In order of how strongly I recommend them:
- The 7 Habits of Highly Effective People by Stephen R. Covey
- First Things First by Stephen R. Covey
- Getting Things Done by David Allen
- The first 20 pages or so of The Ultimate Sales Machine by Chet Holmes
I use a combination of tactics recommended by GTD, FTF and T7HOHEP. After reading GTD, I wrote down everything I could think of that I would have to or want to do, ever. Examples: do the dishes, email Steve, visit Europe. Later, I captured most of these items in Evernote, and then later, I graduated to Things. I suspect that the developers of Things have read GTD.
Now that I have all of my to-dos captured in Things, I try to take one day each week (usually Monday) to plan the rest of the week. Reality never matches up with the plan, but I don't think that means I need to throw out the entire process. It's still helpful to have at least a high-level idea of what I want to do with the week.
I still find Evernote valuable for capturing ideas, but Things seems best so far for capturing to-dos. I also still use pen and paper to plan on a day-to-day basis. If I go by Things only, I forget, so I usually transfer my daily Things to-dos to paper at the beginning of the day. As unexpected things naturally pop up throughout the day, I add them to my daily to-do list and/or Things, depending on how likely I think it is I'll get to that item the same day.
Hope that stuff helps.
Personally, I find TDD is a helpful design aid for tricky bits of code. I don't bother when it's trivial, but when creating major systems or components, it helps to focus my design and enforce encapsulation.
gedit notes_<yyyymmdd>.txtI find that since I'm using the source control anyway, I may as well keep a track of everything there too.
You're (usually) not going to accomplish much, macroscopically, until you've done a fair amount of ground work (e.g. learning APIs). You need to keep that ground work fun, so whatever structure you impose on the process (to-do lists) needs to be focused on improving this factor.