ProjectX Blog

The 37 signals guys created a post where you could ask them anything.

I decided that I would asked them something that has been bugging me a little bit after reading “Getting Real” about how they manage multiple products.

You guys have a number of products and a small team. How do you prioritize the work on your products? (How does Getting Real apply to multiple projects ?)

Their response…

There’s no real science behind it. Different people are working on different things all the time. One person usually works on one product at a time. If it’s a bigger update or requires additional expertise then two or three people may pitch in. Sometimes a designer and programmer work together. Other times it may just be a designer and other times just a programmer.

Sometimes some products go untouched for a few months or more. There’s nothing wrong with that. It’s often good to let things just be the way they are for a good while. Then we’ll come back armed with a lot of good longer-term feedback and decide what to work on next.

Well, that all makes makes sense and fits in with their whole approach.

So if there is anything you want to know about Getting Real or 37 signals, now is the time to ask !

We’ve been a bit quiet on what we’ve been doing, so here’s a run down on what we’ve been working on over the last few months.

• US Maps: We been building and rendering maps for North America (USA and Canada) for one of our clients. We’ve designed and rendered a large part of the US using mapserver and Teleatlas data. After maxing out 8 machines and some serious RAID kit, we’ve clocked over 10K CPU hours on the project so far and got a way to go yet.
• NZ maps: We been working on updates and upgrades to the NZ maps.
• New API: We’ve just in the final testing for a new API to compliment our mapping and geocoding API’s.
• Demo websites: We’ve been working on a new map concept with a couple of Wellington companies.
• New tools: We have a bunch of tools exiting the R&D phase entering production development. More info on those later.
• Oh yeah, and we’ve been planning Summer of Code 2.0.

So what’s with all the secrecy???? We want to get a bit of a headstart before Wises and et start copying us again! 🙂

There is a really good post from ZDNet suggests that the 80:20 rule of software development needs to be changed for SOA (Services Oriented Architecture).

Here’s a snippet from the article.

At first the amount of needed customization is high — maybe 80 percent (a perversion of the old rule) — either because there are not many services available, or because the services are too general and not specific to a specialized vertical industry or niche function.

Then, over time, with investment, the balance shifts toward the 50-50 point, and reuse forms a majority of a composite applications or business process, even for highly specialized applications. These composited functions then become business-focused service frameworks, to then be reused and adjusted. Those architects that gain experience within business niches and verticals to create such frameworks can make significant reuse of the services.

Joel Sposky has a post talking about a few books. He singles out a quote from Ben Casnocha’s book called My Start-Up Life.

Great entrepreneurs show up, take small risks (and sometimes, large risks), raise their hand when they’re confused, and try to figure out what’s going on and how a situation could be made better.

When you show up and raise your hand, you’ve already outperformed 90 percent of the crowd.

That’s a really preceptive insight from the 19 year old. I’ve meet plenty of people who have lots of great ideas, but not enough balls to ante, do something about it and the determination to see it through.

If we’re going to change that way of thinking, then we’ve got to start early. That’s one of the core drivers of the Summer of Code ie. show that there are options outside of the cubical farms of the big consulting companies. On the Summer of Code you’ll get paid to experience the life in a start-up and hopefully think of your own ideas to cook up.

We’re looking for a couple of developers and I’ve been going through a number of resumes. Unfortunately, its a frustrating process as most of the resumes are poorly structured and written really badly.

I want to offer some advice on writing your resume, which is based on my experience both as a contractor looking for work and an employer of dozens of tech people. I’m borrowing heavily from the book “Pitch Yourself” and I’m providing some general advice that is applicable to writing a resume for any industry. This post expands on the talks that I gave at the Summer of Code and Victoria University. (Here’s the powerpoint for my last talk)

The problem with current resumes

Here is snippet of a resume from Bob (Edited from a real resume)

June 2002 Developer – X Consulting company, Wellington

I was worked for 12 months with the X team as a developer on the Alpha project – a secure trading system . The Alpha project had 10,000 active users and clients included Y finance company and Z bank. The project used extensively Enterprise Java Beans, Open Java Trading System and Oracle technologies.

Ok, so what’s wrong with this resume snippet. The problem is that it only gives me half of the information I need. From this snippet, I can tell where Bob worked, what role he did, how long we worked there and some of the technology involved. BUT I don’t know what he actually did! Did he work on the front end, or the back end or did he sweep the floor ? More importantly, the resume does not tell me what Bob was good at ?

What an employer really wants to know from your resume?

What is an employer really looking for your resume?

1) Who are you ? What are you passionate about? What makes you the person that you are? What are things that you are passionate about, what are you motivates you.

2) What are you really good at ? What are your core strengths or competencies? What are the 4-5 key skills that you have and can apply to your job. What sort of things ?? Here are some examples

• Strategical thinking
• Building relationships
• Problem solving
• Problem Analysis
• Effective Communications

3) Can you do it again? Your employer wants to know what are you going to do for them! They look at your experience as a guide to what you’ll do for them.

What are some personal attributes that an employer is looking for? Marc Anderssen (of Mozilla / Netscape fame ) suggests when hiring the best people you should look for three things.

• Drive – “self-motivation — people who will walk right through brick walls, on their own power, without having to be asked, to achieve whatever goal is in front of them.”
• Curiosity – “Anyone who loves what they do is inherently intensely curious about their field, their profession, their craft.”
• Ethics – “What do people stand for”

I would add a slight twist on Curiousity and add learning. I love learning new things and I am always looking for people who want to learn new things.

