End of the year lessons
Robby Russell
I'm working on a blog post about things that I learned this year and
thought, "I wonder what other people have learned." So, I thought that
I'd come here and ask the Rails-Business community.
Within the context of Rails *and* Business... what are some lessons
that you've learned over the course of 2007?
If I can get enough responses, I'd like to compile a selection for a
"This Year in Rails Business" blog post to bring more attention to
this great community of people. :-)
Thanks,
Robby
--
Robby Russell
Founder and Executive Director
PLANET ARGON, LLC
Design, Development, and Hosting with Ruby on Rails
http://www.planetargon.com/
http://www.robbyonrails.com/
+1 503 445 2457
+1 877 55 ARGON [toll free]
+1 815 642 4068 [fax]
Greg Newman
John Athayde
strongly with me at this point after quitting my job and going full
time as Hyphenated People with Amy Hoy:
* Supply and demand works. When the demand is too high and the supply
low, raise the price and it balances out. This means your supply of
time and your clients demands. We work less and make more than we did
a year ago.
* Follow your gut. When you're in a pitch and it just doesn't feel
right, it probably means it's not. Get out quickly. Especially when
they drop buzz words and drop they incorrectly.
* Build an army. We have a large network of people we call in on
various jobs. We help our friends, and in turn, they refer us for a
lot of stuff.
* Relax. Take time to do something non work related, e.g. watching a
movie, making music, surfing, camping, anything. If it's outside, even
better. No, reading programming books does not count.
* Keep learning. The more you know about various elements of the
process (e.g. developers learning about design and vice versa) the
better it makes you at your own job.
Courtenay
Philip Hallstrom
> Particularly don't work for clients who pay "net-90" which really means "6
> months, if ever".
>
> Even if the contact at the client is a friend.
This isn't always true though... I do some work for a local city group and
it's 30 days... but it's very consistent and I've never had an issue.
That said, they've been a client for over 7 years so there's a long
relationship there.
Outside that I'd have to agree with you.
Michael Christenson II
I'd agree with you. I've only had one client that ended up taking up
to 60 days sometimes. needles to say I only work with clients who pay
promptly on a schedule or promptly after being invoiced now.
Michael Christenson II
m3tal...@gmail.com
--
Crazy Quote of The Year:
“Freedom is not a concept in which people can do anything they want,
be anything they can be. Freedom is about authority. Freedom is about
the willingness of every single human being to cede to lawful
authority a great deal of discretion about what you do.” - Rudy Giuliani
John Moody
1. Obsess about cashflow.
As a former boss once put it, only cash can be directly exchanged for
food. You run out of it, your business dies. You run low on it, and
all of your energies are directed toward getting more of it, fast.
Soon, that killer app you're building on the side lies dormant while
you're just trying to make ends meet.
2. You don't need it.
Yeah, that shiny 17" MacBook Pro would increase your productivity, but
you don't need it (yet). Your old PowerBook will do for now. Save the
cash. (See #1.) At the very least, wait a month and see if you still
need it as badly as you thought you did.
3. Plan to keep up.
The world of Rails moves fast - faster than most other development
frameworks out there. If you're going to stay up, you have to schedule
time on a regular basis to learn rSpec, master REST, and get Git. (And
by "regular basis", I mean weekly.)
4. Fire your worst customer.
We all that one client who never pays on time, is always bugging you
with little changes, and trying to nickel-and-dime you for every charge.
Show them the door. Today.
5. A house divided against itself cannot stand (very well)
If you spend half your time using Rails and half using other frameworks
(ASP.Net, Java, PHP), you'll find it very hard to keep switching back
and forth (at least I have).
6. A good designer is worth the money.
No comment necessary.
- John
John Moody
President
MentalVelocity Inc.
360-941-5218
jo...@mentalvelocity.com
http://www.mentalvelocity.com
Jose Hurtado
I would add some for those who haven't jumped to Rails yet but who are "enjoying" the learning curve, like myself.
So here is advice to actually be able to do Rails later:
- Learn Ruby first. Yes you can sort of learn Ruby and Rails at the same time, but there will be holes in your eduction, some times pretty big holes. I recommend Ruby for Rails and Scripting with Ruby
- Don't burn your ships yet . Yes I said it, stick with what works now, especially if you have a tough project ahead and you are still not proficient in RoR. Use PHP / Java / Net whatever you are really good at first. Use RoR for simpler, or not risky projects at first.
- Build something to practice. Either open source, in house tool, whatever, write something to practice your skills, don't wait to get the "best paid gig" do something now.
Myself I am following my own advice, and having a full time job doing PHP 5 development it's taking longer than expected to learn Ruby and Rails. But is worth it, it is a great tool, I wish it was faster and more efficient in hosting environments though, I can only run it at a VPS or a dedicated box.
Cheers,
Jose Luis Hurtado
Software Developer
TrumpetInteractive.com
Toronto, Canadad
--
Best Regards,
Jose Hurtado
Toronto, Canada
Michael Christenson II
-- Don't worry about chasing that last invoice down through
collections: you can make more with the time spent. Just blacklist
that customer and spread the word.
-- Always leave a contract making sure you haven't ticked off a good
future contact. I know, sometimes you really want to tell that client
where to go ... do us all a favor and don't.
-- Keep your army up to date with your needs, and make sure to keep up
with theirs.
-- Schedule time out to work on personal projects and work on them as
if they were paying projects. Do this steadily to keep your skills up
and someday you'll produce that magical elusive passive income.
Cheers,
--
Michael Christenson II
Senior Lead Developer
for The Urban Rebellion
e. mic...@theurbanrebellion.com
w. http://michael.theurbanrebellion.com/
c. (614)906-0544
Neil Wilson
inhabit different worlds. Finding your mirror in the other world is
remarkably difficult.
If anybody fancies organising 'speed dating' to bring RoR Designers
and Developers together, I'm sure they'd make a killing.
The other one is that if you are organising a team using physically
diverse individuals then you need to force everybody to work in a
physically diverse way (using BaseCamp/Campefire or whatever).
Otherwise you will create communication divisions in your team whether
you intend to or not and that will reflect itself in the project.
Computer Software *always* reflects the structure of the team that
built it.
And it goes without saying that physical colocation is by far the best
way to get a jelled team that performs. Unfortunately underneath it
all we're all just a bunch of apes that much prefer to sit under a
tree somewhere. Working round that is a hard problem to solve. Don't
underestimate it.
Neil Wilson
Aldur Systems, UK
On Dec 6, 6:41 pm, Robby Russell <ro...@planetargon.com> wrote:
> Hey all,
>
> I'm working on a blog post about things that I learned this year and
> thought, "I wonder what other people have learned." So, I thought that
> I'd come here and ask the Rails-Business community.
>
> Within the context of Rails *and* Business... what are some lessons
> that you've learned over the course of 2007?
>
> If I can get enough responses, I'd like to compile a selection for a
> "This Year in Rails Business" blog post to bring more attention to
> this great community of people. :-)
>
> Thanks,
> Robby
>
> --
> Robby Russell
> Founder and Executive Director
>
> PLANET ARGON, LLC
> Design, Development, and Hosting with Ruby on Rails
>
Joe OBrien
> thought, "I wonder what other people have learned." So, I thought that
> I'd come here and ask the Rails-Business community.
We like others have learned a lot:
Negatives:
- Stay on top of cash flow. It is king. Even if a customer says they
are going to pay, stay on top of them until they actually do.
- Realize that this is business. Great relationships mean a lot, but
do not let your trust overtake your gut feel.
- Fixed bid projects will kill any chance of having a good working
relationship (in stark contrast to the way I felt at RailsConf)
- Keep developing. As a business owner it's easy to get caught up in
the Sales side of things, or in running the company. Make sure you
allow yourself the outlet of developing software. It's what you love
to do.
Positives:
- Stay connected in the community. Make sure you are leading your
local communities and helping them thrive. In our case, that's what
brought us together in the first place. It's easy to get caught up in
the day-to-day realities of running a company and skip the monthly
Ruby Brigade meeting. Go, let loose.
- Hire the best people you can. Bringing on the people we have this
year was scary at times, but has helped in ways we never thought
possible.
- Finding time during work hours each week to devote to open source
keeps the energy high and the minds sharp.
I could go on and on. It's amazing what a learning experience
starting EdgeCase has been. We never thought we would be here, but
find ourselves incredibly excited about where we are.
Looking forward to what reflections we all have next year.
-Joe
_______________
Joe O'Brien, artisan
EdgeCase
theedgecase.com
614/453-5527
Benjamin Curtis
On Dec 8, 2007, at 9:07 AM, Joe OBrien wrote:
> - Fixed bid projects will kill any chance of having a good working
> relationship (in stark contrast to the way I felt at RailsConf)
This particular topic brings up such a diversity of opinion. :) I had
the opposite experience this past year. Having done plenty of
projects both ways, I still love fixed bids. Rather than killing
chances for good working relationships, I am actually at the moment
working on a second fixed-bid project for a client who was happy about
the first one we did earlier this year.
----
Benjamin Curtis
http://catchthebest.com/ - Recruiting software
http://www.bencurtis.com/ - Personal blog
horatio
As to matching up the programmer/designer... I've found this "gem" to
be a good starting place:
www.programmermeetdesigner.com
Andrew Stewart
On 6 Dec 2007, at 18:41, Robby Russell wrote:
> I'm working on a blog post about things that I learned this year and
> thought, "I wonder what other people have learned." So, I thought that
> I'd come here and ask the Rails-Business community.
>
> Within the context of Rails *and* Business... what are some lessons
> that you've learned over the course of 2007?
Most of my lessons this year have revolved around how to price my
work. The main one has been to remember, when pricing a piece of
work, that I must include overheads above and beyond the time the
work takes. For example our dear government has this notion of
taxation and I need to account for that. It's obvious really.
Another lesson has been that knowledge, not just time taken, is
valuable. I particularly notice this with Ruby and its beautiful
expressiveness: I might need to write just three lines of code to
achieve a task -- but my value is in knowing what those three lines
should be and where they should go.
Sometimes clients see such changes and wonder aloud why what appears
to have been a 5 minute job cost more. I don't mind because I
understand that for a non-technical person there must be no
discernible difference between a trivial three line change and a non-
trivial three line change. Hopefully the client trusts your
professional judgment when you explain the difference.
Regards,
Andy Stewart
-------
http://airbladesoftware.com
rupakg
1. If you cannot show your work or have a portfolio, you will not get
work. Even if you have tons of enterprise experience. So quit looking,
and work on some internal projects to build your portfolio.
2. John Moody's 5th point: A house divided against itself cannot stand
(very well). If you spend half your time using Rails and half using
(ASP.Net, Java, PHP), you'll find it very hard to keep switching back
and forth (at least I have).
collaborate with in projects.
4. Try to make contacts. Join a local meetup group.
5. Do not try to setup the whole business yet. Get work and everything
will follow.
Thanks,
Rupak Ganguly
President, Webintellix
www.webintellix.com
Blog: http://developershelf.blogspot.com
Blog: http://rupakg.wordpress.com
Wiki: http://railscheatsheets.wetpaint.com
Chris Kampmeier
> Another lesson has been that knowledge, not just time taken, is
> valuable. I particularly notice this with Ruby and its beautiful
> expressiveness: I might need to write just three lines of code to
> achieve a task -- but my value is in knowing what those three lines
> should be and where they should go.
>
> Sometimes clients see such changes and wonder aloud why what appears
> to have been a 5 minute job cost more.
design for Citibank -- "it's done in a second, and 34 years." Go watch
the video here: http://www.hillmancurtis.com/hc_web/film_video/source/scher.php
The whole thing is worth watching, but the relevant story starts about
40% in when they start showing shots of the Pentagram NY offices.
Chris Kampmeier
http://shiftcommathree.com
Rob Sanheim
>
> Hey all,
>
> I'm working on a blog post about things that I learned this year and
> thought, "I wonder what other people have learned." So, I thought that
> I'd come here and ask the Rails-Business community.
>
> Within the context of Rails *and* Business... what are some lessons
> that you've learned over the course of 2007?
>
> If I can get enough responses, I'd like to compile a selection for a
> "This Year in Rails Business" blog post to bring more attention to
> this great community of people. :-)
>
> Thanks,
> Robby
Distributed work is very hard, and making a "virtual team" or "virtual
company" truly function is *way* harder then most people think.
- Rob
Robert Dempsey
Michael Breen
stand
>> (very well). If you spend half your time using Rails and half using
>> other frameworks
>> (ASP.Net, Java, PHP), you'll find it very hard to keep switching
back
>> and forth (at least I have).
Good point but don't let this discourage anyone from getting into
Rails (or any other technology stack they want to use). For those who
have built a reputation and client based on a certain framework it may
not be that simple to just flip the switch over to a new tool set. You
need to support your existing clients and pay the bills if the jobs on
the "framework du jour" aren't coming.
What I learned this year:
After making the jump from .NET to Rails is don't get hung up on any
technology. That's not what your selling, you are selling your skills
as a problem solver. Rails is a fantastic framework and I love working
on it but it's not the right tool for every job. You need to do the
right thing for your client, even if that includes a solution that
doesn't include RoR.
Best.
Mike
John Moody
worth it until you have the client base to go 100% Rails! (And being
able to help your clients with their existing systems is a BIG plus
too...)
- John
-----Original Message-----
From: rails-b...@googlegroups.com
[mailto:rails-b...@googlegroups.com] On Behalf Of Michael Breen
Sent: Tuesday, December 11, 2007 5:40 AM
To: rails-b...@googlegroups.com
Joe OBrien
> company" truly function is *way* harder then most people think.
We have two people working remote and it has been a challenge, but
something I feel we have overcome. Technically we have had great
success in pairing remotely (see my blog entry about this at:
http://rubyurl.com/BZQ). The hardest part of this though is not the
pairing technologies it's a company culture issue.
We have to continue to try and make sure everyone is included in the
events. We video skype the guys in for all of our company meetings
(video is incredibly important, as it feels as if they are there, and
they feel included ... audio only makes it feel all that more
remote). We also make sure to communicate through campfire as much as
possible. This again, helps in making sure everyone feels included.
Yes it's hard, but it is by no means impossible.
David Parker
though you may be excited to work on a project (in Rails), if your
team members aren't as excited or motivated to work on the project,
then you will fail in making the deadlines that you have planned.
Though, for my team, the biggest lack of motivators is the fact that
my team members and myself don't need this job- we all have other
jobs. I think someone needs to up the stake and go full-time with the
project...
David Parker
Ideally LLC
Robby Russell
On Dec 7, 2007, at 1:13 PM, John Moody wrote:
>
> My top lessons learned this year:
>
> 1. Obsess about cashflow.
> As a former boss once put it, only cash can be directly exchanged for
> food. You run out of it, your business dies. You run low on it, and
> all of your energies are directed toward getting more of it, fast.
> Soon, that killer app you're building on the side lies dormant while
> you're just trying to make ends meet.
If you're looking for something to help manage projected cashflow,
check out PulseApp.
> 2. You don't need it.
> Yeah, that shiny 17" MacBook Pro would increase your productivity, but
> you don't need it (yet). Your old PowerBook will do for now. Save
> the
> cash. (See #1.) At the very least, wait a month and see if you still
> need it as badly as you thought you did.
This really depends on what you do. Performance does matter on some
projects... getting your specs to run, applications to run smoothly...
etc.
Invest in RAM and disk space... and backup often. (trust me... http://rubyurl.com/urv
)
Robby Russell
On Dec 6, 2007, at 10:41 AM, Robby Russell wrote:
>
> Hey all,
>
> I'm working on a blog post about things that I learned this year and
> thought, "I wonder what other people have learned." So, I thought that
> I'd come here and ask the Rails-Business community.
>
> Within the context of Rails *and* Business... what are some lessons
> that you've learned over the course of 2007?
First of all, thank you all so much for sharing your lessons with each
other. This has been very educational.
I wanted to share some of my lessons as well.
1) Watch your cash flow very closely and work with your clients to
keep a steady stream of money coming in and in return, you provide a
steady stream of quality work.
2) Hire motivated people that want to prove themselves.
3) Like a good Math student... show your work. Keep as much of your
decision making process transparent with your employees and colleagues.
4) Know that trust isn't a boolean value. Trust has many shades of
gray. Constantly re-evaluate your trust and confidence in people...
they *should* be doing the same thing... so constantly work to
reinforce their trust and confidence in you.
5) Invest in a good work environment. Read Peopleware[1] and get your
employees some natural daylight[2]... finally!
I have some more.. but thought that I'd keep it light to start with.
Links..
[1] Peopleware - http://rubyurl.com/eix
[2] Planet Argon gets closer to the sun... http://flickr.com/photos/planetargon/1873894837/
Eric Davis
1. Focus - Don't be everything to everyone. Become an expert at your
technology and market. Taking on some PHP projects has really hampered
my Rails-fu.
2. Say no - There's too much work out there to take on an mediocre project.
3. Marketing is not optional - Unless you are a brand name developer,
you need to market yourself to become one. If you are a brand name
developer, keep at it because others are gaining on you.
I've been blogging about my monthly goals and lessons since I started
freelancing, might be some more good lessons in them:
http://theadmin.org/tags/business-reviews
--
Eric Davis
Little Stream Software
http://www.LittleStreamSoftware.com
John Athayde
Robby Russell
On Dec 8, 9:07 am, Joe OBrien <j...@theedgecase.com> wrote:
> > I'm working on a blog post about things that I learned this year and
> > thought, "I wonder what other people have learned." So, I thought that
> > I'd come here and ask the Rails-Business community.
>
> Damn good idea. I love it.
>
> We like others have learned a lot:
>
> Negatives:
> - Stay on top of cash flow. It is king. Even if a customer says they
> are going to pay, stay on top of them until they actually do.
> - Realize that this is business. Great relationships mean a lot, but
> do not let your trust overtake your gut feel.
> - Fixed bid projects will kill any chance of having a good working
> relationship (in stark contrast to the way I felt at RailsConf)
> - Keep developing. As a business owner it's easy to get caught up in
> the Sales side of things, or in running the company. Make sure you
> allow yourself the outlet of developing software. It's what you love
> to do.
>
years (since hiring our first employees). Do you have any advice on
how you allow yourself to invest in development time, which often
requires that you're able to dive *deep* into a project. I tend to let
my employees dive deep and I stay shallow because I need to span
across various projects (internal and external). This tends to leave
me a bit envious of their development efforts. ;-)
Thoughts?
Robby
Aaron Blohowiak
focused thing and see if you can improve it. Quote follows.
There are advantages to being the chairman. One of my favorite perks
was picking out an issue and doing what I called a "deep dive." It's
spotting a challenge where you think you can make a difference—one
that looks like it would be fun—and then throwing the weight of your
position behind it. Some might justifiably call it "meddling." I've
often done this—just about everywhere in the company. (
http://en.wikiquote.org/wiki/Jack_Welch )
Dr Nic
prefer prompt payment:
"I have an agreement with the banks, they don't do leading edge
software development and I don't loan money".
Said with a smile, this works :)
On Dec 8, 5:54 am, Courtenay <court3...@gmail.com> wrote:
> Don't work for clients who pay more than 2 weeks after invoicing.
> Particularly don't work for clients who pay "net-90" which really means "6
> months, if ever".
>
> Even if the contact at the client is a friend.
>
David
or (2) the employee being supervised at the moment. You can have a
really narrow span of control, with mid-level supervisors that leave
you with extra time for your own projects. Or you can have a wide span
of control, that leaves you interacting with others constantly. I have
the latter, not necessarily by choice, supervising 5 developers, 1
support tech, 1 salesman, and 2 trainers. The only way I can do much
dev work is to (a) close the door and put up a sign, or (b) come in on
Saturdays when no one needs my time or attention. Having just
completed a 100 hour dev project this fall, I found it necessary to
use both of these strategies.
So it essentially comes down to how you organize your company, and how
you organize your personal priorities.
On a personal note, I was at the Red Lion Hotel in Vancouver, on the
north side of the Columbia last week at dusk, wishing you well in
Portland. Merry Christmas to all.
David
Robby Russell
On Dec 24, 2007, at 7:05 PM, Aaron Blohowiak wrote:
>
> I believe the phrase "Deep dive" comes from jack welch. pick one very
> focused thing and see if you can improve it. Quote follows.
>
> There are advantages to being the chairman. One of my favorite perks
> was picking out an issue and doing what I called a "deep dive." It's
> spotting a challenge where you think you can make a difference—one
> that looks like it would be fun—and then throwing the weight of your
> position behind it. Some might justifiably call it "meddling." I've
> often done this—just about everywhere in the company. (
> http://en.wikiquote.org/wiki/Jack_Welch )
Thanks for the link. I'll read more into that. There was a good blog
post about a developer who moved into management. He was kind enough
to share his experiences...
* Wide vs. Deep, http://blog.eod.com/post/18462877
Worth a read...