Professional Coding: What to Expect?

Life as a professional developer.

I was inspired to create this site after reading a thread on the ArsTechnica forum; it is a collection of answers provided freely by professional developers, I have merely collated and organised the responses.

The question on the Ars forums that inspired this site.

If you have an answer that you would like to submit, just fork the site and submit a pull request.

The Question

I graduated recently and just got a job in a big software company (red one, hates API's ;) ). I was wondering, what should I expect upon starting my life in this strange, new, corporate world. Any tips anybody wishes somebody told them when they were starting?

I've grouped the selected responses below, to read the entire thread unedited, please visit the ArsTechnica forums. If you have any suggestions, just fork the site and submit a pull request.

Your first year

It will take you some time to adjust to coding for eight hours a day.

You will learn more about the practical side of software development during your first month on the job than you did in your entire degree program.

As a fresh out you are going to be given a bunch of tedious maintenance tasks (at least that's what you should be getting). This is the apprenticeship period, and it's to get you familiar with the code base and any processes and procedures.

You're not going to spend all day everyday coding - you'll be going to meetings, training, reading (or, if you're me, ignoring) lots and lots and lots and lots of emails, troubleshooting, and coordinating with other teams.

It will take you some time to adjust to coding for eight hours a day.

Your skill?

After a year or two, you will think you know everything. You are wrong.

You probably have some idea of where you stand in the world. How your aptitude stacks up against everyone else. Throw those ideas away. Until now, you've been in ponds populated by beginners.

You'll be working with people who have forgotten more than you've ever learned. Dunning Kruger is a thing, especially in individuals who don't understand just how big the global pond is.

Best practice

Unit testing is hard but worth it.

Working with others

Learn to communicate, both verbally and in writing. The better you are at this, the better your job prospects are.

If you don't know something, ask. I don't know how many times I've come across people that don't ask questions out of a fear of being called stupid or some other nonsense.

General rules

Learn how to ask good questions.
Learn how to realise you do not know things.
Yes, that is a skill.
Learn to self-learn.
Learn to JIT your learning.

There are fads in programming. Learn the new stuff, but don't think it's the One True Way. It is not.

Life and career goals

Your five-year plan needs to include determining if you have the capability to manage people and if you are interested in managing people. If you can manage, and want to manage, work toward management. If you can't or won't, you need to specialise in something. Go deep into a technology or business vertical, learn to architect, whatever. You just need to know if your career will aim toward management or if you will stay technical.

You should be able to figure out your long term goals within five years. If you are skilled at communication and putting the user first, consider the management path.

Start a project journal.

In this journal track every project. Some of the information you will know from the beginning of the project, some you will acquire during the project, some you will pick up later.

Here is a list of information to include to help you get started. As the years go by you will probably make adjustments to this list.

  • Project name
  • Start and end dates
  • Company
  • Client
  • Principal project members and the project members you were in direct contact with. Make a note of contact information for each.
  • Technology
  • Your role in the project
  • Make a note of anything that was interesting or different about the project. That could be the technology, infrastructure, process, etc. Follow up with a description and detail whether the difference helped or hurt the project.
  • For everything that went wrong in the project make a note, why it went wrong and how the team corrected it.
  • After the project is complete make a list of the lessons you learned on this project.

Anytime you hear updated information about the project make a note. For example, five years later you could learn that the client is still using the project – make a note of that. If you learn they increased revenue by 50% without adding any staff, then make a note of that.