I am easily the sexiest programmer on GFY :2 cents:

I still use vi for absolutely everything (including on my desktop)... Hell two years ago I still used it for composing emails. I stopped freelance programming 2 years ago, but even for my own sites and program I've got four ssh sessions to my servers, two with mysql command line and two with various files open in vi.

Can't type without creating syntax errors? Some of us are just prodigies I guess.

Yeah, I wrote the article with no person preferences in mind; it was meant to help those seeking to hire people. Arguing about what methods certain coders choose to employ would be another whole topic altogether :)

All great points Joe and I know you've gone through dozens of bad programming experiences off which to base these points. Other readers would do well to heed your advice :)

I have just finished reading what was added here after my first post and feel like I have to chime in.

It has been my experience that clients (and bosses in the employer-employee situation) do not want to pay the extra price that documentation and project management, version control can add to a project.

When I estimate something I give the full blown number, with documentation and project management included. Without an exception it always comes down to "That much? Isn't there any way you can do it for less???" or "That long, isn't there a way you can get it done quicker??".

Clients and employers do not seem to believe that there are jobs that actually take longer than 2 weeks to complete.

The first thing thrown out is documentation. Properly documenting code can/will dramatically increase the time of developement unless you happen to have a full library of all the modules that you will need to complete the job.

Project management and versioning is the next thing thrown out. It is not needed to get the job done (It could be argued that it is needed to get the job done properly but that is a different story).

I generally end up programming by the seat of my pants. Screw modular, my clients just want it to work.

I pride myself on writing very readable code (I call it kindergarten code) and given enough time to do it properly it is compact and modular and documented but in the real world that is usually not the case.

In the real world it is spaghettied (sp?) out and rambles on. You rarely get beyond cut 1 because the client wants to move forward. The code works, that is all they care about. They do not want to pay for clean up, they do not want to pay for the time it takes to do something properly.

So you fly by the seat of the pants and hope that you don't crash and burn.

Just my :2 cents:

Shouldn't it be "I am 'arguably' the sexiest programmer on GFY? ;)

When are we gonna get an Educational Series article out of you??

nice thread :thumbsup

Solid point. Many a time I have seen people wanting the fastest "band-aid" solution, which isn't a real solution. It may work now, but it'll come off later and leave you bleeding.

That just reminded me of a point I forgot to cover in the original post:

Many times, a programmer may tell you "your project has to be re-done from scratch, the current code is a mess/unusable". While often true, I have also found that programmers push that option when its unnecessary for their own benefit. This way they get to do it "their way" as well as likely make more money (as it will take longer). The client should always be wary of restarting a project from scratch unless it truly is an irreparable disaster.

Yeah Fuze, I don't recall any girls screaming your name out on strange GFY bus rides in the middle of the night :winkwink:

Thanx.

On your point. There have been many times, when I have looked at someone else's code that I have arrived at the conclusion that I can write it from scratch faster than I can figure out what the other coder was doing.

If the job is something that is up and running, then I never push for a rewrite.

If the job is a rescue (and often that is where I come in) then I will push the re-write. It is not to put more cash in my pocket though. It is to get a job up and working as quickly as possible.

I don't know of a programmer around that while looking at someone else's code doesn't have the immediate reaction "Who wrote this shit?".

I try to get past that reaction and properly evaluate the code. Am I reacting to style or substance? If I am reacting to style I try to live with the code. If I am reacting to substance I push for the re-write.

I have found through the years that there are a bazillion (yes, thats a number) ways to code something. If all bazillion ways arrives at the same answer then they are all correct. Some may be faster, some may be more elegant but if they all reach the same result then they are all correct.

Just a little humor. I was in working on something about 2 weeks ago and had the usual reaction of "who wrote this shit?". Well, I wrote that shit about 8 years ago ;p It was a journey through what I had added to my knowledge base across the past decade to read through it and yes, I did a re-write.

I know exactly what you are talking about - happens to me every time I start work on a new personal project, which are usually spaced pretty far apart since they are mostly for my own fun and each time I build it much more efficiently than my previous work; a new trick here, a new class there. :winkwink:

Experience is definitely one of the best assets a programmer can have.

Excellent write up.

I can't stress the importance of proper thorough specifications enough. Back when I was freelancing full time I turned down 90% of the people who contacted me and the most common reason was because there weren't sufficient specs.

I've learned from experience it just isn't worth working on those types of projects.

Also, the more experienced programmers make use of meta-programming. It has been said that "Great programmers can write better programmers than they can hire". That is one of the primary reasons why some programmers can get done in 1 hour what would take another programmer 10-20 hours.

