There’s a lot to be said about being the new guy at any tech company, depending on your level of experience you’ll either try your best to hit the ground running and make some mistakes along the way or you’ll become more reserved about what you do or say in order not to come off looking like an idiot.
Either way when I quit my government contract gig to come work for AMCO, I was looking for a challenge beyond what I was already doing at work or in my free time and got one. Here are some of my experiences learned over the last few weeks that might help you in whatever you do.
Be willing to use other technologies
I was once called a Linux Fascist by a co-worker but in no way does that imply that I have a problem with other operating systems. This is my first programming job when I’ve had to learn to use MacOS and though again I don’t mind it, I have already installed my OS of choice and will eventually make my way back to XMonad land.
The realities are that I needed to hit the ground running hard and get code out the door right away and the only way I could do it using the code I was given was to be willing to adjust my own work environment and speed. This is true about so many tools we use in development that sometimes we get comfortable and complacent and aren’t willing to try new things. I try to think of technology in terms of food, I’ll try anything at least once.
Be willing to be humble to the guys before you
Sometimes when you go into a project you may have ideas and things that you want to do right away, too many times I’ve ran into the folks that have immediately started criticizing other’s code and or methods of development within the first minute of being on a new project. I find that just listening at first and being willing to learn from the people that have been keeping the engine running this whole time will pay off dividends later.
You’ll still be able to implement your changes as you go, little by little adding the things that helps improve your development process on the project while ensuring confidence in those around you that you’re not going to botch up all their hard work. Criticizing for the sake of critiquing is sometimes used as a defense mechanism by some developers to appear smarter but it can hurt team cohesion.
Be willing to break stuff (so that you can make it better)
Probably the worst thing about being the new guy is when you break the build, there is a way to break code without breaking everything else and without pushing your breaks to everyone else. Figure out what that way is at your shop, but be willing to break stuff if you feel you need to so that you can put it back together in a better way. If you have tests to go off of then you’re lucky, if you don’t then you’ll have to be more careful and cautious and will probably have to write them yourself along the way.
In development you’re only as good as the mistakes you’ve already made, being able to tell someone that something doesn’t work only happens when you’ve already tried it so make mistakes quickly and then move on making sure that you’ve learned not just the if it works or not but also the why it didn’t work. In the end coding is a meritocracy whether some would like to admit it or not, past accomplishments might have gotten you the job but do nothing in the way of allowing you to keep it. Willingness is rare in the tech world, be willing and you’ll be just fine at your new gig.
