How do I prepare myself for working with other programmers?

Question

I am a self-taught programmer. I'm reasonably intelligent and programming comes naturally(ish) to me, I just didn't do it at school or university. I've been working as a programmer on my own for many years now, and I think I need to get out into the real world and work with other programmers in more structured environments.

My concerns are:

• What shocks do I have awaiting me (what is the biggest hurdle I have to overcome)?
• How do I prepare myself to work with other programmers?
• What can I do to prepare myself for more rigid and structured programming environments?

EDIT:

I got the new job, so keep the tips coming, work starts July 12th

Answer 1

What will shock you: That you often know more about programming than people who have studied it. You even can drop names of famous CS guys and the ones with the degree don't even know Tanenbaum, Weizenbaum, Dijkstra, etc. Not all of them, but shockingly often.

Preparation: Be yourself. Don't be too much impressed. Be ready to learn and teach.

Rigid and structured? Let the real world surprise you.

Answer 2

• If you dont already drink coffee, learn to drink it
• Be ready for someone to take serious offense if you correct them, or suggest a better way of doing something
• Try to Be humble and admit your mistakes
• Recognize that programming is a terminaly entry-level thing so you must constantly be learning

Answer 3

The biggest shock that will await you: there's multiple ways to solve a problem, and other programmers will disagree with you. Learn to put your ego aside and debate on technical issues.

Second biggest shock: the world of professional programmers is much like the world in general. Some are good, some are bad, most are mediocre.

Answer 4

Be prepared for Pointy-Haired-Bosses!

Answer 5

One of the biggest shocks that I've had when moved from the home office to professional team was that I realized that I knew much less than them in area of software architecture. But it was a great guys, they learned every day and shared their knowledge between each other. I think it's not true for all teams.

Ah, and another shock was that our management was terrible. Simply saying, it was Anti-Peopleware management.

Answer 6

Realise that your actions will effect others now:

• if you check in broken code, others won't be able to compile their applications any more;
• if you break the build (unit tests start failing), others can't rely on existing code's behaviour;
• if you write poor quality code, others will have to pick up the pieces.

You need to do the best thing for the team, which isn't always the same as the thing that makes your life easiest.

Answer 7

You should have learned a lot from SO in terms of working with programmer virtually

Answer 8

The biggest hurdle you'll have to overcome is to let go of your ego. Us programmers have big egos, and learning to take constructive advice from others can be diffcult at first.

Once you open your mind to input from others, you'll find that just by communicating your problems to other developers you'll help yourself greatly understand how to solve them. Not to mention you can learn a lot from their experiences as well.

On the flip-side, don't let other egos offend you. Try to be amiable even when it obvious the other side is wrong. Try to solve all disagreements as diplomatically as possible. Communicating well with others is the basis of a good team-oriented environment.

In terms of getting yourself prepared, get familiar with source-versioining systems such as SVN, you'll probably be using it a lot.

Answer 9

So to put it bluntly you get to work harder than the other programmers, at least in the short term, sorry (I was in the same boat as you). To really be successful, you have to be able to communicate and think the same ways the other programmers do (You won't get this by reading Python Step By Step). I don't know how you taught yourself, but if it didn't include reading things about data structures, state systems, searching and sorting algorithms etc. you have some more reading to do. People with CS degrees have an advantage in this respect, they were forced to learn things like this. They may not remember it exactly, but they at least know what it is. My advice is to find a university that you have some respect for and find the books they read for the courses and go read (at least some) of those. Most universities are nice enough now to post the notes online for their courses too :)

The biggest shock you're probably going to have is that after all this work you've done to learn it, a fair amount of what you know isn't applied. This depends on where you work (places like MS and Google don't apply to this scenario). Most people are content with doing the basic amount over and over again. I have nothing against this but don't expect to see sublimely elegant solutions to a problem. A lot of what you will probably see is retrieving a record set and looping through it etc. Things like that. So why bother learning all that extra stuff? Because you are expected to know it, and the times that it comes into play, you really have to know it.

