Your first 30 days with a company can be nerve-wracking. Your boss is watching your performance, trying to decide if he made the right choice. Your co-workers are trying to learn if you’re going to be a helpful member of the team or just dead weight.

All that scrutiny gives you a golden opportunity to make a great impression.

Here’s four ways to make sure they’ll be glad to have you on board:

1) Go in Early

I know a lot of developers are night owls, but for the first 30 days, you should make an exception. Come in earlier than you normally would, but stay as late as everyone else does. You’ll show everyone you’re serious about the job, and aren’t afraid of work.

Even if you shift your schedule back to a normal one after the first 30 days, you’ve gone a long way to reassure your colleagues that you’re here to help them out.

2) Update Documentation

Was the system setup process well documented? If not, fix it. If documentation doesn’t exist yet for something you’re supposed to learn, create it. Your boss will notice, and you’ll be helping future employees get up and running faster.

3) Ask Questions

It’s one thing to learn how a company does things. It’s better to learn why they do them the way they do.

Look for areas where they don’t have any reason to back up how they’re doing something. If you can find a better way of doing it, pitch it to your boss. You’ll show him you care about the quality of your code, and you won’t have to step on anyone’s toes.

4) Stay Calm

You’re learning a lot of new things, and trying to stay productive at the same time. Don’t rush yourself. Most employers don’t expect their employees to start seriously contributing until they’ve put in 90 days. You’re going to be slower than normal, but that’s ok. Take the time to really learn all the nooks and crannies of the system you’ll be working in now, so you can contribute more later.

You’ve landed a good job. You negotiated a high salary, plenty of vacation days, and flexible work hours.

Congratulations. But don’t stop thinking about your career just yet. Now that you know your way around your current programming language, it’s time to learn another one.

Here’s why:

1) Languages go obsolete

Every programming language becomes obsolete at some point. COBOL isn’t used for new software anymore. Whatever language you’re using now will be obsolete, or at least on the downward trend, in 5-10 years. You don’t want to end up chained to one company (or worse, laid off from said company) with only an obsolete language on your resume.

Pick a language that looks to be on the upward curve, and learn it. Think of it as insurance against the future.

2) Languages express best practices

When someone creates a new programming language, they’re codifying a certain style of programming that they consider to be the best. After all, if Guido Van Rossum thought functional programming was the best style to work in, Python would have been a functional language.

One of the easiest ways to get deep into someone else’s ideas about the best way to program is to learn their language. Consider the learning experience a conversation you’re having with the language creator, trying to learn how they think programming should be done.

You’ll probably agree with them on some things, and disagree on others. Take the things you like – the parts of the language that make some best practices easier – and find ways to incorporate them in the language you’re currently using.

3) Languages don’t do everything well

Most of the general-purpose programming languages we’ve got are actually really good at just one or two things, and terrible at others. PHP is a great scripting language, but pushing it to express a complicated DSL leads to code that’s hard to read and painful to write.

Picking up a new language gives you a larger toolbox to draw on, so when it comes time to build that internal website, or reporting system, or distributed image processing software, you’ll be able to use the best language for the job.

4) Languages lead to jobs

This one almost goes without saying. You can’t land a Ruby job without learning some Ruby. You need to know C++ (or Objective-C) to work in the games industry. If you want to switch from web development to scientific computing, learning a new language is your best bet.

5) Languages teach programming fundamentals

Do you know what a monad is? How about S-expressions? Learning a language that’s radically different from what you normally work in (say, Haskell for Python devs) can teach you new programming concepts. You’ll learn new ways of thinking about programming, and new ways to approach traditional programming problems.

In the end, learning a new language (or several languages) is all part of becoming a mature, experienced developer. If you want to prepare for the future, expand your programming horizons, and keep a secret weapon (or two) in your dev toolbox, then you should learn a new language.

With the market for developers so fierce, we can afford to be a little more careful about where we work.

Over the years, I’ve interviewed at several companies. Whenever we got to the part of the interview where they asked what questions I had for them, I had plenty of stuff to ask about their tech stack, but not as much to ask about their working environment. Here are 10 questions I wish I’d asked at every interview:

1. How many hours a day do you require from your developers?

You’d be surprised how many places expect more than 40 hours. If they want you to work 45 or 50 hours a week, it’s best to know that up front, so you can negotiate an appropriate salary.

2. Do you allow working from home? How many of your developers work from home at least once a week?

A lot of companies will say they allow working from home. If they’re actually committed to it, though, they’ll be at least one or two developers taking advantage. If no one works from home, it’s because it’s discouraged by management, or they don’t really have the infrastructure (VPN, etc) in place.

3. What is the timetable for getting vested in shares?

A critical question for startups. They’ll usually ask you to take a lower salary in exchange for shares. But if those shares take 5 years to become vested, you’re looking at a long wait for a risky payoff. Do you really want to sacrifice money in the bank for that long? Best to make an informed choice.

4. Do you have “office hours” you like your developers to keep? What are those?

Most places are flexible, but have some sort of core hours they want you to keep. These may not fit your natural schedule (I’m personally a morning person, but I know a lot of developers that prefer to code at night).

5. What’s your leave policy? Are Vacation and Sick Days lumped together? How many do you give a year?

Several startups are offering unlimited leave these days. It makes sense; if you’re a salaried employee, paid per year to get a job done, does it matter how many sick days you took?

If they won’t go unlimited, consider bargaining for increased vacation instead of a higher salary. You’ll thank yourself later.

6. What’s your process for changing internal tools – e.g., if you were to change version control systems, how would you go about that?

Over the life of any piece of software, your tools are going to change. Is this dev team ready to handle that?

7. Do you allow developers any time to work on open source projects, or just projects of their own for the company?

You’re going to want to spend time on your own stuff, whether to try out a new language or keep your skills up to snuff. You’ll probably want at least some of that to be open source work, so you can show future employers your coding prowess without violating NDAs. If your new job won’t let you invest in yourself, will they pay for training or conferences to compensate?

8. What’s your employee review process? How often do you do employee reviews?

Ideal would be reviews after 30, 60, and 90 days for new employees, with everyone else getting evaluated every 6 months. You need the feedback an employee review can give, and they should want to hear from you.

9. Do you do code reviews? How often? What’s the process?

Feedback, feedback, feedback. One of the fastest ways to grow as a developer is to have other people read and comment on your code. Frequent code reviews mean the team is committed to getting better.

10. Do you do project reviews? What’s the process? Alternate: How is the performance of the dev team as a whole measured?

Another feedback question. Again, you’re trying to see if the team is serious about getting better.

These questions won’t cover everything, but they’re areas we developers often forget to check when looking for a new job.

Ripped from Code Complete:

People who preach software design as a disciplined activity spend considerable energy making us all feel guilty. We can never be structured enough or object-oriented enough to achieve nirvana in this lifetime. We all truck around a kind of original sin from having learned Basic at an impressionable age. But my bet is that most of us are better designers than the purists will ever acknowledge.

—P. J. Plauger