Creating the right environment

You’ve just hired a new junior engineer, and of course want them to be as successful as possible as quickly as possible.

To get this done, create the right environment for them. This is 100% the most important activity you can be doing. It may seem obvious, but no one showing up on day one or day 1000 will be able to delivery efficiently or effectively in the wrong environment.

What this means specifically:

• Remove all obstacles that don’t exist to support a new developer.
• Understand what that individual cares about
• Understand their learning style
• Understand where they want to go in their career

Starting out expecting that someone will just go from where they are to where you want them to be is fools errand. They will go from where they are to where they want to be. You’re goal is to understand and utilize that for mutual benefit.

Fix the development lifecycle

The first part of this is culture/environment the developer is in. Create only technology and processes that are obvious. When a process exists to solve a more difficult problem, solve that problem. You can easily recognize these when you hear words like This is what we have always done, or _We need to do this because X,Y,Z on the other side of the building/business needs it._When you have requirements that are not self-evident it requires esoteric knowledge to execute “effectively”. Those are exactly the things that “experience” and “domain knowledge” help with. So instead eliminate the need for domain knowledge and experience. Limit your long conversations. Ask the 5 Whys of analysis, and make every one of those answers obvious.

The best strategy to solve this is limit the “developer configuration” to zero. I’m an expert software engineer and have experience in specific languages. (I’m not proud of some of them, but that’s not the point) Javascript, C#, Ruby. I expect on day one of working in a team:

• I can go to one of Gitlab, Github, or another online git/task management web app. No custom, self-hosted, on prem solutions. Your code is not that important, if it isn’t available so that working from home on my laptop I cannot connect to get the source code, then there is an issue. Think of it like this, your new developer is on-call and there is a production issue. What steps do they have to take to check out the necessary code to investigate. Can they do this on their phone, on a train?

If the answers are No, then make it simpler.

• Automatically get authenticated with my domain credentials for the company (or auth using my google account). After being added to a security group or being invited, I should be able to access everything in the company I need to. Multiple security groups or invites create unnecessary overhead, and especially no registration. Oh you don’t have access to that system yet, is just one more thing to slow a developer down.
• See the list of tasks for the team there, pick the most important one. Where is the list of tasks, how are they tracked. If I can easily go to one obvious place to answer this question, then you’ve made too difficult to pick up new work. That means the new developer will be inherently deterred from doing that activity.
• Then fork the repository, clone it locally. This should be the easiest part, if it isn’t there is a real problem.
• Run one command to install all necessary packages or setup my machine for this repository in way which doesn’t require any manual steps and doesn’t prevent working on any other repository for another company or FOSS service/library. I can’t stress this enough of how much this needs to be one command. And that this command needs to be axiomatic to the language. This likely means making serious changes to your development pipeline and architecture to be able to support a new developer. If on day one they need to perform “machine setup steps”, immediately take a look at that. No matter how “simple” you think they are, your process is more out of date then the C# or node installation guide. I guaranteed you also haven’t tested your process on every type of OS with every browser and version. One of those scripts will break and your new dev and a senior will be sitting there all day playing around with unnecessary legacy technology instead of doing work.
• Load that code into my editor of choice. Sure there may be some editor specific configuration, but I expect that all of the necessary parts to execute are either contained in a configuration for the language. i.e. if I’m using node, yarn test should run the tests and yarn start should create a dev webserver for me to test locally. The editor may have a shortcut, but that’s all it is. Require a specific editor? Fix that. I have no experience with Visual Studio on Windows. Don’t make me try. I use Linux personally with VSCode, if you make me switch, for 1 year I’ll spend it being considerably slower, just because the development environment doesn’t work exactly the way I want it to. (This doesn’t mean don’t commit the necessary IDE files to your source. I would recommend it, just in case you get a developer that is using one the team already is, but don’t require it)
• Make the necessary changes without understanding the context of anymore than the explicit files I need to change. The architecture of services or hierarchy of a service/library is extremely important. Organization is key, and more importantly SRP (Single Responsibility Principle). Having separations of concerns in your source code and following good coding practices helps to reduce by a large margin inefficiencies. If I have a bug ticket that says: “We have an NRE on line 10 in file X”, I should be able to go there and understand what file X does, how the methods in that file work, fix the NRE bug, without understanding any other code in the entire repository. If “oh but there could be a problem elsewhere”, is a red flag, and should be investigated. This means always writing clean code that is readable. Longer variable names the better, the most specific method names, no excess validations or checking for things that should never happen. If something should never happen then you don’t need to check for it. I would quote the SOLID principles
• Push that code to my fork, and create a Pull/Merge request. This implies having all the necessary CI/CD automation in place. If I need to start doing things manually to test/deploy a MR or deploy to production, you are creating overhead and complexity for a developer for no reason. PR code get’s deployed for testing automatically and the location of that is reported to your MR automatically (most CI/CD platforms do this out of the box). Then on merging the code it goes to production, no extra manual steps. If there is an extra manual step, I will get it wrong, remember I’ve never used your process or tools before.
• Meet with my reviewer whomever that is using an online app for communication, slack/zoom/meet/skype whatever (which also has integrated login). I will be working remotely one day, because I’m waiting for my package to arrive. Can I still work? I’ll be at home, and I might need to communicate with the team and others. Are they prepared for that, or does being at home suddenly increase the cost of working?
• Merge that code, goes to production
• Grab the next issue, repeat
• Review that list of activities that need to get done, and make sure all of them can happen by simply adding a user or email to specific DL or security group. If any of these cannot immediately be done by an already experienced developer, then that’s the first step to over come. Those are just unnecessary obstacles.

