Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

I've been programming (obsessively) since I was 12. I am fairly knowledgeable across the spectrum of languages out there, from assembly, to C++, to Javascript, to Haskell, Lisp, and Qi. But all of my projects have been by myself.

I got my degree in chemical engineering, not CS or computer engineering, but for the first time this fall I'll be working on a large programming project with other people, and I have no clue how to prepare. I've been using Windows all of my life, but this project is going to be very unix-y, so I purchased a Mac recently in the hopes of familiarizing myself with the environment.

I was fortunate to participate in a hackathon with some friends this past year -- both CS majors -- and excitingly enough, we won. But I realized as I worked with them that their workflow was very different from mine. They used Git for version control. I had never used it at the time, but I've since learned all that I can about it. They also used a lot of frameworks and libraries. I had to learn what Rails was pretty much overnight for the hackathon (on the other hand, they didn't know what lexical scoping or closures were). All of our code worked well, but they didn't understand mine, and I didn't understand theirs.

I hear references to things that real programmers do on a daily basis -- unit testing, code reviews, but I only have the vaguest sense of what these are. I normally don't have many bugs in my little projects, so I have never needed a bug tracking system or tests for them.

And the last thing is that it takes me a long time to understand other people's code. Variable naming conventions (that vary with each new language) are difficult (__mzkwpSomRidicAbbrev), and I find the loose coupling difficult. That's not to say I don't loosely couple things -- I think I'm quite good at it for my own work, but when I download something like the Linux kernel or the Chromium source code to look at it, I spend hours trying to figure out how all of these oddly named directories and files connect. It's a programming sin to reinvent the wheel, but I often find it's just quicker to write up the functionality myself than to spend hours dissecting some library.

Obviously, people who do this for a living don't have these problems, and I'll need to get to that point myself.

Question: What are some steps that I can take to begin "integrating" with everyone else?

Thanks!

share|improve this question
    
I'd say the first step is to study programming so you can at least speak the same language. –  Rig Jul 6 '12 at 4:51
    
Isn't the question more about how you will integrate on a project with a larger codebase than you're used to? –  Baboon Jul 6 '12 at 9:30
3  
"... this project is going to be very unix-y, so I purchased a Mac ..." Have I misunderstood something, or is this a typo? –  Stuart Pegg Jul 6 '12 at 10:16
4  
@StuartPegg: Mac OS X is a *nix, complete with a built in shell terminal, although I'd recommend installing MacPorts on it if you want to use the *nix side heavily. –  Dave Sherohman Jul 6 '12 at 10:53
1  
I remember once in American Pie film there say "you don't score until you score". So like tGilani said Become part of a team. :) –  asakura89 Jul 6 '12 at 11:26

7 Answers 7

I think you are getting a bit both anxious and excited at working for a group.

None of us learned working in a group or team from books or was given any baby steps or "Dummies Guide to Working in Teams".

We just learn working WITH groups by working IN groups.

Everything that you heard about professional programmers, will fall into place gradually as you work in team.. You'll learn about all of them one by one like version controlling, unit testing etc.

To me, the bottom line is

Become part of a team.

share|improve this answer

I'm going to pick out some of your sentences and make a couple of general points:

