Life and Code

The Three Day Project Paradigm

I am currently a firm believer and a practicer in the Three Day Project Paradigm. This is, simply put, that one can learn a lot by building 100% of a project within the timespan of three days. It is worth noting that, given my current state of unemployment, this means 3 full days rather than three evenings. What sort of lessons can we get from such a project?

First, open-ended projects can have the tendency to drag on. Putting a limit on the length of the project automatically stops this. The time limit forces one to properly spec out the idea before simply diving in and coding. It has also forced me to budget my time in very specific ways. For example, my timeline might go something like this:

Day 1:

- Pick an idea.

- Create a precise feature list.

- Design the software. Whiteboards are excellent for this.

- Create a skeleton of the modules, classes, and functions required for the given features. Do not flake out on this step! The more parts you skeleton in, the more you will understand the potential issues of your own project.

 Day 2:

- Flesh out the major routines with pseudocode.

- Make the app work (or at least start), and start building in

- Discover potential issues, re-design anything necessary, and continue hammering away.

- Have a major code re-factor before the end of the day. It is ultra important to not leave your code in a state of disarray. If anything gets out of hand in terms of being difficult to read or understand, crack down on it as soon as possible.

  functionality.

Day 3:

- Code the final features.

- Fix any bugs after performing as much testing as is reasonable.

- Tidy the code.

- FINALLY, write up a short report about the shortcomings of the project, your future goals for the project (were you to continue), any bugs you were not able to fix, and what you learned/what you would do differently. This really helps to tie off the project and make sure you’ve learned something.

 Day 1 is all about figuring out what you’re going to be doing. If things go well, you can jump into Day 2’s tasks, but everything in Day 1 helps to make sure the rest of the project is finished expediently. Having a whiteboard with my plan on it helps to keep me focused on the original idea.

The initial feature list can include room for improvement if the project is finished early. Those extra features should be categorized as such, however, or else one risks skipping other important tasks.

As a fan of the PPP (Pseudocode Programming Process), on Day 2 I like to really flesh out some of the routines before I get to coding them in.  In my most recent project, a Blackjack implementation in Python, this involved writing out the game loop in detailed comments before actually coding any of it. If the primary game loop (ie. receive input from player, output result, repeat) is not set up well, this can only lead to problems. This can apply to just about any program, as it is likely that you will have some sort of module that will activate the rest of your code and communicate with the major classes.

The final day is really all about making sure all of your features are in place, and that the cody is tidy and readable. Make sure that the idea is to make your project open-source so that other people can contribute. With this in mind, you will start to notice how horribly unreadable your code can be.

I find the report aspect of the project to be very rewarding. My Blackjack implementation was actually completed in order to secure a phone interview, and the task happened to fit perfectly with the Three Day Project Paradigm. I made sure I put together a report so that they understood that I was well aware of my own project’s shortcomings. Indeed, it is far from perfect, and there are a number of things that I would change and refactor.

For an example of such a (less than perfect) project, please visit my github at github.com/danielmoniz/blackjack. Browse the README and the REPORT files if you want an idea as to how the program functions. It allows for people to create AIs to count cards using any method they desire. This means that people can simulate card counting and statistically determine best methods.

Do note that the Three Day Project Paradigm is a work in progress, and I will accept constructive criticism from anyone with experience. I hope somebody will get something out of trying it out.

Sincerely,

Daniel Moniz

The Plan

The first phase of The Plan, as highlighted in the previous post, was to quit my dead-end job without having one lined up. Rather than search for another job immediately, however, Phase Two involves developing both personal and professional skills.

Although my current jobless situation is clearly not ideal, I can safely say the following: in an ideal world, I would like to spend approximately two months in between every job that I have. This would, in a better situation, involve having a job lined up for two months after I leave my current employment. That time would allow me to vacation if I please, relax (depending on the demand of the previous job), and build skills.

Being in the technology industry, and being willing to adapt to new technologies in this internet age, building skills is a very manageable thing. There are vast resouces to be found online for a person motivated enough to use them. Programming languages have comprehensive tutorials and reference guides for anyone to access, and open-source tools often provide more support through the community than could any commercial product.

I therefore set out to do the following:

1. Learn a new programming language (Python).

2. Study algorithms.

3. Get an awesome job.

 The latter is pretty vague, but I mean a job at an innovative company like Google or Twitter. Let’s rate jobs on an interval between 1 and 10. If I lined up a job while still working at my previous position to start immediately, I would have had very little time to find the right job, as well as minimal time for the development of skills. Instead, given that I quit without find a job, I have been able to quickly develop the kinds of skills I might need to reach that high-hanging fruit.

I’m studying algorithms to help me reach this goal. A computer scientist needs a lot more in his or her toolcase than a list of programming languages they know. Google will be probing for problem solving ability and the way a person thinks about problems, and the same goes for Twitter. Brains and accumulated knowledge will have to meet in symphony.

Lastly, I’m learning Python because I need more languages under my belt. While I have used PHP for great projects in the past, it would be great to know a language with the power and elegance of Python. Not only is it a lovely language for those of us who are mathematically inclined, but it is becoming a popular language for web development as well.

All of the above will allow me to make the transition from “Web Developer” to “Software Developer”. This seemingly pointless change of job title is more of a change in attitude that I am attempting to develop. I do not want to be a PHP developer or someone who makes websites for people. I do not mind, on the other hand, being a software developer that is well versed in the ways of the web.

Over the past three weeks and into the next month, I have been (and will be) working to make these things happen. This blog will be a sort of journal designed to disect my experiences, both the positive and the negative, and share whatever conclusions this wandering developer may find. 

Sincerely,

Daniel Moniz

The Experiment

So begins the largest self-experiment I have ever performed. It has been two of the most productive weeks of my life. Who knew quitting a job could be such a constructive thing?

Let’s back up a couple of months. I’m working a job that I’ve wanted to quit for some time, but have been hesitant to do so. It’s early enough in my career that I’m worried about damaging it by leaving a job too early. There are, of course, financial concerns with living downtown Toronto without a job.  Considering that I live a frugal lifestyle, money has never been the issue with me as it is with others.

More and more I had been irritated with the fact that my learning at home dwarfed my learning in the workplace. It’s absurd to me to think that a motivated and knowledge-driven person should have to feel like they live their entire lives in the evening. More and more, I found myself too drained in the evening to accomplish anything. If I’m truly motivated, why should I have to put up with that? I ask for a few things out of a job:

1. A learning environment.
2. Good people.
3. Creative direction.

The first two are obvious. When I say ‘creative direction’, I mean that I need to know that I can make change if I have the right ideas. I need to know that the company is legitimately open and interested in new ideas. This one is the hardest attributes to measure before one accepts a job. Nevertheless, if I am unable to make any creative change at my place of work, it is only a matter of time - namely, once I’m confident in my relevant abilities - until I feel under-valued at my workplace. It’s not a job trait that is immediately relevant, but it is one that will make me leave a job within a year of applying.

Suffice to say, #2 alone is not enough to keep me in my position. After staying on at the job for about two extra weeks in order to finish an upgrade I had been working on, we celebrated my last day at work with what was probably the most frustrating and mind-numbing day yet. Nevertheless, I was sad to leave some of these people behind.

It took me all of 48 hours to get started on phase two of The Plan.

…To be continued…

Sincerely,

Daniel Moniz