loading...

What do you wish you knew when starting your last gig?

rossbates profile image Ross Bates ・1 min read

There is a lot of content written from a dev manager's perspective on how to increase the chances of success for a new developer.

I'd like to flip the script for a moment and ask what are the things you as a developer need to know to be successful when starting a new job/project? What are the things you want to accomplish day one? Week one?

I suspect the answers are not going to be "I wish I had more standards documents to read".

Discussion

pic
Editor guide
Collapse
tracypholmes profile image
Tracy P Holmes

Editing this to provide a bit of clarification - I'm currently in school to up my developer game, but my current/most recent position is not a dev position.

  1. The consequences of not being able to devote a major portion of my time to learning to code. I went from being a full-time student to a part-time one, and I was not ready for the change.

  2. Because of where I work, when I (finally) finish, I don't actually want to see code because I'm learning at the same place I work.

  3. Helping others succeed at what you're trying to accomplish is hard. I have many down days.

  4. Make sure you have someone to keep you accountable! Accountability partners are important.

  5. Stay true to yourself, your mission, and your goals.

Collapse
ben profile image
Ben Halpern

Great takeaways Tracy.

Collapse
tracypholmes profile image
Collapse
lpasqualis profile image
Lorenzo Pasqualis
  1. Understand the specific domain concepts. Build a glossary of terms used in the company, and become very familiar with them.
  2. Understand who does what. Get a clear sense of who is responsible to do what, and start building a good relationship with your new co-workers.
  3. Listen carefully. Observe. Study.
  4. Understand what is expected of you, and exceed that expectation.
  5. Be enthusiastic, stop worrying and have fun.
Collapse
rossbates profile image
Ross Bates Author

Build a glossary of terms used in the company, and become very familiar with them.

I like this one a lot. It combines both practical knowledge & team culture into a format that's easy to digest.

At my last company any object that was "other" was called a 534. Why? Well because when we first seeded the database in week 1 of the company that was the index of the last entry in the table - the one we simply inserted by hand with the label "Other - Not Found". For the life of the company 534 was just shorthand for something you couldn't categorize.

Also, for those looking for a trip down memory lane. Let us not forget ESR's Jargon File.