Fearless Development

Confidence is an important factor in getting started quickly on a new task and also in knowing when that task is complete and ready for sign-off. When you’re afraid of all the unknowns, when the setup is confusing and unfamiliar and when you’re terrified that whatever you do could break the code that’s already in place, that’s when productivity takes a nose-dive.

Throughout this guide we talk about the ways in which the software practices we stick to can aid your confidence as a developer: having a thorough test suite as a rock-solid base to work on; separating out deployment environments so that you can sandbox your app with ease; adding monitoring in early to save head-scratching time later; making reusable components sooner rather than later for you and your developer friends; it’s all good.

Adaptive Lab’s Culture

The work environment we have established is another key factor of fearless development. We’re highly focussed on the working culture we’ve set up and we foster an environment where individuals in the team feel supported in what they do. There are no stupid questions!

Everyone has different skills and expertise, so we like to share those around the team, sometimes by giving talks on subjects of interest. Books, courses, meetups and being given the time to learn new things help to plug any knowledge gaps.

When working as part of a team, it makes sense to leverage that combined knowledge. The sum of the whole is worth a lot more than the individual parts (Unless you happen to be a super-awesome individual and the team is just slowing you down). The team should feel responsible for the quality of the work that it produces and the combined experience can be used to help ensure good quality.

There are no stupid questions!

When given a new challenge to solve and there are bits you’re not clear on and are uncertain of, then pipe up early. No one’s going to mock you for anything you might ask. Some people know some things; other people know other things. No one knows everything, especially when you’re dealing with domain-specific tasks that come with a history and a language created before you even came to work on it.