Answer 10

I'm in a similar position. I have been working as the sole developer at a tech startup for the past 2.5 years. And now we are finally in a position to take on 2 more developers, one for less "core" development and one proper core developer.

I have spent the past month setting up a Screwturn Wiki to document everything.

We tried an intern a few months ago and it was a total disaster. He had a CS degree and everything but he was just clueless. Couldn't communicate with me or anyone. That has scared me somewhat about what lay in wait for me in January. I am hoping that it is not going to be all like this.

I don't have an ego when it comes to programming or anything in general really. When I was at uni. getting my own CS degree I was always the one helping others with their code in the lab courses etc. Problem is when you've got often unachievable deadlines and pressure from the bosses of your own, your concerns for others tend to take a back seat. This obviously gives off a bad impression of you to the new guy(s). They think you don't give a toss about them. In reality I would love to help and chat to them about all sorts of tech subjects but just don't always have the time!

We've found a less core developer type guy but still looking for that properly good core developer. My worry at the moment is that the powers that be are going to push the more amateury developer into tasks he is not equipped or experienced in doing - and thus pollute the code base in critically important areas with bad code. I will be determined to prevent this from happening.

Why is it so hard to find client-server/enterprise architecture/winforms/C#.NET/threadpools/workflow engines/concurrency/design patterns developers?

Answer 11

If you've taught yourself from examples on the internet, you may be shocked to find out how many bad habits that you've picked up. You may also be shocked to find out how many are shared by your new colleagues.

Answer 12

Maybe not applicable to you if you've already been programming professionally for a while. But one thing I find with new programmers is that they often spend time doing things like making some user interface look pretty when its just for use as an internal tool.

Think about how your code will directly affect customers and focus your attention appropriately, this should impress your new colleagues.

Regarding the structure of code though, there are some practices regarding source code control you'll probably find different. It's very important to keep the checked-in code base compiling and working, you'll be hunted down if you break it. And, its important to add comments when you check-in so other people can figure out what the purpose of your changes is. Also, check in regularily. As soon as you've made changes and got the code into a consistent working state, check it in. Don't keep loads of code out for long periods of time because the code on your machine will fall behind that in source control, and you'll have trouble resolving differences with changes anybody else has made to the same code when you come to check it in.

Try to adopt the coding standard of the company, or the coding standard you find in a file you're working on. Forget about your own preferences for where the curly brackets go etc. Even if they've got a terrible coding practice (like hungarian! or something), realize that's just a matter of personal preference, and it's professional to swallow your pride in your own thought out conventions, and go with the groups standard.

I find its useful to write comments to say what each class is responsible for, and what its not responsible for. This might guide somebody who comes to modify your code so they don't try and stuff something in your class to break its encapsulation - hopefully.

You will find different programmers have very different skill levels. Try and learn from the good guys.

If you find the company has some really backward practices, like not unit testing or something that's fundamental to modern software development. Don't start changing them straight away, learn how they manage in their current system. When you do try and introduce the better practice you know about, don't get too disheartened when people don't adopt the better way. Old habits die hard, and it takes a lot of chipping away and doing it the right way yourself before people realize maybe your way is best.