I can do all of those things long before I hire anyone new. Once I’ve hired them, I need to start looking into how that person works and how they’ll fit with the team. Before they show up, I make sure they can log into to our systems, this means communication (Slack), email (SES/GSuite), Git service (Gitlab), and Cloud (AWS). But that’s all I need to setup (and most of that is controlled by integrated auth). That works for technology, but I also need to start the conversation with them. Who are they really? They were a fit for the company after the interview, but I want to make sure they are prepared. Do they like UI frameworks, or algorithms. Microservices, REST, DDD, TDD? Where are they going in their career? I need to have the track laid out. Set the expectations on where they want to go and how to get them there. This doesn’t need to all happen before they show up, but sharing that this will happen puts them in the right mindset.

Now they are there, assuming I understand the development track my developer wants to take and I understand what motivates them, now put them in your environment, and they’ll succeed right?

Being Reactive

Well… You can’t have solved for every problem 100% so some things need to be reactive. What are the support structures you have in place to ensure they’ll be successful even when they aren’t. They will go to your team and ask for help. Is your team ready to support another developer? If everyone is unhappy in the team or struggling in their own way, then they might not be successful. Do you know if your team is performing and working together or if they are just a group of people you are calling a team? You need to know, and this isn’t an easy question to solve. Most Team Leads and Managers, are never able to do this correctly and there is a lot of survivorship bias. Use a tool, something that tells you how your team is doing (and not the number of commits they are making), how they are really doing. Are they supported, are they aligned with the team? Are they contributing in a way they want to be? You need a tool to help you answer these questions. Your performance evaluation or employee engagement tool is NOT that tool.

Create feedback loops

Ensure the feedback loops are there, so when something is going well you’ll find out. These feedback loops aren’t necessary obvious for everyone even experienced senior developers, but put them in place, and explain why they are there:

• Team Identity => Everyone is aware of what this is and you talk about it explicitly and frequently. When there is a decision to be make you link it back here. Creating a team identity values, mission, and vision is difficult, but it is constantly adjusting to what the team wants. Make sure everyone knows what this is.
• Short term => 1:1 every week you’ll meet with your team members and guide them to grow. Understand where they are at and help them get to the next step. This is your first clue on how to make sure things get better or prevent things from getting worse. You won’t be involved in every discussion, so having this short term view into team members is super important.
• More Short term => Team Alignment meetings, talk and discuss what the priorities are and how they are changing. Discuss new work and how it fits into what is currently being worked on. This means having a strategy for how work is created and prioritized. I highly suggest OKRs, because they are the fad right now. I use a whiteboard for this.
• Medium term => Retrospectives, have everyone in your team about once a month, meet and discuss the anchors and sails for the teams. What slows you down and what picks you up. Listening to that and using it to make changes in your medium term feedback loop
• Longer term => 360 feedback. Get your team together and discuss how an individual is doing. Get honest feedback and share openly. Understand where they are at and how other perceive them. The tool you picked to help your team with this is super important and helps here as well.

Making the jump to Senior

To be truly effective, making the leap from junior to senior is joining the delivery with what’s best of the business. That means stop the discussions what needs to be done, and instead have them about why it needs be done. Having to micromanage the what makes this very difficult for everyone involved and to get them productive means they need to realize the why themselves. To get them their make why the point of every discussion. Here is something we can do, here’s the value it brings, and then follow it up with how we are going to do it. If someone doesn’t understand the why , then they can never be sure of the what. Is this the right code to write Is based on many assumptions, having these be the right understanding in the situation is important. You can further get here by:

• Introduce that person to real users. These are the people asking for features and feel the pains and successes of what they are working on. Get them to start thinking like the user.
• Introduce them to some stakeholders. These may not be the users, but they should those that want to see those user succeed. They are more frequently your partners, and can connect them with the right users. This may be an UX division, a marketing research team, or even a great external partner.

That’s probably more than you asked for and more that most teams can do, but to be efficient and effective, executing on these