(on the other hand, they didn't know what lexical scoping or closures were). All of our code worked well, but they didn't understand mine, and I didn't understand theirs.

...

I hear references to things that real programmers do on a daily basis -- unit testing, code reviews, but I only have the vaguest sense of what these are. I normally don't have many bugs in my little projects, so I have never needed a bug tracking system or tests for them.

...

I spend hours trying to figure out how all of these oddly named directories and files connect ... I often find it's just quicker to write up the functionality myself than to spend hours dissecting some library.

I think the biggest single thing that you are going to need to learn is this:

For a given standard of developer ability, a team of n developers does less than n times the work that one of the developers could do alone - but they do still do more than any one person could.

The reason is simple: when working with other people, you must spend some of your time exchanging information with these other people; whereas when working alone, the information exchange all takes place in your head. Which naturally is quicker.

The other important thing is:

Some of your co-workers will be less able than you, certainly in some skills; some will even be less able than you in all skills

With these two ideas in mind, everything I've quoted above makes sense. Lots of people don't 'get' closures.The testing and code reviews are to ensure quality and decrease risk when code is bring produced by a group of people of mixed ability. The bug tracking is because when you produce sufficiently large systems, bugs are inevitable. And the endless libraries with their conventions are because without conventions there is just too much code to learn or write it afresh every time you need it.

Really, I think the only way to learn how to work in a team is to actually do it; but hopefully the above will help you mentally prepare. Good luck!

share|improve this answer

The most efficient way is to become part of a team.

Joining a team might seem difficult, as I understand that you are not part of a team yet, like many students, and many people whose job is to work with no other developers around.

I would recommend you to take part in an open-source project that is very active and favours frequent communication on modern open-to-all channels (issue tracker, mailing list, wiki, etc). Open communication is important because you will probably start by observing how other people interact, so avoid projects that rely on email between core developers, or non-archived IRC.

Prefer a project that seems welcoming, with several quite-frequent contributors, rather than a project with 1 person who does everything. Also, prefer projects where anybody is allowed to touch to everything (rather than each developer having their delimited area), because it is more fun and offers more opportunities for communication.

Shameless plug: you are very welcome here!

share|improve this answer

I won't reiterate what everybody else has already said to the effect of "just do it", but I'll add an additional point I've not seen mentioned: a good manager will really help you integrate in to the team.

While you may have all the right stuff about you for the programming part of the job, you could be missing some of the more inter-personal and software development related stuff. A good manager will guide you in to the teams practices (both in soft skills and hard skills) to help you gel, and will also hopefully tell you if you've done, or do, something that is in opposition to those practices; because you can't fix something you don't know is broken.

share|improve this answer

Another tip I would like to give you is that no two teams are the same, and that even an existing team will change when one or more people join it.

A team originates from the interaction of individuals that get to know each other and try to understand how to work together until they find a common way (see e.g. Tuckman's stages of group development).

So my advice would be not to try and find answers to your questions now, but to see what happens when you actually start working in the new team. Some of your issues might be considered non-issues by your colleagues, some others will be considered relevant and you will have the possibility to discuss them together or even promote your own view on the topic. And finally, you will probably also deal with aspects you had not thought of.

I agree with ElYusubov that you need a lot of patience and give yourself and the new colleagues some team to learn to work together until you become a team. If you practice some team sport you should have experienced this already.

One final comment on spending a lot of time understanding other people's code. Working in a team means you are going to work on someone else's code and other developers are going to work on your code. Sometimes the code is too complex to be rewritten from scratch. A typical solution is to ask the original developer to review your changes, so that you have a bit more confidence that you are not breaking anything in their code.

This was for me a big leap in the transition from a solo programmer to a team programmer: you work on code you only partially understand and you have to get used to it. This involves a lot more communication with your colleagues, a lot of respect (yes, the have weird naming conventions for their variables, so what?) and mutual trust (even though they have a different coding style, I know they deliver working code).

share|improve this answer

Being a good team member means communicate fearlessly, trust your colleges and overcome obstacles in a project as a team and deliver project as a team.

It takes time, takes patient and requires to learn in order to feel comfortable and confident as a programmer. It is also true that NOT every programmer is a good Team player, and team players share their success and learn lessons from failures.

It would be helpful to highlight some characters of good team member.

a) Good team member is a person who is goal-oriented instead of self-oriented.

b) Qualities: thinking more about big picture rather than self-satisfaction. This is key point. All other qualities (like reliability, constructive communication,) inherits from this one

c) How to improve: Try to qualify how have you interact with your team during the day, define good and bad points, pay attention to them during next meetings. Also, try to Look at Team decisions from many angles. Place yourself on the other's roles, think how you can affect others work.

share|improve this answer

First, congratulations on being the kind of person who seems to genuinely enjoy programming. However, programming isn't the beginning and end of delivering useful systems. You are going to have a challenge in front of you and it's going to be up to you whether you go back to hobby programs or go on to a career where you can do what you love and get paid for it.

You are disadvantaged in that you do not have an education in building software. In that education there are several things taught (not just how to program) that for CS grads and experienced software developers will be second nature. Not that it comes up often in the work place (although it did for me, once) but NP-hard is an example of a term they may understand and you might not. You probably lack any background in formal theory behind computation, but that's okay, as long as you're willing to learn about it. Maybe a master's in CS in your future? It sounds like some of your code may be idiomatic, in the sense that you have a style of programming that seems clear to you, but not to others. Pay attention in code reviews and be willing to accept criticism and learn. This is going to take work, and you may get frustrated, but stick with it.

What you have going for your is priceless. You genuinely appear to enjoy programming. I think you'll also enjoy the other aspects of developing systems, such as design, architecture, testing, optimization, etc. Programming is one part of the puzzle and you will have to learn other skills to be a software developer. Hackathons aside, a lot of the business involves communication, learning from each other, listening, and planning. I've worked with many people who are CS grads and liked software development more than selling cars or painting houses, but didn't have a real love for it.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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