As you prob know, i'm trying to get an idea for what being a programmer in the field is like aka, creating website for clients.  How much hard coding of projects do you do?

For example,

$query = "selecT * from contacts";


now lets say that was on a page to display all people in the database.  Would I hard code that in, or try to make that a variable, and give the user the option of changing it, but if they did change just that, I would have to make all Query sets variable, which seems like a lot of work...... and a knowing of the code, which the user couldnt do.

Being a programmer, will I be responsible for long term changes or updating of their files? 

What is THE way to do it.  Create a totally massive variable, user adjustable site, or create a nice site and be the TECHNICAL person for the client

-Rob.

Having no experience of this, and not being a programmer I've no idea why I'm replying to this  : but I'd guess it depends on client abilities and needs.

If the client is technically competent and wants the ability to customise the site to that degree, then I guess there is benefit to providing a flexible interface to your applications.

It could be argued that you really should be

programming

  in a flexible open fashion anyway to ensure that the client has options in future; personally I'd always advocate open standards and flexible code bases however I guess there is a difference between achieving this and providing an interface for clients.

Just a few thoughts.

DM

Hey Rob -

Lots, yes, yes, yes, yes, perhaps, yes, yes.

Essentially, as a good freelance coder, you'll be responsible for a wide range of projects, running from creating simple sites of scant little

PHP

  nuggets to designing larger systems that let the user do stuff themselves. As a technical consultant specializing in coding with

PHP

 , you'll want to become familiar with the codebase for SMF, WordPress, perhaps

php

 Collab. Look into the various

PHP

  frameworks so that you can see how others have done it - you'll probably NOT want to create your own user frameworks as your first venture, although I would not marry ANY of the currently available frameworks just yet (if ever) since you will be tempted to see all jobs through the lens of what *that framework* can do.

Your best bet is probably to get a job that is just slightly larger than what you can handle and underbid it - because you'll burn up a lot of time figuring stuff out, and if you are charging less than the job is worth then they won't have as big a griperights as if they were paying at-scale or a premium. Sleep little, dig hard and see if you can make every single line you code a lesson in how to make use of the language.

Your largest job as a programmer, though, will eventually be design and the ability to communicate - code monkeys can write script - but a good architect/consultant can correctly gather the needs and expectations of the client, convert them into a spec, get it done and then articulate to the client exactly WHY it took 4 weeks longer than expected and is thousands over budget.

I'm only 1/2 kidding

/p

my straight up opinion is this.

putting your SQL queries into some variable that is built remotely is annoying. I spend alot of my time fishing with other peoples code, and I gotta say, every time they do a remote variable that gets built somewhere else, I get very annoyed.

Build the SQL queries where you need them, then use them right there. Obviously there are exceptions to the rule, such as really complex queries that require a giant ass function with many many many possible outcomes to build that query. But frankly those are rare. Especially your example. To put that in some variable/constants file, which is disconnected from the flow of the code, is dumb. Sure, if you ever needed to change the table name or the column name, you could have a much easier time by having all your queries in 1 place, but that is what global find/replace is for...

That said... if you anticipate a pain in the ass client, or the database is out of your control and you will get 5 minutes of warning about schema changes, then go for the central queryfile method. I have only done it once in my life, hated every minute of it, because I couldnt remember what fishing queryvariable was for which query. was it sqlUserById or sqlUserByUserID or....

Both ways have valid advantages over the other.
Inline SQL is much more readable.
Remote SQL is much more manageable.

pick your poison. And fish worrying about who will next work on your code, do what works for you. Assume you will always be the one. Sounds backwards when you consider my complaint above, but just because I complain about it, doesn't mean I don't do it myself. Exception being if you are building code for an internal team who will manage it. You don't want to look like a fishtard.

Finally ... a post I'm comfortable responding to (Thanks, Rob)

My

programming

  spectrum is a wide as the Mississippi, but you'd be hard pressed to get your ankles wet crossing the damn thing.  Variety of experiences and languages, but nowhere as deep as what the guys who run this board are accustomed to.  However, I've been around the block a few times and echo nutballs' thoughts below - write it for yourself as if you're the guy who has to maintain it forever, and keep in mind you may need to revisit your app in 6 or 8 months so I'd recommend a bit of commenting along the way - don't go crazy, you're writing an app not a book. 

That said, I tend to keep my db queries within the page that calls it primarily because I can't remember shit only moments after looking looking at something.  I kind of subscribe to Einstein's methodology: "why memorize it when you can look it up."  The only libraries I tend to create are .CSS and .JS libraries as those tend to consistently span across pages in your app.

Lastly, I once heard the story of a programmer who never commented his code and used his variables to tell a story - (if isChick($CaptainCrunch) then ($lunchAtHangingDiner = TRUE)) kind of stuff.  He was once asked by a nooB "Your code is hard to read," to which the programmer responded "It was hard to write, so it ought to be hard to read." 

I'm almost certain this didn't help, but it sure was fun to participate. 

Best of luck to you, and now I'll get out of your way. 

lol i gotta remember that one for the next time I get some smartmouthed $8/hour hack taking over my code an complaining about it.

I work based on the pay.
If im getting paid very well, ill put in more time and effort into the coding / expansibility of the project
If im getting paid peanuts and the clients are twats ill just make it work and sod whats underneath.

People get what they pay for, if your getting paid well then do a good job, if you dont get paid well then do the job
- im not advocating doing a bad job, im just saying do what you get paid for

almost all my early projects were for clients who wanted a fully blown custom cms with every bell and whistle for like $500, id literally be working at $5 an hour, after a few of those i realised my time was worth more than that.

MM, yea, everyone has to sell their soul to get started. I also had done quite a few 5/hour jobs when I started out. And even 1 or two since then, because I wanted to

learn

  something new, and figured if a client will pay me to

learn

  it, and is ok with it taking longer, then why not.

I generally code the same way no matter what now.
If the client needs it fully commented and such, I charge more, though they don't know why. not much though.

Personally I love it when I can make a buck for

learn

 ing  a new something... agree completely



I also code exactly the same way regardless of income - my experience is that I can usually convert low-paying or small-job customers into bigger ones if I play my cards right - I don't like to deal with my own shit code, so I make sure that whatever I do I can work with later. sometimes I take it in the pooter, but very, very rarely.

i used to do that as well, since my code is generally pretty funky once you get down to the 5 iteration of "can we add this feature?"

But since I now am so much more entrenched in my own methodologies, I don't really need comments anymore, except in the places where I KNOW i need them. like some crazy ass math check.

Mostly though I have realized that the length of the comment is inversely proportional to my ability to understand it 1 year later.

No lie. If I have to comment then it's usually some weird shit and I'll prolly have a tough time later in any case.

If someone says they want something, i always assume they want somethign 10x as big and code accordingly.
They dont know it yet but they want it, they just didnt know how to tell you, even though you asked if they wanted it!

I used to do that as well, but screwed myself enough times to stop. Now, if a client says 'well why didnt you think of doing that before we got to this point?' I usually either spew some mumbo jumbo if they are already paying me well and I want to keep them.
OR
'I was hired as a programmer and my consulting and analysis services were not needed. If they are now needed, i would be happy to provide them for a fee.' if i could give a shit about them.

If they are hourly, i just say, 'OH! I would be happy to spec out the project for you and determine all the required features!'

Truly, a man of experience