mzarate06

As a developer, this is the type of post I find very informative. But, what is leading?

Yes, the Freelancer plan only allows up to 10 clients at any given time. That means if you've entered 10 clients, and want to add another, you'll either need to upgrade, or delete a client. The pricing being based on the # of clients is just 1 option we considered. Might another metric be more useful to you? We'd love feedback in regard to that: support-at-timepanel.net.

As to whether there is a way to record historical results, can you clarify? Perhaps you're asking how to import past clients, projects, or invoices? If so, we're working on an import tool right now; it's a big priority (i.e. others are asking about this as well) and we're hoping to get that out in the next week or two.

Does that help?

I'll start working on getting projects to save for the demo.

Thanks for giving it a test drive!

Everyone thinks that this exit interview is your last chance for you to let management know that things need to change. Everyone thinks that they are going to be the change catalyst on the way out of the company. You're going to be the hero!

This all sounds a little over the top.

My experience has been that HR was quite clear they would share the feedback I gave in my exit interviews among company leadership to help improve the work environment or culture. Even if it got out more than that, no big deal. (except if we're talking about an extreme case, e.g. an employee leaving due to sexual harassment.) And, given that I had high respect for many that remained at the companies I've left, I willingly gave honest feedback if it might have any chance of improving their work environment after I left.

I respect the author's opinion, but it sounds like unnecessary hyping of exit interviews, and bad advice ("exit interviews are a fraud, they're worthless, so lie!!").

I'm assuming that holds true for you? If so, how did clients respond to that? I'm curious to hear about existing clients you transitioned from hourly (if applicable), and new clients that were introduced to that pay structure from day 1 (b/c most new clients I encounter have only heard of fixed pricing or hourly billing).

- full time contract work for at least 6 months

- my LLC formed (US only, I think)

- my site built, setup w/analytics, a blog, Google webmaster tools, etc.

- my first set of business cards in hand (may not be that important to some people, but they came in handy for me)

- other misc. stuff (spoke to my CPA about taxes, researched sample contracts, looked into software I'd need, etc.)

Doing all that while still having income meant that I didn't have to trade billable time for those once I became a consultant. When you're running your own business, you'll always have to invest non-billable time, but those first 3/6/12 months are always the hardest, so do what you can to maximize billable hours and finding more clients or work, w/out overwhelming yourself.

Would you mind sharing who some of those people are? I personally disagree with that, and I'd be interested in reading more about the rationale behind such suggestions.

The key to confidence is entirely about doing things despite the fact you're scared stiff. ... It's trying even when you'll probably fail.

I agree, nothing in life comes easy. In particular, going through risk or adversity for the sake of achieving beyond that is the key to being mentally tough.

We don't gain confidence, or become better people, by sitting on the couch and doing nothing. Instead, we make all kinds of decisions throughout life (taking that daily jog, competing in that martial arts tournament, working that extra hour, etc.) to achieve higher, long-term payoffs. In doing so, it should be accepted that the pain or discomfort that comes along with those decisions is simply the cost of admission.

Most of the failed outsource attempts I know of are one way or another due to non-technical team members attempting to lead technical teams. That a developer could lead another developer, or team of developers, down the right path sooner, more efficiently, and for a longer duration, makes perfect sense. In practice, it's worked brilliantly for the teams I've worked with.

Even still, it takes a special kind of developer to successfully outsource development work. It's not sufficient to simply push work over a wall and accept whatever comes back. Things like well defined requirements, frequent code reviews, detailed mockups, and clearly stated user stories are critical, b/c when you outsource work, the default regresses from what you'd normally expect to substandard work.

But, that's not always due to the outsourced team. Often times its on the hiring party to identify what they need to do better. Great results start with great teams, and part of being a great team is understanding that accountability for the overall result flows both ways.

Its 3rd beta update was released in May, and we're hoping to launch very soon. While its technically not profitable, it does have a small # of users, and we still have the payment system to hook up.

Despite it being very young, building it has been an incredible amount of work, and one of the most enjoyable experiences I've ever had.

Number of users is slowly growing, and I just released its 3rd beta update; looking to formally launch very soon.

a) return the error messages, even if only in dev environments

b) convince my supervisor that I should have access to the shared api server

c) run the entire app stack in a local dev environment (which I prefer the most)

We're making progress on all those now, but only after a round or 2 of push back from my supervisor.

Especially when it's completely unnecessary. Some of my recent work has taken longer than it should b/c I'm having to debug my work through my supervisor. By through, I mean that he insists on watching the error logs on a remote server for me, and then telling me what the error is, and then I can adjust my code. My request to gain access to the entire stack so that I can debug my work on my own was met with defensive arguments.

"This has been described by Douglas Crockford—the inventor of JSON..."

He didn't invent it.

Source: Douglas Crockford @ 0:55 - 1:10 in this video: http://www.youtube.com/watch?v=kc8BAR7SHJI