You will learn company politics, and important project information next to the coffee machine. Chatting with colleagues at the coffee machine is productive! (well, don't spend all day there though).

If you do ask a colleague to explain how something works to you, write it down so you don't have to annoy them when you've forgotten a month later what they said. If they have a wiki set up... write new things you learn on there so that the knowledge is available to everybody. There are lots of things that will be in your colleagues heads, and its useful to get them into wiki form, it would help anybody else out who joins after you.

Answer 13

Speaking from experience from my first job in a real show - prepare to be humbled. Every self-taught programmer feels that they can walk into a shop for the first time and hit the ground running. It is extremely rare, and I have never experienced it or seen it, firsthand. There is more to development than just syntax and cranking out the kind of programs that you want to write - and it is going to take time to learn how to work within a team, how to take criticism, how to understand that you aren't going to win every battle, how to realize that opinions backed with experience within the organization will carry more weight, how the company's practices and policies impact your workflow, how business decisions will impact your decision making, how you will not be calling the shots when you walk in the door, and the list goes on and on...

Honestly, I do not think that there is anything that you can do to prepare for it. You need to go in and focus on being a part of the team. Being a team member and not causing friction will allow for you to learn, and eventually gain experience working in a team environment.

Answer 14

I've contracted with many different dev teams and these few rules helped me become part of the team:

[Less coffee is more coding - in a team setting]

[Always be positive]

[It's all about the customer]
Always say 'Thank you' to your testers. No one remembers a bug was found by testers, they only remembers customers that reported a bug you coded.

[Don't own your code] The code is the last thing to worry about. With so many tools to help with tuning, testing and cleaning your code and people reviewing your code, the best approach is to understand that the code is the property of the company your working for and not yours. Only YOU as a co-worker is what most people will remember.

[Everyone is correct when reading the future] There are (enter # of team members) correct answers to every design problem. Everyone has a correct answer because you haven't released the product yet - you don't know what is going to bite you after release. If you have an issue with another persons design, use the phase "Here is what concerns me about this section ..."

[Be an expert at your IDE] Team members can almost always agree on the fastest way an IDE can do a specific task. If you know these tricks, you can help the team out immediately that way. (A graceful way to tell everyone on the team that you know how to program without having to get into conceptual discussions with anyone.) If you know your tools, then you must be able to code.

[Be Pragmatic] - Don't talk about what needs to be done, model it or code it (best way to for developers to initially communicate)

[Know your teams SDLC and stick to it] If leadership has provided an Software development life cycle process, be the person that sticks to it. You never know when something is going to bite your team and it usually ends with "It looks like we didn't complete the [enter SDLC step] for that feature and we missed that issue"

Good luck!

Answer 15

Documentation is king. Comments are nice in code but make sure you make notes on your design choices and insure they are available for others to use. Also try to keep project documents up to date, you never know when you may get pulled onto another project or someone new will need to work on the code you've been writing. Having good documentation saves time since people don't need to learn everything from the code.

Answer 16

The Ten Commandments of Egoless Programming is an excellent list to keep in mind. Every one of those points is directly applicable to work with other programmers.

Thanks to Jeff for preserving the list; the original builder.com page is now gone. I first saw this article many years ago, and I believe it's improved how I deal with others.

Answer 17

The biggest hurdle would be seeing other people's code and passing your own off to them. There will likely be a culture wherever you work that you'll notice and probably pick up to some extent.

My suggestions for preparing yourself would include thinking about how you use version control, code structure(do you have files with thousands of lines of code or a way of naming classes), project management, code reviews and be prepared to learn how it is done wherever you work as some things, especially code reviews IMO, can vary dramatically.

I'm not sure that you'll find a rigid and structured environment, unless you are going into the military. Try to be prepared for the unexpected would be my last suggestion.

Answer 18

Be ready to deal with people who will do nothing (either on purpose or by accident) and then try to take credit for the work.

Answer 19

One thing that self-taught programmers often lack is language. I'm not talking about traditional progamming languages per se. I'm talking about the language of programming.

You will find it much easier to deal with other programmers and be able to smooth your integration if you already know the strict definition of things like "class", "object", "iterator", "inherit" and a whole bunch besides.

Answer 20

You need to get along with people at various levels of competency. 50% of the people you'll work with are below average. Learn from the good ones, and do your best to maintain professional working relationships with the rest.

In particular, you must resist the urge to refactor random bits of ugliness you encounter in the existing code base. Avoid fixing formatting or stylistic problems in code unless you're also making real functional changes. The person who created that ugly code may be in the cube next to you. Source control means people will find out if you're a habitual "code tweaker". It's not a reputation you want to acquire.

Answer 21

If you start work at a tech company, prepare yourself for a lot of reading the first week/month. You can't even approach real code before reading its documentation, the documentation of all the libraries they use, and probably even some theory or academic papers.