Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I am currently a programmer specialized in JavaScript (mostly jQuery) and CSS. In other words, my main work is always done on the client side. However, I do know basic stuff about MySQL and PHP.

Recently, a friend of mine who has very little knowledge of PHP (he is not a programmer but he wants to become one) told me that he would love to start a project together. I told him that I liked the project, so we started splitting the “tasks”. I thought it would be best if he specialized in database design & management (SQL) and also in PHP, so I would be strong “on the client side” and he would be strong “on the server side”.

However, I have many concerns with this approach. What would you do? It is not like I want all the work for myself, because even though I have much more experience, this guy has quite a lot of brains, and he will learn anything quite soon. That is why I thought he should learn SQL. How would you split the tasks? I am also afraid of the amount of work we will have since this project uses AJAX very much.


migration rejected from Jan 10 at 8:56

This question came from our site for professional and enthusiast programmers. Votes, comments, and answers are locked due to the question being closed here, but it may be eligible for editing and reopening on the site where it originated.

closed as too broad by MichaelT, Ixrec, GlenH7, Scant Roger, gnat Jan 10 at 8:56

There are either too many possible answers, or good answers would be too long for this format. Please add details to narrow the answer set or to isolate an issue that can be answered in a few paragraphs.If this question can be reworded to fit the rules in the help center, please edit the question.

Is specialization a must? To quote Heinlein, "A human being should be able to change a diaper, plan an invasion, butcher a hog, conn a ship, design a building, write a sonnet, balance accounts, build a wall, set a bone, comfort the dying, take orders, give orders, cooperate, act alone, solve equations, analyze a new problem, pitch manure, program a computer, cook a tasty meal, fight efficiently, die gallantly. Specialization is for insects." – maple_shaft Dec 21 '11 at 14:24
And yet, without specialization there would be no space flights, rovers on Mars, heart transplants, etc. Seeing nature come up with effective solutions and determining that we (humans) must be above that is a serious and catastrophic fallacy. – Dan McGrath Dec 21 '11 at 15:54
jack of all trades = master of none – BlackICE Dec 21 '11 at 16:43
@David Masters are overrated and are an evolutionary dead-end if the situation that mandated the need for a master has changed. A Jack-of-All-Trades is more flexible, has agility and is more likely to survive in a chaotic ever changing environment. Software needs and requirements are ever-changing so thus Agile is the best approach, the very antithesis of specialization. – maple_shaft Dec 22 '11 at 11:52
up vote 6 down vote accepted

It lowers your Bus Factor quite a lot. However, I guess that in a team of only two guys, the Bus Factor is pretty low no matter what you do.

The result will be better if you play to your existing strengths. Just don't make it too extreme.


The best programmers combine specialization, flexibility, and curiosity. So I advocate specialization but not ownership. The code is owned by the team. Your SQL guy probably should be tuning queries, but in a pinch anyone should be able to hack something together, and at the very least debug in every part of the project. The team is responsible for the whole project, and once one person starts refusing to work in module X because that's Bob's area and we'll have to wait for him you're screwed. That's just a recipe for blame and infighting -- Bob wrote module X and it sucks. I can't come up to speed on X, that's Bob's area. I only want to do Y now until time imemorial. Not only has your team become inflexible, they've drawn the borders for turf wars and infighting. They've become locked into defending the implementation of X and Y against all external ideas or improvements. No. let bob Bob be your resident expert in X know the code best... for now. But Bob better be able to work in Y and Z in a pinch, and maybe he'll apply something in X to Y or Z and suddenly become a resident expert in those areas two. You want to allow things to be fluid, not set in stone.


When our company started doing scrum we noticed a big shift towards less specialization. When you have two weeks to finish a story and the expert is booked solid, you don't have a choice. That doesn't mean agile mandates less specialization. If the specialist didn't happen to be overbooked, we would have carried on much the same. Scrum has a tendency to bring problems like that to the surface. We probably always had too much specialization, but just didn't notice it.

Therefore, what I recommend to you is to track, by whatever means works best for you, what is holding up delivering shippable software most often. If you are consistently finishing features together, wonderful. If one person is always jumping ahead to the next feature while the other is finishing up, you want to look at cross training. That doesn't mean you can't each have your strengths, just don't let them limit you.

+1 Excellent point. Agile makes the whole process more transparent so it does point out to management all the underlying problems that went unnoticed. Unfortunately too many companies are so shortsighted that they believe that Agile is the cause of these problems, thats when they bastardize it by making it more rigid and inflexible, or just outright abandon Agile altogether. Can't say I blame them too much though, the problems they uncover can sometimes be insurmountable. – maple_shaft Dec 22 '11 at 11:57

First, assigning an area to someone and saying that is where they should specialize is generally bad management.

Wherever possible, determine a persons natural affinity and allow them to learn and excel in that area. This is how you get the most out of someone.

Granted, this isn't always possible - but if you don't even attempt to find out... well, good luck to you, sir.

Second, organizing your tasks in logic blocks will enable your friend to pick up tasks that are related, which could reduce the amount of hand-holding you need to do, as well as reduce the time it takes for your friend to 'learn'. Still, take into account that initially this project might progress slower that if you did it yourself since you will need to guide your friend.

Third, be sure to review their work as you go. This will allow you to catch mistakes and bad habits early, before they become an ingrained habit. Conversely, get your friend to review your work as well. Not only might they find obvious stuff you missed (pink elephant in the code?), but it is also a way for your friend to learn what you are going and more about system as you go along. Win, win!


Depends on the project a lot. With web projects the frontend vs backend comes quite natural, but isn't a must. If there is much more work to be done on the server, it may become just a matter of time, that you should work on this part as well. In most cases the work on the server is more complicated, so if he is very smart, this should be his place. (Though the SQL part shouldn't be a main point, unless your database is very complicated)

And I don't see, why Ajax should influence the amount of work too much. With a library like jQuery Ajax becomes more or less another way to request some data from the server, nothing magical about this. (As long as you keep your HTML and CSS clean)


Not the answer you're looking for? Browse other questions tagged or ask your own question.