What are your do's and don'ts for the first day on the job as a developer?

Question

I just got hired as a web developer for a marketing company (though they do lots of things, development is the bread and butter).

I'm a self taught developer with zero experience as a programmer other than my own freelance stuff. I've always been in the sales/consulting side of business, never been paid for being a geek really. And so I'm unfamiliar with the office environment of being a programer. What kinds of things are frowned upon? Encouraged? etc.

I hope some of these answers can be helpful to others in my shoes later, so I've marked it as a community wiki.

Answer 1

Do follow the code conventions of your peers. Use the same formatting, variable names, indentation, etc., even if their style clashes with your personal style. It should not be possible to tell which code is yours just by visual inspection.

Answer 2

Congrats on the job. It really depends on the office you work in, but I've found that most programmers are pretty relaxed. Look around, soak in what the other developers are doing and I'm sure you'll be able to fit right in.

Answer 3

Do use version control to manage your source code, HTML files, images, and so on. Please enter meaningful comments when checking in changes and check in regularly. Do not check in broken code.

Answer 4

Do not perform SQL queries directly on the production database server! You only have to forget the WHERE clause on a DELETE statement once...

Answer 5

Lets see:

• Figure out who the programmers are who are respected that are also friendly/receptive. Don't brown nose them or crowd them, but give them lots of respect and find ways to get teamed up with them
• Try to be realistic about your abilities when asked to do things, while at the same time showing a can-do attitude
• Work the hours that seem to be expected, no matter how ridiculous, until you get the cred needed to stand up for yourself when expectations are unreasonable
• If people appear to be grumpy or in lock down mode, leave them alone-- unless you really really need them, in which case, be firm and sure about the fact that you need them while asking for help

Answer 6

Setup your work environment as allows you to be as much productive as possible. If the company refuses to provide you the needed tools, buy them yourself.

I refuse to do anything without a double screen. My employer did not buy me a decent screen, so I bought it myself. You work 8 hours a day (in my case, 14 a day), you must be confortable in what you do.

Answer 7

Don't get caught trying to up your reputation on SO instead of working.

Answer 8

Don't ask "where's my desk?" - you may be disappointed.

Answer 9

I begun my first programming job about a month ago. Here have been my experiences:

Mine is a diverse work environment - we have people of all ages, races, and backgrounds. That said, nobody cares what I wear, sound or look like. As a programmer, your peers will judge you based on your code. If your code is good, they will like you. If your code is bad/broken/uncommented/buggy, people will notice.

So, as John said, try to follow the local coding style ("When in Rome..."), do your thing, and don't be afraid to ask questions. My experience has been that everyone is willing to help me as long as I have done the work to come up with the proper questions. This means doing a bit of Googling to narrow down the exact problem area, so that I can ask a short question and get a short answer, and we can both get back to work.

Answer 10

See also Tips for Junior Programmers.

Answer 11

Having watching some new programmers start at our company, here's some things that I can pass on:

• take time to learn the codebase (if applicable). Don't be afraid to ask questions, but make sure they're good ones! Odds are that your team is busy.
• learn how things 'flow' in your organization (technology and otherwise), and follow that structure. If you think you know a better way, don't bother making suggestions yet - you'll just piss people off.
• If your organization has bad processes (or none at all) try using your own (keep bugs in a spreadsheet, use to-do lists, set up your own repository, etc). If you can show results with your processes, perhaps you'll be able to formalize them across the company.
• Let the quality of your work speak for you - you have to earn your props!

Answer 12

Don't get into long discussions with other developers about refactoring, good vs bad code, test-driven development, and other buzzwords. Do some work first, and take your time to get to know people. There'll be time for such discussions later.

Answer 13

Don't work unreasonable hours at the beginning - it sets a precedent, and makes it really hard to cut back later. Don't slack off, but don't let yourself be bullied into extremely long hours.

Answer 14

Apply basic people skills. Some people seem to think that just because you are working around engineers all social skills no longer matter. If you ask those around you polite questions and then show a genuine, inquisitive interest in their responses, you'll be surprised how much they might appreciate you for that.

Don't be the new guy coming in all up on yourself. If somebody wants to know, they'll ask you. Make it a key priority to get to know everyone else first.

Oh, and have a sense of humor. It helps not only yourself but those around you.

Answer 15

Don't promise anything to users with-out talking to other developers first. Don't be afraid to say "I don't know, but I will try to find out.". Ask for help or ask questions before doing anything.

Answer 16

Since you have no professional experience, your reputation is everything.

*Work hard to establish your reputation as a superstar.
*Get things done fast, on time, and with high quality.

*Make sure every line of code that you check in is production ready, even if it means you have to stay late and work weekends.
*Be receptive to bug reports, sit down and listen to your customers and allow them to demonstrate the bugs. Don't blow off "the idiot user".

How bad do you really want it?

Answer 17

Some personal tips for you:

• Dont get caught playing flash games like Sagrario's Room Escape while working!
• Dont get caught working on your own private projects.
• Dont get caught on social networking sites.
• Dont get caught poking around your companies network servers.
• Dont get caught pen testing your companies network.
• Dont get caught reading web comics.
• Dont get caught building a tower out of soda cans.

Answer 18

Try no to guess about what you think is happening or what went wrong.

If you say "I'm not sure; It might be that the widgets are crinkled, but I need a bit longer to find out."

What the PHB hears "It's definitely the widgets, they're crinkled."

This could be a problem if the PHB then goes and spends the rest of the budget on new widgets.

If you don't know, be sure and emphasize it, and carefully omit any other information.

Answer 19

Don't flip the bozo bit on anyone. Don't dismiss anyone's contribution until you have a good deal of experience working with them.

Answer 20

Do NOT diss any programming language, platform, framework, operating system, etc on your first day of work. Programmers/Developers grow emotionally attached to these things.

Oh, there is one exception though... If you're a web developer, it's o.k to throw a couple of jabs @ IE6, but that's it!

Answer 21

Make sure that you familiarize yourself with the test environment for any of the systems on which you will be working on. Although you may become more of a daredevil later on it is imperative that you are able to familiarize yourself with the systems you will be working on in a controlled environment.

Answer 22

Setup the dev-box if it is not set up yet. Know who is your Tech lead, Project Manager Know what the work is being done as part of your project.

Answer 23

A few things that I've learned over the years:

1) Make sure that basic employment items are done. Does the employer do direct deposit? Are there forms for benefits? Are there time sheets to complete as a way of showing hours worked? Are there specific hours that you are expected to be in the office? Is there a dress code? Is there a general orientation program for you to get to know the company and corporate culture?

2) Discuss with your manager on which projects you will work, their current status, who are the team members of the project, etc. Also in here get the basics of the environment like what IDE is used, version control, common developer scripts that may be useful to know what they do like a nAnt script for example.

3) Map out the first week in terms of work items and initial objectives. There may be little to this but this is where you have those first impressions that can potentially be something you will live with for the rest of your life there.