So how do I decide what to put in my resume?

Here’s an overview of the process that the Pitch Yourself book suggests to help you find your key skills. The book promotes the “Objectives Analysis Action Results” (OAAR) approach as a framework to figure this out.

1. Deconstruct your experience – You’ll need to look at your experience and deconstruct it to find your core skills. For of the major projects you’ve been involved in answer these questions.
   1. What were the objectives?
   2. What analysis did you make?
   3. What actions did you take?
   4. What were the results?
2. Think about what you did – Look at your de-constructed experience and think about the implications of what you did. If you go through this process you’ll start to find a number of common behaviours that will start to identify your key skills.
3. Build a list of competencies – You should be able to have a list of experiences that can be arranged like this.

	Your Story	Behaviours displayed	Key skills
Objectives
Analysis
Action
Results

4. Arrange your skills list – Create your all list of demonstrate skills with a story how you can deliver.

So what does this look like in action, here is a snippet of one persons core skills.

Effective Communications – In the aviation industry it is essential to convey and receive information succinctly. I use effective briefing techniques that are imperative for a successful flight from the ground up (and down again). I have an approachable style and carry out my tasks in accordance to the Standard Operating Procedures, whilst liaising with all my fellow crew in an open and co-operative manner, resulting in a reduction of inherent risk and shared knowledge.

One final thing to think about when writing your resume, Tom Peters (Management and change guru) says that you should aim to add something significant to your resume every three months. If you’re not doing that then you should think about a change.

Challenges in writing your first resume

There are a couple more challenges in writing your first resume. Basically you don’t have so much experience to call up to build your skills profile. In truth you can apply the same process to your university studies. You can use the OAAR technique on each one of your courses. A employer is looking for what you’re good at and what you are really interested in. ie. If you really like AI then think about what you like about it and why and use that in your resume.

So what now ?

Your resume needs to be tailored for every job. Why? You’ll have a variety of skills and experiences where not all will be appropriate for this role. So you need to tailor it to fit with the profile that their looking for. Also if you tailor your resume for every role you’ll have more luck with the automated bots (Do you think Google process all 3.5k resumes a day by hand ???) and recruitment agencies that do key word searching.

Make sure that your recruitment agent knows that, so that you can put your best resume forward for every job.

How long ?

Your resume should be one page. Why ? 30 seconds – That’s the time you’ve got to make an impression. You have to hook some to want to learn more about you, so you need to short, sharp and to the point.

The basic structure should be

• Name and contact details
• Personal statement
• Table of 4-5 core skills
• Summary of Experience and Education – (Only where you have work, what role and for how long)

That’s it!

But what about my technical skills ? What about my academic results? They can be on other pages.

Next time…

That’s enough to chew on, in my next post I’ll be outlining some thoughts on how to put your technical skills / experience down on paper.

Just found this blog post by Mark Fletcher that nails what it means for a person to start a company.

As an employee climbing the corporate ladder at a company, it’s all about getting more. More responsibility, more control, a larger salary, a bigger title. However, the exact opposite is true when you start a company. A big part of starting and building a company is about giving up. A founder is in a weird position. When you first start a company, everything is yours. You own all the stock, you make all the decisions. This point of creation is the only time this will be the case, however. Forever after, the founder must give up more and more control to other people and more and more ownership to employees, investors, etc. The founder must do this for the company to be successful, but at the same time this is the opposite of what many people are used to doing.

I don’t look at it as giving up, I look at it as working together. Its better to have 20% of $100M than 70% of $1M.

To be successful, you got to build a team of people dedicated to achieving a common goal. By working together anything is possible. Look at Rod Drury, in developing Aftermail, he built a team of skilled people that came together and executed brilliantly. After the sale to Qwest, Rod rolled a lot of his team onto his next project – Xero and their kicking ass now.

Food for thought!

Lulu just sent me a link to this great presentation on visual thinking.

Check it out!!!

If you like to learn cool new technologies, if you like to work at a place where you can feel comfortable and above all if you like to design and build application that people actually want to use then we’re interested to hear from you.

We are now hiring for the position of a Software Developer. See details in the jobs section on our web site.

I have been using Trac for many years now. Despite it’s severe shortcomings it’s still one of the best issue tracking systems because of its simplicity. The integrated wiki is pretty good and with some basic customisation and a system you can get quite a lot out of it. I get asked a lot about Trac and how it can make life easier. I’ve thought about it a little and I have this to say:

Software doesn’t make your life easier. You make your life easier by understanding what the software can do for you.

I think that there is this misconception that a piece of software should just do everything for you. With any ticket tracking software the software is only as useful as you make it. If you don’t have a good system and by that I mean a manual process which you could follow on paper then software won’t help you much there. You also need to make sure that your expectations are in line with what the software can actually do.

The other problem, which I have to wrestle with constantly, is that any ticket tracking system is only as good as the tickets which go into it. Programmers are lazy and undisciplined by nature, they never put tickets in and they never pick tickets out. When they do pick a ticket, it’s what they want to work on and not what needs to be done. That’s where you need a system in place. This all goes deep into project management territory. In turn, project management is futile if you have no decision making power and that comes from a well structured business hierarchy with clearly written HR guidelines (ie code of conduct, division of responsibility, reporting structure, etc).

At the end of the day, computers are just useless piles of junk without the right people to use them and people are confused unless you tell them exactly what you’d like them to do.

My advice: sort out your people issues and you won’t have to worry too much about your issue tracking software.