Comment by jrogers65 | Hacker News Reader

Comment by jrogers65 | Hacker News Reader

Parent Full thread

I appreciate that resources are always tight in these situations so I would recommend that you hire an experienced developer to review your code. It's cheaper than hiring someone full time and you should still be able to get a lot of value out of it. They will know about nuances and gotchas that only years of working on code can teach. Addressing those early rather than late is probably a good idea.

A cheaper (no money but more time spent) alternative is to use forums and IRC channels to get advice. There are plenty of knowledgable people who are more than willing to help if you ask.

Some basics which are vitally important to cover are ensuring that the object model and database schema are solid and extensible, that there are automated tests in place (especially for business critical functionality), that everything is documented (otherwise you will waste inordinate amounts of time explaining how things work to any developers you hire in the future and/or relearning parts of your own code after forgetting what it does) and that everything is backed up to multiple locations. Addressing those concerns puts you well ahead of the pack.

Thanks. Really appreciate the feedback.

It's so tempting to keep build quick and sloppy, but I know I need to be more diligent with testing and documenting.

I'm setting a relatively low target number of users to acquire just to make sure this idea has a chance, before bringing on a developer.

Very broad question, but how does one find an experienced developer? I live in New York, but have zero tech connections.

> It's so tempting to keep build quick and sloppy

That's normal when you're starting out. The only reason more experienced developers do not give into this impulse is because they've learned of the consequences through painful experience.

I would recommend looking at the people who contribute to Rails, Ruby and related projects on Github. The core developers will be far too expensive but people who throw some code out every so often (assuming that their pull requests are usually accepted and nobody is shouting at them in the comments) will likely know their stuff and may have reasonable prices.

IRC channels on Freenode such as #ruby and #rubyonrails will likely prove useful too. Look out for people who answer a lot of questions (and get them right). One strategy is to try to design a solution for a feature by yourself, then summarise the design (i.e. show the relevant code snippets) in a Github Gist or pastebin page and ask for feedback. If there are any glaring faults or simply better ways to achieve the result then they will be pointed out to you.

Thanks for the info. Very helpful. Will check out those sources!

Re: where to find experienced developers with no tech connections, that's not really a problem. Here's why: It's similar to a man asking, "Hey, know any models I can date?"

Actually, beautiful women are hardly rare. But it's the qualifier that's important: "models I can date??"

Good developers might be rare, but they're not hard to find. They are, however, hard to woo. You know the drill on how to woo them, it's just inconvenient/hard/expensive. But at least it's pretty well laid out.

Nice analogy. I'm hoping to find a girl that doesn't yet realize she's pretty enough to be a model, and hasn't yet developed that diva attitude ;)

The best documentation is the code itself. Check out the book Clean Code for great details.

I heartily agree that good code makes sense on it's own.

One of the things which good code and inline documentation (comments) do not communicate very well is a high level overview of the architecture of the application. In my opinion, it is better to describe such things using external documents and diagrams.

The same goes for the deployment procedures and the way the servers are laid out as well as dependencies. For example, the place I'm currently at had no documentation what-so-ever for the libraries and modules necessary to run the in-house web application and, consequently, it took us more time than it should have to figure out what needed to be installed when we moved to a new server.

Thanks for the book recommendation, seems like a great one judging by the reviews. It's always useful to learn more - will add it to my 'to read' list.

Reply on news.ycombinator.com