The great programmers know how to find the best solution to a problem. If you are a carpenter and all you know how to use is a hammer then you are going to have a very hard time trying to cut a board to a certain length. It is going to be a long and tedious process. Sure you can get it done, but with the right tools you can get it done faster. Which would you rather do, pay the $9/hr guy for 100 hours to cut boards with a hammer, or hire someone who actually knows what a saw is and get it done in 1 hour for $100?

A good question to ask programmers is what other languages they know and use. Even if the project only requires PHP, if they know 10 other languages they are most likely going to write better PHP code. The more styles of coding they have seen and worked with the more they can write efficient code.

The thing about programming is that you can create your own tools. So a programmer that knows about a tool in one language that doesn't exist in PHP can just create it. Versus the average joe PHP programmer who would just bang away on that board with the hammer until it is chipped down to the correct length.

documentation, documentation, documentation.... very important.


I lucked out and found a great programmer 8 years ago and he has been full time working ever since. I've used out source companies for over flow projects when we had a lot going on at different times and was never satisfied from my personal experiences.

I use vi quite frequently. Vi has code completion just like an IDE has as well. Most people don't know about it though. I used GUI's before vi, I just found vi easier to work with once I went through the learning curve. Of course I also type on a dvorak keyboard for most English based text (emails and IM) ;)

Once you master vi you can get things done so much faster. The problem is it can take you a week to get to the proficiency level of notepad and another month before you start seeing any real benefit to using it. A lot of GUI's force you to switch between keyboard and mouse. I keep my hand on the keyboard the entire time and don't even move my hand to the arrow keys. Moving your hand from home row to the arrows takes away from thinking power.

vi doesn't really make you productive until you can edit code without using the arrow keys (h,j,k,l) and can jump around the file. In a GUI you would have to click at the spot or you'd have to hold down the key until you get to the correct cursor position. When you get good at vi you can literally jump to where you want in fractions of a second (even if it is 40 lines down and 8 tokens in).

Still GUI's have their uses. They are good if you need to jump between multiple files and be taken right to the function. Of course, vi does this a well but I haven't spent the time to learn that part of it yet.

I also use TextMate, Emacs (when working in interactive REPL-based languages), and occasionally GUI's. It all depends on the task and what I need to do at that moment. If I need a lot of keyboard macro's I'll use textmate. If I need to just do general coding or quick one off repetitions I'll use vi. If I need to jump around code a lot from file to file I'll use a GUI. It's all about the right tool at the right time. I'll edit the same file in multiple editors sometimes.

I use nano and zend.

Great post Keith, a lot of very useful nuggets for potential employers - and a reality check on salaries. Both adult and mainstream can be notorious for people trying to squeeze out quality out of a tiny budget.

Someone should make another educational series post along the theme of 'My luck with designers/programmers sucks, they keep bailing on me. Those assholes. What I'm paying in this terrible economic climate is better than them not getting paid at all.'

I agree with the people who spoke about specifications... the number one issue I have dealt with as a developer is that 9 times out of 10 the client changes the spec after the project is already under development... they see what was completed (based on the original spec) and decide they want something different or they hear about buzzword feature xyz and decide they want to add that but they typically don't want to pay more and they typically don't want to change the delivery date.

Secondly, about deadlines... even experienced developers will miss deadlines if the original spec has changed or if there has been a complication during the development process.

A perfect example of this would be a project where the developer is integrating a third party script that he/she is not intimately familiar with. I recently ran into this problem while integrating a script that has very little documentation for a developer. During the development, I identified 2 bugs in the third party script that had to be fixed before we could test the integration and a number of unexpected problems appeared as we developed the integration. I missed the deadline by 4 days...

Developers are not magicians... make sure your deadline accounts for unexpected delays if it's a major project and don't be pissed off at the developer for missing the deadline if he has communicated with you every step of the way. Sometimes deadlines are arbitrary... most developers view them as targets... if your project is large, you have a 90% chance of missing your deadline that was set arbitrarily... a deadline is always subject to missing data when the deadline was set.

wanna know how to do it

HaHa! Sooo true! :) Wow, 5 years have flown right by...

Only 5? Wow it seems like so much longer :)

A very useful post :thumbsup

"Who wrote this shit?" ... hell with 8 years, I say this about some of my own code after a few weeks.

I tend to tell the programmers what I want the system to do VERY rough (I have A, I need B, figure it out)
Then I ask them to write the specs, then I review it
Then I ask them to make the flow charts and the pseudo code.
Then I ask them to design the database structure.

After that I ask them to write the code.

This way I can weed out the people that can't come up with a solution fairly fast or can't work independent.

This may not be the best solution for everyone, but having a smaller company with only 4 programmers this appears to be the most efficient way for us :2 cents:

