A New Developer's Tale
Thursday, Jul 23, 2015
Or how to be a good new hire and how to be good to your new hire.
Hi there, I’m Aaron. I’m the new guy - or more formally the new Lead Software Engineer - at InterExchange and I’m here to say this has been about the best first month at a company I’ve ever had.
I think what made starting at IEX so good probably boils down to a few things:
- Intake process was well defined and actioned
- I spent my first week at head office
- Engineering process was documented
- Typical engineering utilities were already scripted
- Pairing is the default though not manditory and not limited to engineers
- I started just preceding a crunch for the engineering team
- Embracing remote workers
I’m just going to break down how each point has been done, why it’s beneficial and most importantly how as a new hire you can make your starting process both smooth and beneficial in the future.
Intake Process Was Well Defined and Actioned
Put simply, a new employee has too many other things to come to grips with, asking them to also navigate their induction haphazardly is unfair and prone to error. At IEX however, the process was well defined and I knew who to talk to and what to do at all turns. Responsible people chased me in their area until the job was done.
Here I’m talking about filling in forms, 401K, pay information and so on. At many other places this gets sorted out as you go, there are always problems, often even important procedural documents like leave policies have had no thought given to them. This is just uncertainty a new employee should not have to go through.
I had a meeting with the person responsible for inducting new employees, they sent me a link to Google Drive with everything I needed or had to fill in. I sat with them to make sure it was all filled properly and meetings were scheduled to go through leave, 401k and insurance as I became eligible. It was all easy.
Also to any software developer that started a new job anywhere, anytime; there was a laptop ready when I arrived. I installed throughout the day while in meet and greets and planning about the next release and was ready to work almost straight away.
I Spent My First Week at Head Office
This is a remote position. I work in Colorado whilst the other members of the engineering team are primarily in New York whilst another member is in Florida. The value of spending your first week - or any time - with the rest of the team building a rapport and being able to talk about things more easily cannot be overestimated. I still learned a lot about the domain and people in the following couple of months but that first week accelerated the journey to being productive and comfortable.
The value of spending your first week - or any time - with the rest of the team building a rapport and being able to talk about things more easily cannot be overestimated.
As a new developer it also accelerates the journey to productivity and having applications working on your hardware. Tools not working, different versions of libraries, holes in documentation and so on are all easier to rectify with working examples next to you.
Engineering Process Was Documented
Organizations talk about people deploying on their first day but there is a lot of groundwork that’s required to allow this to happen. A large part of being able to do this is to have everything written down and better yet implemented into tools.
IEX has a deploy page that just worked. I could get a database backup straight away.
I used it and everything went better than expected.
I think I did a production deploy of two apps in the first couple of days. That’s my first time as a new developer that I could do that safe in the knowledge I wasn’t breaking something.
Outside of this dot files were already setup in a repo which included installing required libraries, tools and so on. My laptop was up and ready to work on quickly and my setup was similar to everyone else which makes it easy for anyone to jump on and show you around. It lets people pair between computers without the usual friction.
… no one has ever used the words ‘not my job’ and everyone is willing to jump on anything they’re capable of doing. That being said, knowing who is responsible for what part of the process makes things easier for the new guy
The team was already using Pivotal Tracker and there was a strong identification of actors within the engineering department which made it super simple to do my job. That being said no one has ever used the words ‘not my job’ and everyone is willing to jump on anything they’re capable of doing. That being said knowing who is responsible for what makes things easier for the new guy.
Typical Engineering Utilities Were Scripted
This continues on from process but everyone knows those
stupid essential things you need to do like get a production database, login to a staging machine, deploy code typically have idiosynchratic implementations at different places. That is if they have any utilities at all. Having database management, deployment and dot files all sorted, easily updatable and working from the outset just made a lot of the minutae of development a breeze. I was able to share my own faves to other developers within days of starting. This sounds like a low bar for happiness but it makes a huge difference.
Having database management, deployment and dot files all sorted, easily updatable and working from the outset just made a lot of the minutae of development a breeze.
Part way through this sprint Heroku updated the pg:backups add on and it took about half an hour to update these scripts and deploy them to all of our engineers. This is beautiful in comparison to any other place I’ve worked.
Pairing is the Default Though Not Essential and Not Limited to Engineers
We as engineers often think of pairing as something that only developers do but during this last month I’ve paired with developers on code, a PM on feature descriptions and stories and finally our COO on PDF templates. Outside of this we have PMs from different projects pairing on story generation and acceptance just to name another unusual pairing situation.
I’ve done pair programming before and I have to say this is my first positive experience with it. I think that comes down to the acceptance that pairing isn’t always optimal. We default to pairing but split and communicate heavily if pairing isn’t appropriate. If someone is in a lull or wants to jump off what they’re working on then they could pair just to take a break. Pairing has so many incarnations and uses here and I like it.
As a new hire and as the organization that hired you the quickest way to learn the ropes is to ping-pong pair with a person experienced in what you’re learning. It’s actually funny but nothing about that is breaking news, since the beginning of time the best way to learn was through mentoring.
I Started Just Preceding a Crunch
It seems counterintuitive but having just experienced starting at the beginning of a big crunch I would say that this was the best way for me to learn the ropes.
The benefits of starting at a crunch time are probably only realised because of the things I outlined above. If you have to deliver for acceptance but the process is flaky or difficult to navigate then it might (definitely would) be a different story. That being said I had no problems writing tests, implementing features and deploying my code to acceptance and production.
I had to come in and deliver features whilst coming to grips with the domain we’re working in. Not being distracted away from this now leaves me in a place where I know a lot of the gnarly code (which is working just fine) but have a really good understanding of the domain.
It can be distracting to start working in a new code base and quite often you see new developers boy scouting their way through only to be leaving breakage in their midst. I had to come in and deliver features whilst coming to grips with the domain we’re working in. Not being distracted away from this now leaves me in a place where I know a lot of the gnarly code (which is working just fine) but have a really good understanding of the domain. I could’ve easily focussed on fixing code without truly understanding the domain. Fixing code without domain understanding is a fools’ game.
Embracing Remote Work
I’m not the first remote worker IEX has but I’m the first remote engineer so there was some trepidation about whether it would work. Let’s just say that it did. I think everyone has been really happy at how we’ve delivered.
Embracing remote work is a two way street. As the remote worker I would say you need to offer flexibility, especially if you’re in a different timezone. As the employer I would say you need to offer flexibility, especially if you’re in a different timezone.
With that out of the way the most important part of any relationship is trust. As the new hire I knew I’d need to put in a few extra hours here and there to show that I’m engaged and want to go the extra mile. The other side to this is that this is repaid by your employer in time off and praise. I worked probably an extra day or so of hours in the past 2 months to get things over the line or improve process and in return I left early as required or started a little late a few times.
I’ve had more early days, granted time off and praise for a good job in my first 2 months at IEX than I had in 4 years at my previous job. This isn’t a special case for remote workers but the way I’m treated is no different to anyone else in the organisation.
As far as tooling to make this really work this is what we’ve been using:
- Slack for text communication
- ScreenHero for pair programming and general screenshare
- Google Hangouts for IPM, Daily Standups, Retrospectives and some general chit chat
- Tmate/Tmux for pair programming without ScreenHero (we haven’t used tmux for > 2 months)
- Pivotal Tracker for work tracking and specific task communication
ScreenHero at this time is invite only and sometimes a little flaky (its gotten significantly better recently) but when it works it is pretty great for most pairing duties. We’ve had PMs call in to just take a look at what we have on screen, as developers its as close to what I’d want for pair programming as I can find. If you can get an invite please try it out. The ease of having 2+ developers in a call about a problem with code in front of them beign able to point/select code and chat easily is invaluable.
So what has been my big take away from this last couple of months? Automation, easy communication and pairing are probably the most important things to do to enable new hires to become effective quickly and more importantly, enjoy working with you. As a new hire the most important things you can probably do are take part in communication, automate the stuff you find frustrating and offer flexibility, especially at first.
We’ve delivered our crunch to little fanfare and have started the post MVP tidy up. To take on a new engineer, plow through a month of work, release and see the tiny number of issues we’ve seen is - I think - testament to the system I was inducted into and the change I’ve been able to make within that framework as required.