We may include generic coding questions that can be answered in any language of the candidate's choosing, but we always try to include a couple in languages that the position targets.

I tire from that very thing, very quickly. I've worked with too many "idea" guys that always want to see 10 ideas started, vs. 1 completed and executed really well. Maybe they're trying to find that 1 great idea by trying out many, but a lot of times I see startups start one thing without finishing another. In the end, after XYZ time frame, the company really doesn't have 1 solid feature to show for it, only multiple half ass ones.

What's worse, at least from what I've experienced, is that a lot of those ideas or features are secondary, or tertiary, with regard to what the core product should really support.

It will indeed, for folks that prefer that or haven't looked into enabling alternate behavior. Set STRICT_TRANS_TABLES (for InnoDB) or STRICT_ALL_TABLES (for any storage engine) in MySQL's config and it'll throw the following error instead of silently truncating data:

[Err] 1406 - Data too long for column '[some column]' at row [XYZ]

Does that help?

Sure, if you're not careful; but that's the case w/any language or layer of an application stack. I'd consider becoming familiar w/JavaScript a greater concern though. Learn to avoid JavaScript's foot guns, and use tools like Speed Tracer to help profile your JavaScript.

If it matters, my time tracking and invoicing product uses heavy client side processing, to the point where some of its reports never touch the server. We're seeing response times in the low ten's of milliseconds when relying on JS-only generated reports.

css variables, transforms, gradients, border-radius, multiple background images, etc.

... you'll be glad to know that those features are available as well and that you don't have to add complexity to whatever you're building to hack those in. I also don't see how CSS variables, or other recent CSS features, hinder anyone from learning from a site's code.

All these things make it easier to create stuff. My only complaint is that they're not added soon enough.

I also regretted getting that degree for the longest time, now it doesn't bother me so much. I wish I had gotten a CS degree.

I'm really not that demanding when it comes to the performance of a server side language. PHP + APC has been proven to be almost as fast as C++ (well, Facebook's Hip Hop, which is written in C++), and I'd argue that the biggest bottle necks in a web app are always the network latency and the database, so that's where I spend most of my performance tuning.

http://www.enrise.com/2012/02/zend-framework-2-performance/

In ZF's defense, the ZF team has stated that they're aware of the performance problems and that they'll look at those at a later stage. However, that, combined w/your review, combined w/the complexity I see every time I view a profiled call stack of a ZF app in KCacheGrind, really make me want to start rolling my own framework. I've done just that w/my JavaScript, and I'm loving the net positive in simplicity and speed. The growing complexity of ZF makes me want to go that direction with my PHP code as well (though I'll probably look at simpler frameworks first, like Lithium) .

In regard to the following line of ZF2 code cited in the post ...

$message = $this->getRequest()->query()->get('message', 'foo');

That line in ZF1 would look like ...

$message = $this->_getParam('message', 'foo');

Not much of a difference, but I wonder what was wrong w/ZF1's less verbose alternative?

However, I always found myself missing the math aspects of CS, and to this day I regret not having the lower level foundation that CS offers over CIS/MIS. In hindsight, I would've stuck w/CS.

1) While I found most non-technical folks seeking freelancers to prefer a portfolio over a resume, the same wasn't true for dev firms. They usually have technical staff on board, so even though I lacked a portfolio at the time, they still recognized my technical accomplishments and background (whereas my non-technical clients really don't understand that stuff, they'd rather see a portfolio).

2) Many make use of contractors at a regular frequency, so if you're able to hook up with one, or a few, they'll help provide steady work during the early times.

3) Since they provide steady work, you don't have to concentrate as much on networking or marketing yourself. You'll eventually have to worry about that stuff, but when you're starting out you have so many other things to worry about. Dev firms help defer that burden, or at least keep the work coming while you figure that stuff out.

Best of luck. Freelancing can be tough when you start out, but very rewarding once you get into a good rhythm.

Something I'm constantly reminded of is the haste Congress showed in trying to reach a final vote. I sat through 11 and 4 hour SOPA committee sessions (video), and if it hadn't been for strong opponents like Congresswoman Lofgren and Congressman Issa, who literally forced a count for each amendment vote made as a way to help put the brakes on, SOPA probably would have advanced another step.

I'm thankful for the time they helped buy, that ultimately gave opponents the chance to produce the response that we did. SOPA may not be truly "dead", but it's reassuring to know that our voice can have an impact.

I thought ... tiresome browser-compatibility fixes were a thing of the past

Not by a long shot. One thing to keep in mind are browser half-lives. IE's decay rate, in particular, is horrible. IE 6 is still a problem in some sectors, and IE 7 & 8 still linger just as much, if not more. IE 9 is a huge step in the right direction, but still, more advanced features such as support for local databases, ES 5 strict, web sockets, and web workers, won't land until IE 10. The same is even true for lesser features that other browsers have had for years, like text shadow.

Javascript: The Good Parts by Crockford Javascript Patterns, by Stefanov Javascript Web Applications, by MacCaw