This probably wouldn't work on a freelance / project basis as they are usually dealt with on an agreed price rather than per hour and they are usually not in-house.

P.S. reason to ask developers to write specs is to show that they fully understand the assignment

You must have some technical knowledge yourself though, at least vaguely, to properly review their pseudo code logic and database structure. I think for many who are hiring, they are unfortunately without that knowledge, so it would be hard for them to do.

I can vaguely recognize codes, been programming for multiple years as well as taken classes, when other kids was out selling lemonade me and a buddy of mine made a sell lemonade game for the commodore computer instead :1orglaugh:pimp

I pretty much stopped during any kind coding 6-7 years ago but the general principles still stick

Ah, I remember the commodore where you had to program on cassette tape that was sold as an add-on (at least with the VIC 20) :winkwink:

Could I please get a mod to move that post of mine in here? Lots of good info that thing :)

Thanks!

I used to be more like that until I started using UltraEdit... There's so much functionality packed into that thing that it's hard to stop using it once you've adopted it. The additions over just an editor are fantastic... Just starting from simple things like projects, being able to grep within a project, and switching projects easily to more advanced stuff like setting up macros for git or svn commands, piping script output back into a new file, opening files from ftp and having the event save a local backup copy, hotkeys to launch external apps and scripts, etc...

Once you start integrating all of that into your routine it becomes so nice to have it all available to you in single application. I see you wrote TextMate so I'm guessing you're an os x guy. I believe UltraEdit is coming out with an OS X version very soon. Another thing that's so fantastic about UltraEdit is their development speed. They're releasing version 16 and they do about 3 - 5 minor revisions inbetween majors. They just keep making additions... Don't even get me started on the lack of updates for TextMate ;)

That is a lot of money. :2 cents:

useful article

Great post Varius

Great post!:)

As a developer In the 90's i worked for main stream companies, a lot of money thanks to Dotcoms, then when that died in early 2000 i moved to Adult. Very good living until about late 2008. Now 70% of the work i do is mainstream and 30% adult.

I think by end of 2010 it will be all mainstream, their is more money on the other side.

I am glad to see someone took the time to write this up. My beef with the adult industry was that they always wanted something for nothing. Most programmers like myself, who can churn out quality work, were being offered $10 an hour or so for years. Its just not worth it. Good write-up and clear documentation always helps, a good programmer though can also take most people's ideas and expand on them to make them even better for the client.

Its too bad the adult industry is still mostly stuck with using PHP when there are so many better languages and ways to build things faster out there.

As far as development, Emacs and/or TextMate are the best imho.

Thanks for the write up, it was an interesting read.

One thing I'd add is that I don't understand why anyone would pay a non-employee at an hourly rate. When I have code work done I always pay 'pre project' not 'per hour.' I think it's a much better way to go for several reasons:

1) If you pay per project you have cost certainty. You know exactly what the code work will cost before any work is started and can decide if the investment is worth it based on your projected ROI before any money is spent.

2) If I find a coder who can complete their work much faster than 'normal' they should not be penalized for being quick. When you pay per hour for anything, you create an incentive for the person to take their time with it because they fear sending you the completed job quickly and being asked to reduce the price. I want the work done right and I want it done as soon as possible... being done ahead of schedule is a good thing not a bad thing.

3) I agree very much with what others have said about creating very specific terms for the project. If you find a coder who is not willing to give you a project price it usually means you failed to make a specific enough set of instructions for the project. If your specs are clear, a good coder can tell you how much it will cost to build... so while a per hour rate allows you to hire someone willing to take their time and fumble their way through a murky set of instructions... a per project price requires you to be much more specific and gives the coder good incentive to think things through and ask questions for clarification BEFORE they begin their work.

Incidentally, I price text work per project rather than per word or per hour for many of the same reasons... :2 cents:

thanks a lot

I like pie.

I wanna be a programmer.

You have some very good points and I agree, per project is a great way to do business, for all parties involved. Setting milestones for payment is important though, so large amounts of work do not go on without being compensated and it allows one part to be approved before proceeding, possibly continuing in a wrong manner.

I think the only time per-hour should apply for freelancing, is when a task estimate is fairly impossible. Let's take the case where you have a MySQL problem where under certain circumstances, queries are very slow, mysql crashes, or some other form of undesired behaviour yet you cannot manage to pinpoint the cause. It would be very hard for a programmer to estimate exactly how long it would take.

In such circumstances, I think the best approach is for the client to say something like "I am willing to spend $500 on solving this problem. If you are unable to solve it in that timeframe - say at $125/hour that's 4 hours work - let's see what you have found out and if it's worth putting more time into it or not. Debugging is usually hard to estimate and thus, usually, is a per-hour task.

Yes, I agree completely.