PHP Guys Up to Creating Modern Web Site?
December 24, 2010 5:40 PM Subscribe
Would it be a mistake to hire smart PHP-based web programmers to create a slick cutting-edge mainstream site?
They are energetic, bright, and diligent; very well-educated in computer science with a solid basis in C++. , but they've been working for a moldy old corporation and their training is stuck in 2002. They've only barely heard of Ruby, AJAX, etc.
When the concern is raised, they reply that learning new languages is no problem. They're very strong at semantics, and syntax can be learned quickly. They're fast learners.
But the worry is that it might be one thing to learn a language, and another to know its ins-and-outs...much less which works best for what task.
So, what do you think? Are really good PHP people up to the task of creating a bleeding edge, slick web site catering to a broad mainstream audience accustomed to snappy sleek magical usability? Presumably, that means AJAX, but it'd be great to get your views.
They are energetic, bright, and diligent; very well-educated in computer science with a solid basis in C++. , but they've been working for a moldy old corporation and their training is stuck in 2002. They've only barely heard of Ruby, AJAX, etc.
When the concern is raised, they reply that learning new languages is no problem. They're very strong at semantics, and syntax can be learned quickly. They're fast learners.
But the worry is that it might be one thing to learn a language, and another to know its ins-and-outs...much less which works best for what task.
So, what do you think? Are really good PHP people up to the task of creating a bleeding edge, slick web site catering to a broad mainstream audience accustomed to snappy sleek magical usability? Presumably, that means AJAX, but it'd be great to get your views.
Certainly, there are plenty of very bright, capable people doing PHP work. I don't think working in PHP makes you a bad programmer or anything like that. I'm of the opinion that lots of newer web programming techniques are less about a particular language than about a general methodology. Newer programming languages are often better-suited to these more complex architectures than were their predecessors, like PHP, which is, I think, why you see lots of emphasis on Ruby, Python, etc., in model-view-controller programming, vs. PHP, but I don't think it means that that sort of thing *can't* be done with PHP, but only that it'd be easier with something else.
All of that said, my personal experience was that I did PHP work, and as I started to want to built more architecturally complex applications, I found PHP limiting. I personally think PHP encourages the formation of bad habits, and think that people that are serious about writing heavy-duty web code will probably run into the same frustrations I did, and feel compelled to expand their horizons and become acquainted with newer technologies. The fact that these people seem to have become complacent, well-educated though they may be, about the state of the art in their fields would make me nervous. Again, I don't want this to sound overly disparaging, particularly to PHP programmers; I don't think every web programmer should know Ruby. My Ruby skills are pretty awful. But "barely even heard of Ruby" makes me think they don't follow what's going on in web programming at all, and AJAX programming is complicated and fundamentally different from all-server-side work; it takes effort and experience to get good at it.
I'm not really sure if that answers your question. I guess I'd sum up by agreeing with them that in general, learning new languages is pretty easy if your foundation is solid, but learning whole new ways of tackling problems is hard, and I think you're right to be concerned about that, here, though it's quite possible that they'd do a great job.
posted by andrewpendleton at 6:11 PM on December 24, 2010
All of that said, my personal experience was that I did PHP work, and as I started to want to built more architecturally complex applications, I found PHP limiting. I personally think PHP encourages the formation of bad habits, and think that people that are serious about writing heavy-duty web code will probably run into the same frustrations I did, and feel compelled to expand their horizons and become acquainted with newer technologies. The fact that these people seem to have become complacent, well-educated though they may be, about the state of the art in their fields would make me nervous. Again, I don't want this to sound overly disparaging, particularly to PHP programmers; I don't think every web programmer should know Ruby. My Ruby skills are pretty awful. But "barely even heard of Ruby" makes me think they don't follow what's going on in web programming at all, and AJAX programming is complicated and fundamentally different from all-server-side work; it takes effort and experience to get good at it.
I'm not really sure if that answers your question. I guess I'd sum up by agreeing with them that in general, learning new languages is pretty easy if your foundation is solid, but learning whole new ways of tackling problems is hard, and I think you're right to be concerned about that, here, though it's quite possible that they'd do a great job.
posted by andrewpendleton at 6:11 PM on December 24, 2010
Since web backends don't usually involve complicated data structures or algorithms, backend coding experience primarily matters for how quickly the site gets built and how easily the functionality can be extended later. So the problem isn't that they're PHP coders. If that's all it was, you could ask them to use a PHP MVC framework like Symfony, Cake, CodeIgniter, or Zend to do a lot of what Rails, Django, and so on do to help with rapid development and good code organization. The problem is they're not already telling you about those options, and you should reasonably be concerned that they simply don't know how best to organize their own code.
Moreover, it sounds like what you really want are good frontend developers, at least as experienced with graphic design and Javascript--particularly libraries like jQuery or YUI or MooTools--as they are with coding the backend.
It's possible they can do that. But if they can't show you a site where they've done it, pass.
posted by Monsieur Caution at 6:16 PM on December 24, 2010
Moreover, it sounds like what you really want are good frontend developers, at least as experienced with graphic design and Javascript--particularly libraries like jQuery or YUI or MooTools--as they are with coding the backend.
It's possible they can do that. But if they can't show you a site where they've done it, pass.
posted by Monsieur Caution at 6:16 PM on December 24, 2010
Response by poster: Thanks all for the great thoughtful stuff.
that's all it was, you could ask them to use a PHP MVC framework like Symfony, Cake, CodeIgniter, or Zend to do a lot of what Rails, Django, and so on do to help with rapid development and good code organization. The problem is they're not already telling you about those options, and you should reasonably be concerned that they simply don't know how best to organize their own code.
We're not at that stage yet. We're still evaluating whether we should hire these guys (this posting was one step), and haven't even filled in all the details about the project yet. So that's no fault on their end.
Agreed on hiring a good frontend dev (we'd had that in mind, though were unsure that would mitigate the somewhat moldy knowledge of the backend guys). That's a shadowy world, though when last I heard, there were a lot of them sadly unemployed in this recession, a great opportunity for me. What is the proper job description for someone like that?
posted by Quisp Lover at 7:17 PM on December 24, 2010
that's all it was, you could ask them to use a PHP MVC framework like Symfony, Cake, CodeIgniter, or Zend to do a lot of what Rails, Django, and so on do to help with rapid development and good code organization. The problem is they're not already telling you about those options, and you should reasonably be concerned that they simply don't know how best to organize their own code.
We're not at that stage yet. We're still evaluating whether we should hire these guys (this posting was one step), and haven't even filled in all the details about the project yet. So that's no fault on their end.
Agreed on hiring a good frontend dev (we'd had that in mind, though were unsure that would mitigate the somewhat moldy knowledge of the backend guys). That's a shadowy world, though when last I heard, there were a lot of them sadly unemployed in this recession, a great opportunity for me. What is the proper job description for someone like that?
posted by Quisp Lover at 7:17 PM on December 24, 2010
Pluses:
+ Knowing C++ well makes every other language seem much easier.
+ C++ and PHP are both C-derived procedural languages.
Minus:
- Each language, despite common derivation, has its own idioms. Not knowing those idioms means taking more time to do things, in a way that's "unnatural" in the new language, and less understandable to language natives who might later have to reaqd the code.
It's like a native French speaker telling you he "I like the car blue"; you can understand it, but you mentally have to move the adjective.
C (and C++), for example, allow this construct because they support implicit conversion and short-circuit evaluation: if( p && p->next) ...
Java allows (but discourages) this: foo( a.functionWithSideEffect(), a.guaranteedToAppearToBeCalledAfterSideEffect() ); while that same thing is undefined behavior in C and C++.
PHP programmers will know what this common idiom means, even smart non-PHP programmers will have to double-check that this works for all possible values of $arrayName: if ( count($arrayName) ). But C and C++ programmers will probably find this one easy to figure out; Java and C# programmers less so: $func = 'foo'; $func($bar);
I've been having a lot of not-joy the last several months trying to get C# programmers to do Java. Even though C# and Java are very similar, there are nearly constant complaints that that Java doesn't have this or that. And of course, they don't even know about various Java libraries and frameworks, so often things will be done "the hard way".
Expect much more of that for C++ to PHP: while I'm admittedly biased to C++, the PHP I've done left me constantly thinking "this (or that) is a bad idea". (And frankly, I'd never advise writing "real" software in PHP; I think PHP, as a language is ad-hoc and hacked together. There are those would would similarly complain about C++, because of it's backward compatibility; those are people who never read Stroustrup's D&E)
You risk spending a lot of time on getting used to new idioms, or even worse, trying to write PHP as if it were C++.
posted by orthogonality at 7:24 PM on December 24, 2010
+ Knowing C++ well makes every other language seem much easier.
+ C++ and PHP are both C-derived procedural languages.
Minus:
- Each language, despite common derivation, has its own idioms. Not knowing those idioms means taking more time to do things, in a way that's "unnatural" in the new language, and less understandable to language natives who might later have to reaqd the code.
It's like a native French speaker telling you he "I like the car blue"; you can understand it, but you mentally have to move the adjective.
C (and C++), for example, allow this construct because they support implicit conversion and short-circuit evaluation: if( p && p->next) ...
Java allows (but discourages) this: foo( a.functionWithSideEffect(), a.guaranteedToAppearToBeCalledAfterSideEffect() ); while that same thing is undefined behavior in C and C++.
PHP programmers will know what this common idiom means, even smart non-PHP programmers will have to double-check that this works for all possible values of $arrayName: if ( count($arrayName) ). But C and C++ programmers will probably find this one easy to figure out; Java and C# programmers less so: $func = 'foo'; $func($bar);
I've been having a lot of not-joy the last several months trying to get C# programmers to do Java. Even though C# and Java are very similar, there are nearly constant complaints that that Java doesn't have this or that. And of course, they don't even know about various Java libraries and frameworks, so often things will be done "the hard way".
Expect much more of that for C++ to PHP: while I'm admittedly biased to C++, the PHP I've done left me constantly thinking "this (or that) is a bad idea". (And frankly, I'd never advise writing "real" software in PHP; I think PHP, as a language is ad-hoc and hacked together. There are those would would similarly complain about C++, because of it's backward compatibility; those are people who never read Stroustrup's D&E)
You risk spending a lot of time on getting used to new idioms, or even worse, trying to write PHP as if it were C++.
posted by orthogonality at 7:24 PM on December 24, 2010
Response by poster: sorry, correction:
"What is the proper job description for someone like that?"
I meant What is the proper job title for someone like that?
posted by Quisp Lover at 7:45 PM on December 24, 2010
"What is the proper job description for someone like that?"
I meant What is the proper job title for someone like that?
posted by Quisp Lover at 7:45 PM on December 24, 2010
Honestly, PHP programmers can be excellent, but—and this is about to sound harsh—the odds are against you. The best programmers can't be described as
Furthermore, PHP is not a good language, so that many of its habits and practices don't translate well into good code in other languages. At my workplace, I am currently dealing with a legacy pile of PHP. It, in all honesty, is a pile. There's no concept of code sequestration beyond the
At the very least, they should've brought up PHP frameworks in their interviews. They're not obscure, and they're basically necessary to hack PHP into something resembling a decent language.
Now, for people calling the other languages "newer" than PHP, that's a falsehood. PHP first appeared in 1995, Ruby in 1995, Java in 1995, and Python in 1991. Scala is the newest language I can think of that has a significant following in the web world; it appeared in 2003. These languages are just more powerful and advanced than PHP, which is, on the whole, a hideous agglomeration of splintered ideas and broken logic. It didn't even have namespaces until 2009.
posted by sonic meat machine at 7:51 PM on December 24, 2010 [3 favorites]
[name-of-language] programmers. I suspect that if you were looking at guys who are going to produce really good code, they would already have been working on Python, Ruby, Java, etc. frameworks in their spare time. Programming is one of those trades where an autodidact has a distinct advantage.Furthermore, PHP is not a good language, so that many of its habits and practices don't translate well into good code in other languages. At my workplace, I am currently dealing with a legacy pile of PHP. It, in all honesty, is a pile. There's no concept of code sequestration beyond the
include() function, there's no real use of functions beyond some 2002-era cut-and-paste MySQL utility functions, etc.At the very least, they should've brought up PHP frameworks in their interviews. They're not obscure, and they're basically necessary to hack PHP into something resembling a decent language.
Now, for people calling the other languages "newer" than PHP, that's a falsehood. PHP first appeared in 1995, Ruby in 1995, Java in 1995, and Python in 1991. Scala is the newest language I can think of that has a significant following in the web world; it appeared in 2003. These languages are just more powerful and advanced than PHP, which is, on the whole, a hideous agglomeration of splintered ideas and broken logic. It didn't even have namespaces until 2009.
posted by sonic meat machine at 7:51 PM on December 24, 2010 [3 favorites]
Oh, and you want a "user experience designer" or "information architect." These are the fluffiest of fluff titles, however, because there's no really accepted certification system for this area. Make sure your requirements are heavy on education or experience, so that you don't get an up-jumped graphic designer.
posted by sonic meat machine at 7:52 PM on December 24, 2010
posted by sonic meat machine at 7:52 PM on December 24, 2010
PHP is fine for making web applications. A lot of large sites use PHP with no problems.
In my view, the implementation language wouldn't be your problem with "moldy" developers---it would be their unfamiliarity with contemporary system architecture for making scalable web sites. Programming a web site is one thing, making it scale to hundreds or thousands or millions of users is another. That kind of knowledge is hard-won, and (unlike PHP) it isn't the kind of thing you can pick up in a couple of weeks.
If that kind of scaling is a concern (and really, it should be, for any but the most domain-specific web applications), then make sure your guys can give a credible answer to the question "how will you design the architecture of this site so it can serve thousands of users simultaneously?"
You might consider breaking up your hiring process into a couple of groups. Graphic design, interface/user experience design, HTML/CSS/Javascript coding, web application programming (PHP, Python, Java, Scala, etc.), database design, system architecture---these are all tasks that could potentially be taken on separately. Different companies and individuals will have competencies that span some of these categories, but very few are equipped to handle all of them.
posted by aparrish at 8:26 PM on December 24, 2010
In my view, the implementation language wouldn't be your problem with "moldy" developers---it would be their unfamiliarity with contemporary system architecture for making scalable web sites. Programming a web site is one thing, making it scale to hundreds or thousands or millions of users is another. That kind of knowledge is hard-won, and (unlike PHP) it isn't the kind of thing you can pick up in a couple of weeks.
If that kind of scaling is a concern (and really, it should be, for any but the most domain-specific web applications), then make sure your guys can give a credible answer to the question "how will you design the architecture of this site so it can serve thousands of users simultaneously?"
You might consider breaking up your hiring process into a couple of groups. Graphic design, interface/user experience design, HTML/CSS/Javascript coding, web application programming (PHP, Python, Java, Scala, etc.), database design, system architecture---these are all tasks that could potentially be taken on separately. Different companies and individuals will have competencies that span some of these categories, but very few are equipped to handle all of them.
posted by aparrish at 8:26 PM on December 24, 2010
We're not at that stage yet. We're still evaluating whether we should hire these guys (this posting was one step), and haven't even filled in all the details about the project yet.
You are doing it backwards. Trust me: this way lies madness.
Determine what you need before you start hiring, or else you are basically hiring people at random. Or you end up redefining the product based on the skills of whoever you've happened to hire. This rarely ends well. If you go to contract with a developer without a detailed list of functional requirements, and the first question out of their mouths isn't "please provide a detailed list of functional requirements," something is wrong.
I would not hire a bunch of "solid basis in C++" guys whose knowledge of the web is so out of date that they've "just barely heard of Ajax" to build a website of any complexity. If they're fast learners, let them learn on someone else's dime. Sure, any halfway competent developer can pick up another language if they need to -- that's just part of the game. But web development is often less about coding away in a single language than about getting the dozens of bits and pieces -- the database, the webserver, the clientside, the serverside, the template system, etc etc) working together efficiently. That requires a pretty broad base of knowledge.
However smart these guys are, if they don't know current practices they're not going to be equipped to make good build-or-buy decisions, aren't going to know what frameworks are available or when each might be appropriate, aren't going to be able to make informed decisions about how their code might handle under load or how to optimize load times or tune the webserver or, really, most of what web development *is*. Worse, they won't know that they don't know, and you'll probably end up paying them to reinvent the wheel.
posted by ook at 8:27 PM on December 24, 2010 [1 favorite]
You are doing it backwards. Trust me: this way lies madness.
Determine what you need before you start hiring, or else you are basically hiring people at random. Or you end up redefining the product based on the skills of whoever you've happened to hire. This rarely ends well. If you go to contract with a developer without a detailed list of functional requirements, and the first question out of their mouths isn't "please provide a detailed list of functional requirements," something is wrong.
I would not hire a bunch of "solid basis in C++" guys whose knowledge of the web is so out of date that they've "just barely heard of Ajax" to build a website of any complexity. If they're fast learners, let them learn on someone else's dime. Sure, any halfway competent developer can pick up another language if they need to -- that's just part of the game. But web development is often less about coding away in a single language than about getting the dozens of bits and pieces -- the database, the webserver, the clientside, the serverside, the template system, etc etc) working together efficiently. That requires a pretty broad base of knowledge.
However smart these guys are, if they don't know current practices they're not going to be equipped to make good build-or-buy decisions, aren't going to know what frameworks are available or when each might be appropriate, aren't going to be able to make informed decisions about how their code might handle under load or how to optimize load times or tune the webserver or, really, most of what web development *is*. Worse, they won't know that they don't know, and you'll probably end up paying them to reinvent the wheel.
posted by ook at 8:27 PM on December 24, 2010 [1 favorite]
Response by poster: ook and aparrish,
Fine advice. But I'm not in your league.
This isn't a funded enterprise or a corporation. It's a shoestring little startup that will develop via nights/weekends contribs by smart (if perhaps not perfectly suited) true-believers sharing equity, enthusiasm, and little more. The goal is ambitious, but there's no way we can do any of the things you describe. The advantage of this circumstance is that if a PHP guy is motivated to learn, and it takes a little longer, it's not "on my dime", per ook's warning. We don't have a hard deadline.
The project manager I like wanted to involve her two PHP friends, and they're up for it, but I needed to decide whether they'd wreck the project. After reading this thread, I'm leaning toward bringing on just one of them (to handle studly programming and system work, plus learn other stuff on the fly) and supplement by trying to wheedle/charm/beg a user experience/front end person to come on, as well. That seems like a decent compromise.
And if everyone's smart and sincere and willing to try to fill in their own gaps, it may all hang together. That's not the corporate way, but it's ok with me....
posted by Quisp Lover at 8:41 PM on December 24, 2010
Fine advice. But I'm not in your league.
This isn't a funded enterprise or a corporation. It's a shoestring little startup that will develop via nights/weekends contribs by smart (if perhaps not perfectly suited) true-believers sharing equity, enthusiasm, and little more. The goal is ambitious, but there's no way we can do any of the things you describe. The advantage of this circumstance is that if a PHP guy is motivated to learn, and it takes a little longer, it's not "on my dime", per ook's warning. We don't have a hard deadline.
The project manager I like wanted to involve her two PHP friends, and they're up for it, but I needed to decide whether they'd wreck the project. After reading this thread, I'm leaning toward bringing on just one of them (to handle studly programming and system work, plus learn other stuff on the fly) and supplement by trying to wheedle/charm/beg a user experience/front end person to come on, as well. That seems like a decent compromise.
And if everyone's smart and sincere and willing to try to fill in their own gaps, it may all hang together. That's not the corporate way, but it's ok with me....
posted by Quisp Lover at 8:41 PM on December 24, 2010
"...creating a bleeding edge, slick web site catering to a broad mainstream audience accustomed to snappy sleek magical usability?"
I just wanted to toss this in: sometimes sites like that bug the hell out of me so much that I avoid them altogether. The "bells and whistles" are so obnoxious that the content becomes difficult to enjoy, use, and absorb.
I think it's best to separate your project into at least four distinct parts, and usually these parts should be designated to four distinct people:
1) Front end, looks (esthetics)
2) Front end, structure (user interaction, intuitive navagation)
3) Back end, structure (file structures and scripting)
4) Back end, storage (database structure, adaptability, and resilience)
Due to costs, often times those four duties are performed by usually one person, or sometimes two people, but they are four distinctly different aspects of web design.
I doubt I'm telling you anything you don't know, but it's a good reminder, I think.
I'm starting a web biz myself, and I can see I'm going to have to hire those four people to make it work right, while my job will be "big picture" stuff. Overview, plan, and coordinate.
I know I'll get heckled, but a seasoned PHP/MySQL person can put together almost anything you'll need on the back end unless you're talking...I don't know...millions of users.
posted by rougy at 9:57 PM on December 24, 2010 [1 favorite]
I just wanted to toss this in: sometimes sites like that bug the hell out of me so much that I avoid them altogether. The "bells and whistles" are so obnoxious that the content becomes difficult to enjoy, use, and absorb.
I think it's best to separate your project into at least four distinct parts, and usually these parts should be designated to four distinct people:
1) Front end, looks (esthetics)
2) Front end, structure (user interaction, intuitive navagation)
3) Back end, structure (file structures and scripting)
4) Back end, storage (database structure, adaptability, and resilience)
Due to costs, often times those four duties are performed by usually one person, or sometimes two people, but they are four distinctly different aspects of web design.
I doubt I'm telling you anything you don't know, but it's a good reminder, I think.
I'm starting a web biz myself, and I can see I'm going to have to hire those four people to make it work right, while my job will be "big picture" stuff. Overview, plan, and coordinate.
I know I'll get heckled, but a seasoned PHP/MySQL person can put together almost anything you'll need on the back end unless you're talking...I don't know...millions of users.
posted by rougy at 9:57 PM on December 24, 2010 [1 favorite]
Oh, OK. If it's a sweat equity project on nights and weekends only, sure, getting a pro UX designer probably isn't on the map for you (truly good ones are rare), and accepting some risk is part of the deal. Ask your PHP guys to learn and use Symfony, jQuery, and 960 Grid (or reasonable equivalents they suggest) so that they don't use their CS skills to reinvent too many wheels. In fact, ask them not to write things that already exist, but rather to tell you how the idea might change to re-use existing functionality in Symfony or existing jQuery plug-ins, because those tools already do a *lot* and they probably do it better than your coders will know to do. And maybe, since they do have a CS background, they won't do too much WTF coding in that context, and you wind up with something that leverages the skills they do have as well as the cream of what's already been written for them to use.
posted by Monsieur Caution at 10:24 PM on December 24, 2010
posted by Monsieur Caution at 10:24 PM on December 24, 2010
Facebook still uses PHP on the frontend. In fact they recently released their own PHP compiler thing.
The "Cutting edge" stuff is all on the client side, so it doesn't matter what language the server code is done in. Your users aren't going to notice or care whether or not the site is coded in Ruby or Perl.
But that said, the big difference is in frameworks. It's not ruby you want it's Rails. Rails won't make the site better itself, but it will take care of the basic crap so that developers can spend more time making the site slicker and more awesome.
This is a good point. However.
Also, are you guys going to be paying these guys with money, or are you talking about 'bringing them on-board' as partners with "equity"?
posted by delmoi at 12:08 AM on December 25, 2010 [1 favorite]
The "Cutting edge" stuff is all on the client side, so it doesn't matter what language the server code is done in. Your users aren't going to notice or care whether or not the site is coded in Ruby or Perl.
But that said, the big difference is in frameworks. It's not ruby you want it's Rails. Rails won't make the site better itself, but it will take care of the basic crap so that developers can spend more time making the site slicker and more awesome.
The best programmers can't be described as [name-of-language] programmers.
This is a good point. However.
Also, are you guys going to be paying these guys with money, or are you talking about 'bringing them on-board' as partners with "equity"?
posted by delmoi at 12:08 AM on December 25, 2010 [1 favorite]
Response by poster: Monsieur Caution,
Yeah, what you are saying is essentially what they are saying. I'll ask, though, if they know Symfony/jQuery/960 Grid. And a big "yes" to not reinventing wheels. One reason their narrow isolation worries me is that they'll probably need to do more searching around for prior art than actual coding, whereas someone more slick and tapped in might know the options off the top of her/his head.
Delmoi, I did NOT know that about Facebook. That really changed my perspective, thanks. I'm a bit skewed, having spent lots of time around AJAX/Rails hotshots who gave the impression that anything really slick and fast and magical stemmed from that.
This project not have tons of bells and whistles. I just want the software to be Twitter/Facebook transparent, easy, responsive, and (seemingly) robust (e.g. user will see a window with various active components, and can hit "make this go away" for each component, which must vanish instantly without a window redraw....lots of that sort of thing, which is AJAX, no?).
The main guy I'm talking to does specifically call himself a PHP programmer. This made me nervous (which is why I posted my question), and you all seem to confirm. But by all accounts, he was extraordinarily fast and smart and agile in doing everythign called upon in his former web dev gig, however.
I'd rather not get into the compensation/equity discussion, because the situation is a bit complicated and unique and there are unusual extenuating reasons why people might especially want to work for equity alone (i.e. sweat equity). But, yes, that's what it amounts to. And we'll structure the vesting carefully so everyone gets something for their work, but drop-outs don't do as well as stick-arounds.
posted by Quisp Lover at 7:12 AM on December 25, 2010
Yeah, what you are saying is essentially what they are saying. I'll ask, though, if they know Symfony/jQuery/960 Grid. And a big "yes" to not reinventing wheels. One reason their narrow isolation worries me is that they'll probably need to do more searching around for prior art than actual coding, whereas someone more slick and tapped in might know the options off the top of her/his head.
Delmoi, I did NOT know that about Facebook. That really changed my perspective, thanks. I'm a bit skewed, having spent lots of time around AJAX/Rails hotshots who gave the impression that anything really slick and fast and magical stemmed from that.
This project not have tons of bells and whistles. I just want the software to be Twitter/Facebook transparent, easy, responsive, and (seemingly) robust (e.g. user will see a window with various active components, and can hit "make this go away" for each component, which must vanish instantly without a window redraw....lots of that sort of thing, which is AJAX, no?).
The main guy I'm talking to does specifically call himself a PHP programmer. This made me nervous (which is why I posted my question), and you all seem to confirm. But by all accounts, he was extraordinarily fast and smart and agile in doing everythign called upon in his former web dev gig, however.
I'd rather not get into the compensation/equity discussion, because the situation is a bit complicated and unique and there are unusual extenuating reasons why people might especially want to work for equity alone (i.e. sweat equity). But, yes, that's what it amounts to. And we'll structure the vesting carefully so everyone gets something for their work, but drop-outs don't do as well as stick-arounds.
posted by Quisp Lover at 7:12 AM on December 25, 2010
Response by poster: Would it be good etiquette to mark every response as "favorite"? I see no bad ones....
posted by Quisp Lover at 7:36 AM on December 25, 2010
posted by Quisp Lover at 7:36 AM on December 25, 2010
That really changed my perspective, thanks. I'm a bit skewed, having spent lots of time around AJAX/Rails hotshots who gave the impression that anything really slick and fast and magical stemmed from that.*Rolls Eyes*
The "Slickness" of a site really stems from the front-end. It's the Javascript, CSS and interface design stuff that matters, not what it's built in. Twitter was originally done in rails but had to switch to something else because it couldn't scale. One thing you should definitely look for is someone who knows jQuery. Even if they don't use it they should at least be familiar with it.
Also, they should have some example sites you can look at and see for yourself if they look slick.
Almost all web coding is just moving stuff from a database to a to a browser. In some cases you might be 'moving' stuff from a more complex system but that won't (or shouldn't) be written in PHP itself. But C++ would be fine for that if you're dealing with data that doesn't fit nicely in a MySQL database.
posted by delmoi at 12:17 PM on December 25, 2010
Seconding that php vs rails seems to have very little to do with what you are asking. Delmoi is correct that you are really looking at the wrong tier if you want something ajaxy. I'm pretty sure rails and php can both the kind of stuff you would want , namely rest service that return json that can be used by the JavaScript running on the client.
Rails is old school anyway. They should be on node.js :)
posted by Ad hominem at 2:24 PM on December 25, 2010
Rails is old school anyway. They should be on node.js :)
posted by Ad hominem at 2:24 PM on December 25, 2010
I'm a Rails hotshot. Yes, you might have very little money, but take that money and give as much as possible to a great designer/UX person. A great dev can blah blah blah a site together in no time, but because design and UX aren't the primary focus of our profession we'll rarely if ever be as good as a dedicated UX/design person. You only need them once, mostly, so think of it as a one time fee.
Any competent backend developer who is PASSINGLY familiar with jquery, which your devs ABSOLUTELY must be, can take what a designer gives you and translate it into what you are looking to build.
People who don't put money into design up front are doing it very wrong. The backend is the easy part.
posted by soma lkzx at 7:02 PM on December 25, 2010
Any competent backend developer who is PASSINGLY familiar with jquery, which your devs ABSOLUTELY must be, can take what a designer gives you and translate it into what you are looking to build.
People who don't put money into design up front are doing it very wrong. The backend is the easy part.
posted by soma lkzx at 7:02 PM on December 25, 2010
Response by poster: thanks, soma lkzx. I have a really really great designer. But he's a traditional designer, not a user experience guy. No coding, etc. So I guess we need someone to be the layer between him and the PHP guys.
And I like that this is a one-time expense. I can keep the trad designer as an equity partner to keep chipping in bits of design, but I do have budget for one spasm of work by the UX.
Any reccos?
posted by Quisp Lover at 9:50 AM on December 26, 2010
And I like that this is a one-time expense. I can keep the trad designer as an equity partner to keep chipping in bits of design, but I do have budget for one spasm of work by the UX.
Any reccos?
posted by Quisp Lover at 9:50 AM on December 26, 2010
so you are saying they don't know enough buzzwords? dont be a code snob, if they can put together a good documented functional site for the price you want, that should be enough. 1999 php/asp (+ something like jquery if you need real time db stuff) will do almost everything you are probably thinking of, its just that the presentation is key.
be sure to document your requirements well, then go over your requirements again, and then have an old senile person with a thick regional accent read them back to you, and also have specific examples of the user experience you want. make sure they know what your requirements mean. dont assume anyone is going to just 'put something in' if its not documented. Look at examples of what they have done. suggesting they work in cake/symphony/etc framework is alright, but keep in mind someone will need to keep that updated as well.
also, i'd caution against thinking of this as a one time deal, the second actual humans start using your site, they'll find completely ridiculous ways to get confused, and they'll navigate the site in the worst possible ways, you'll probably want to be able to adapt to that in a measured non-kneejerk way.
posted by yeahyeahyeahwhoo at 3:06 PM on December 26, 2010
be sure to document your requirements well, then go over your requirements again, and then have an old senile person with a thick regional accent read them back to you, and also have specific examples of the user experience you want. make sure they know what your requirements mean. dont assume anyone is going to just 'put something in' if its not documented. Look at examples of what they have done. suggesting they work in cake/symphony/etc framework is alright, but keep in mind someone will need to keep that updated as well.
also, i'd caution against thinking of this as a one time deal, the second actual humans start using your site, they'll find completely ridiculous ways to get confused, and they'll navigate the site in the worst possible ways, you'll probably want to be able to adapt to that in a measured non-kneejerk way.
posted by yeahyeahyeahwhoo at 3:06 PM on December 26, 2010
This thread is closed to new comments.
Otherwise you are going to have Ruby & AJAX-based "mold."
Source: Work on these things all the time.
posted by circular at 6:01 PM on December 24, 2010