What mentality should i approach this with?
I wrote my first line of code about two days ago and am currently reading a html, css guide book. How long do you think it will take me to develop a site (after learning some sripting languages) like elance for example. I work about 8 hours a day and am making real progress with html. I am a COMPLETE NEWBIE. Any advice on the mentality i should be taking here. And can anyone here with experience tell me what mentality they adopt when they are coding.
Depends on how big the site is and how complex you want it to be and your typing speed.
Don't try and leap into complex designs on day 1. Build up your understanding of the basics first with some simple pages.
Welcome aboard zencoder,
I've been coding Perl for over 16 years, PHP for 8 or so, amd myself? Sheesh as an eLance provider, it would take me **months** just to clean up the bugs and security issues they have there, if I'm even good enough to find them. So you're looking at a long way to go. But fear not, a journey of a thousand miles . . . . you know.
|...tell me what mentality they adopt when they are coding. |
- No matter how proud you may be of your accomplishment, it will always have something that can be improved. Don't assume it's bullet proof, it never is, but strive to get as close as you can.
- The biggest mistake any coder can make is to assume "my customers won't be doing this or that," listen to complaints and interpret them as something you didn't consider. Incorporate the concepts into a revision. Some examples are "best used at x resolution" best viewed in x browser" or "90% of my customers aren't on a Mac, so tough luck for them." Stick to (what I consider) the first prime objective of web applications: anyone can access your content regardless of how they do it.
- Security first. Too often the push is to "get the job done" and once a solution is cobbled together, it never gets revisited. That is, until the hackers find it and cause problems. Address security with every line of code you write.
- recycle, repurpose, reuse, compartmentalize. When you're scripting, approach each task and try to build a function or class that can be repurposed by other areas of your program, or even other programs. Google for "spaghetti code" to see why this is so imprtant.
- Learn by example. No matter how good you get, there are always thousands who are faster, sharper, and more knowledgeable than you and there is sooooo much to be learned from "playing around" with open source code, picking it apart, seeing what it does and why it works.
- Learn to let go. Personally I see every project as a challenge and often time find myself determined to pound that square peg into the round hole just so I can meet the challenge - don't fall for the mewlings of your ego. :-) If there's an open source solution, let it go and use it. Use available resources and don't re-invent the wheel; this is actually something I have to work on myself. :-)
- Many times "I don't know" or "I don't yet have those skills" is a perfectly valid answer. And it's one that will be much more beneficial to you than saying "yes, I can do that" and having it blow up on you or patching it together and causing security or performance problems.
Your clients will forget "I don't know." They will never forget you BS'ing your way through a project.
>>develop a site like elance
Not trying to be snide, but is this a serious request?
You need a serious apprenticeship, if you are going to build a complex site like elance that matches strangers, takes credit cards and runs an escrow system. I would say that no site like that should ever be built by a single programmer without at least one other set of eyes to run code audits and so forth.
That said, you can get a lot of the pieces of such a site in ready-made scripts and try to piece them together. Others have done it. But before you build a site that handles money and exposes you to serious liability, it would be nice to find a chance to work with a team that really does security right.
So getting a site that kind of works like elance is a tall, but not insurmountable order. Getting one to work like that and is rock solid in terms of security will be much harder. That last 0.1% of refinement in the code is what makes the difference there.
A couple other comments on rocknbill's post.
>>assume "my customers won't...
There's an adage along the lines of "Be permissive in what you accept, strict in what you return".
Following that goes a long way to achieving stability, security and usability in an application. To give one example, let's say you have a phone number blank on your form. Being permissive in what you accept means that you would accept
Being strict in what you return means that the function that reads in the phone number data would realize that only numbers matter and anything else could be used by a hacker or lead to unexpected data being sent further down the pipeline. So the first thing your function would do is strip out anything that's not numeric, verify that it fits the requirements for a phone number (10 digits in the US or Canada), and so forth. So the function would be very strict about what it passes on to other parts of the program.
- Learn some basic debugging procedures. Learn to simplify use cases, learn to boil something down to it's essence for testing purposes. I think my ancient post on troubleshooting in PHP [webmasterworld.com] is still decent advice and the ideas can be generalized to CSS and HTML problems as well.
And for a more lighthearted look at how not to code, [webmasterworld.com...]
One more thing - if you want to build complex sites from scratch, it can help to get involved with open source projects.
I was involved with a shopping cart project for a while and learned a lot of worst practices and some best practices too. So pick a "mature" project where someone has thought about the code a bit.
"like elance for example"
As others pointed out, that's a company, not a one-man job. So for your mindset: there's only so much a person can do by themself. That applies to coding as well.
That said, you clearly have an entrepreneur in you (8 hours a day? High-five!) so that doesn't mean, "Don't dream big."
Mindset: you've written your first line of code two days ago and are already envisioning really complex sites. That's not a bad thing (heck, why would someone be learning html if they didn't dream they could handle a complex site one day?) but DON'T RUSH. Just because you can go to an advanced topic, hack something together, and make it show up the way you want it that one time does not mean you're ready to say, "OK, I'll add that to my toolkit. On to the next chapter." I speak from experience; I taught myself html and css very young, so I did it by reading source code, editing it, and seeing what happened. That meant I could get pages to look (at least roughly) like I wanted, but I didn't always understand WHY. It worked at the time, but it caused me a lot of grief and frustration down the road.
Be enthusiastic about learning anyway. Think of it as learning deeply, not slowly. If you spent 3 hours on tables, rather than an hour on tables, an hour on iFrames, and an hour on CSS, you still learned for three hours; and will know more when you close the book.
Be determined and don't get discouraged. Maybe yesterday you blew through two chapters. Maybe today you spent 5 hours trying to figure out why one little div didn't look right. I guarantee you, every programmer out there has spent 5 hours (and probably more) wondering why their code isn't working. If you're really stuck, you can always ask for help.
"Things should be made as simple as possible, but not simpler." -Albert Einstein
When you find yourself envisioning a really complicated layout with a bunch of divs, float, position:absolute, margins, and padding, ask yourself: could I do the same thing with a table? Don't be proud of complex code. Be proud of simple, elegant code that does the same thing.
Finally, come up with something that keeps you lighthearted. Solving bugs will often be very frustrating. (When I find myself getting really angry, I start to personify my content blocks. "Isn't that red table stubborn?"
It keeps me more bemused than annoyed.)
Oh, and finally finally: if you're not a fast typer, it'll help a lot to become one. There are lots of games on the internet that you can use to practice. Playing them might also be a good way to take a mental break when you need one.
The mentality I take is kind of like this:
1) break every project into the smallest possible parts (functions, variables, etc)
2) group like parts together (classes)
3) every input needs to be exactly what I want
4) output exactly what needs to be output