When done right, effective onboarding can help new developers feel welcomed and valued, which leads to higher job satisfaction and retention rates. Having a clear plan helps new developers understand what to expect, reduces uncertainty, and ensures that everyone is on the same page. Here are 5 things that can make these days a breeze!
Pop-up developer environment
Wouldn't be nice to have everything up and running in a matter of a click? Although we are not there yet, there are many tools to create self-contained developer environments. Let me show you 3 solution, all of which provide benefit from very low effort investment.
Tilt
If you are developing to Kubernetes, you will love Tilt!
Tilt is a development environment tool (Who saw that coming, huh?) that spins up your microservices in a matter of a CLI command. After that, no more CLI, no more kubectl, just happy developing.
The tool utilizes a configuration file that can automate any workflow necessary to get your local environment running. Except building, caching and starting up all containers, because that is built in. You will develop in the containers, the home of the code in production, so all precaution is done to prevent drifts or unexpected errors. What about hot-reload? You might ask. Tilt knows that seeing the result of code changes immediately is non-negotiable, so all changes is code, configuration or even the Dockerfiles are listened to and trigger a rebuild. Don't worry, it only rebuilds the components affected by the change.
Currently Tilt runs everything on your local machine, that is huge a benefit for some, especially the security and budget savvy. They are working on a cloud offering, that will allow further collaboration and ease for developer teams.
Microsoft DevBox
A new sweetheart of enterprise and dotnet developers is Microsoft DevBox. It spins you up a virtual machine in the cloud based on pre-configured SKUs with all that you need to start working on projects immediately.
This is yet in public beta, you can have a machine re-installed with a suite of development tools, including Visual Studio, .NET Framework, and Azure SDK. You can customize it by associating repositories, configuration and container images with your account, although it lacks the ease of configuration yet.
What makes the most appeal to enterprise teams is the lack of network whitelisting and ticket hunting. It uses reverse proxy, no special port so it won’t crash into policies. For the most popular development stacks, you can already find pre-built virtual machine images on Azure marketplace.
GitHub Codespaces
Probably one of the best known options for virtual developer environment is Codespaces. The tools and configuration are defined in a configuration file in the familiar format of json and Dockerfile that can be (I think, should be) stored in the same repository as the source code.
The installation of frameworks and tools, even checkout of the sourcecode and installation of dependencies are done by the time you log in to start working. The work environment is actually remote, a container in a virtual machine in the cloud. You can still use your code editor of choice to connect, with solid internet connection your experience won't be any different from working on your own machine.
A huge pro is that the container specs can be adjusted to have the best value and performance to the given feature. Need to run multiple services on the same host? Scale up! Fixing up CSS of a small website? Scale down!
Simple source control strategy
Keep it simple stupid, right? It sounds easy until everyone agrees what simple is. When you are accustomed to complicated a system, it starts to feel simple.
Simplicity is consistency. Choose a branching strategy from the public domain and stick with it whenever possible. Developers will greatly appreciate that they can continue working with a familiar workflow.
Keep repositories independent. No modern tools have utilities for submodules, resulting in outdated dependencies, skipping tests for code blindspots and you need to document what submodules are required for what features. If working with legacy code, consider developing custom automation for dependency documentation and management.
Predictability is the most important aspect of simplicity. If merging to main on one repo automatically triggers CI/CD but on the other repo it's a manual process, you may cause someone a heart attack. Talk
Understand the task
Choosing the right first tasks is pretty important. You want the very first task to be trivial. Something that can be done in 10 minutes, or even less. It can be made up.
If you ever participated in Hacktoberfest, you must be familiar with this concept. The point of the first task is to get familiar with the codeflow, the review process, the environment and give a little burst of accomplishments into the long first days.
This practice is pretty widespread among the industry but after newhires tend to fall into the grey workdays. I have a meeting format to talk through features with the newbies. I have the curse of knowledge and they don't know what they don't know, so a little help to cover the most important topics doesn't hurt. I stole the format from design thinking. Feel free to adjust the questions to your situation.
Discover
- Did someone work on this task already?
- Who is a user/tester who can help me understand the success criteria?
Define
- What does it look like when it works as expected?
- What does it look like when it does not work?
- What dependencies does this task have?
Ideate
- Can I break down this task to subtasks?
- Which tool do I have to accomplish this task?
- What features of the techstack can I use to have the best result?
Prototype
- Point to code that can be reused
- Write pseudo-code together to conceptualize the solution
Test
- Show how the feature can be tested
- Talk through test data
- What access, permission, account etc. is needed for testing
Get help (even if you don't need it)
Are you doing mob programming? You should! Building a team is facilitating communication and embracing connections. The best way to figure out the team is to work together. This is the concentrated version.
Schedule a half day with the team to work on the same issue together, with a single laptop (or screen for remote teams).
It is a great tool to learn from and about the team, tackle a real problem, build mutual trust and find the vibe. It can be a bit intense, but makes it easier and more likely for the newhire to ask for help.
Deliver
Think about what creates attachment in people! When you see your feature grow up... I mean go to production. One of the reasons why CI/CD is so popular is that developers are more likely to take ownership over features if they triggered deployment to production. That is not possible everywhere, but facilitating the experience to allow a newhire follow their feature from start to finish is.
Not only will it hep with engagement, it also helps understanding the software delivery lifecycle from the definition of the feature to the deployment. Cross-team communication is stellar for engagement, understanding constraints, practices and growing empathy along the way.
Here is a song to mumble while thinking through the essential contacts to have on the list
Top comments (0)