Building a development team so that they may tackle any challenge sounds like the dream. However, can it be done? Of course, it can. Just as a child needs guidance and encouragement, a development team needs to be engaged and challenged frequently to mature and grow. New patterns and technology can foster tremendous growth, especially when you take a team outside of their comfort zone.
We’re not advocating the wild west of software development though. We are suggesting that your team (or company) has a proper culture in place which has coding standards and follows good, strong principles.
What is a proper culture you might ask? There isn’t a one-size-fits-all answer. Every company is different, every developer is different, and each team is different. A solid company will learn what these differences are and let its culture grow and shape itself as needed.
Yet, acknowledging differences doesn’t mean that there aren’t any similarities among cultures or that some ideas or aspects of culture won’t yield more success. For example, modern development teams need to be growing and constantly improving. Stagnation and a lack of growth in the current software development environment will probably doom any team or company. Naturally it follows that development teams who put an emphasis on developers’ growth, both professionally and personally, will flourish.
At 2amigos, our developers are encouraged to challenge themselves. We want our developers to have projects of their own, to try new languages, or frameworks they don’t normally work with daily. We want them to experiment and develop and grow in their own time, doing their own things. Developers also need to have the drive to grow and thrive and they must be given the time to do that, removed from the same static, day-to-day environment in which they’re already working.
Another important part of 2amigos workplace culture and our success is that we don’t micromanage our employees. As a growing company that’s heavily reliant on working remotely, not only is it impractical for us to expend resources watching, monitoring, and constantly worrying about the small details and day-to-day work of our developers, it simply isn’t the culture we’re aiming for. We think companies are more successful when they focus on results and give developers the flexibility to work in the way they know is most conducive to their success, instead of focusing on details and constraints.
Giving developers a high degree of flexibility and freedom to work as they see fit doesn’t have to come at the cost of rules, standards, and, to some degree, of uniformity. At 2amigos, we still have rules and coding standards that developers follow. We also employ “tried-and-true” principles that let our developers and our development team be successful. I’ll share the three principles that I’ve found the most successful.
KISS - Keep It Simple Stupid
This principle is as simple as it sounds. In general, keep code simple and minimal wherever possible. The KISS principle is, at times, elusive. During those times it doesn't seem as easy as it truly is. Some coding problems and their solutions are complex by nature. Sometimes we're late or behind and rushing to meet deadlines. Developers find that they’re implementing the first suggested solution and there isn’t time to refactor. Maybe it’s improving or adding functionality to someone else's code and a developer is working with what someone else started even though restructuring or rewriting the original code might be simpler.
Daily, it can feel difficult to follow this principle, but long-term it has numerous benefits. Simple, easily read code and uncomplicated logic make testing straightforward and easy for another developer to work with code and understand it. It’s also easier for anyone to continue if work with the code stops and is picked back up months or years later. It's one small step that tends to pay back on time and energy repeatedly. For my company, keeping things simple makes every developer's job easier and makes it easy for the development team to maximize synergy.
YAGNI - You Ain’t Gonna Need It
Here's another one that saves everyone a headache and a half in the long run if the team’s code follows this principle early and consistently. Don't add any code that isn't necessary. If it isn't part of the design and necessary functionality, don't implement it. Sometimes as developers we find ourselves with a moment to spare and try to use that time to future-proof our application, preventing a problem that might come up in the future by addressing it now.
This is the exact kind of thing we should be doing, but only within the scope of what we're already implementing, not by adding something we don't strictly need or introducing new features or functionality that aren’t related to what we’re already working on.
This principle is especially important if your company is creating code for clients like we do. While at 2amigos “clients” are primarily external entities that have hired us for development work, a “client” could also refer to a company’s project requester. As a developer, it can be tempting to see some functionality or new feature for an application that you think is particularly beneficial and ought to be included. However, the client hasn’t specified the feature or asked for the functionality. Sure, the client might want it down the road, but if they never do, you’ve lost the time it takes to implement it and to delete it. Now, there is a fine line between a new, extraneous feature and something that isn't explicitly outlined by a client. If the new feature/functionality is necessary when you implement what the client asks for, perhaps the development is justifiable. Make certain the team lead is cognizant of that difference and minimize the opportunity to spend more time than is needed. Avoid work that is superfluous.
DRY - Don’t Repeat Yourself
This principle usually seems obvious. A lot of developers are probably thinking “I already try not to repeat myself, it’s not like I just copy code to slow down application performance”. Still when developers repeat themselves, it’s usually in much more subtle ways. Modularization is a popular topic in development circles. However, looking through actual code, there are countless examples of code with a similar purpose repeated across classes. It isn’t always easy to see when the same function could be parsed out of a few different classes and put into its own class. Sometimes the same functionality shows up within multiple functions in just one class and that functionality could be placed into its own function in the class.
There are a variety of ways to avoid repeating code and a failure to use modularization isn’t the only time repetition is evident. Be on the lookout for code the team has already written or problems that were solved earlier. Whether it’s in the same application or across different ones, if the team solved a problem or implemented something that seems generally useful, consider taking the time to put it in a library. If it’s general enough, the implementation could be useful to other people tackling similar problems (whether the code is provided in a library to the team only or published for anyone to access). It’s possible that a different development team could need the same solution on a different project or for a different company. This level of effort to avoid repetition isn’t always necessary, but it’s helpful to be aware of it.
It’s hard to overstate how much you’ll find principles like these create a successful and strong development team.
Building on the Principles/Introducing Challenges
With principles like these in place, developers can start feeling comfortable with a consistent floor of quality that’s being produced. However, consistency and comfort are only one side of the coin. Growth, challenge, and occasionally being uncomfortable are the other side. To build the best development team possible, a harmonious pairing is needed between the consistency you’ve developed with these principles along with the advantages that growth and challenge present.
In a field where things constantly change, new technologies are always being created and many developers feel challenged so consistently, this discussion might seem obvious to some. Yet, it is surprising how easily stagnation sets in when we’re not paying attention. Further creating an environment where engagement, challenges, and growth are ever present is a task that few companies achieve.
One excellent solution is encouraging developers to develop code on their own. Give them the chance to sandbox, especially with new technologies or new languages. Their experimentation could pay dividends. There are plenty of times when a company finds itself switching to a new framework or language quickly. It’s a relief when a few members of the development team are already familiar with the tool or framework to be used. Other times, a team might create an application in one language, and find a library in a different language that’s perfect or has everything the client wants. While these situations aren’t always going to arise, there’s no real downside to developers having more frameworks and languages in their tool belts and getting even more experience coding both in their work environment and outside of it.
Another great way for developers to grow is participating in talks, summits, events, or hackathons. While there’s only so much to gain from an affair that usually lasts a few days at most, never undervalue the chance for developers to immerse themselves in a learning experience where others in their field, oftentimes more experienced, are sharing their knowledge or coding as well. Just this year, someone from 2amigos was able to attend the Web3 Summit and attend talks relating to the blockchain at a time when 2amigos has been diving headfirst into working with the blockchain.
Being a developer is a bit like learning non-programming languages. More immersion and time spent with a new language means more competency. Make certain developers are following good principles. When a comfort zone is established, take them out of it periodically. Give the development team room within the day-to-day or week-to-week to broaden their knowledgebase and feel challenged. Let them code, experiment, learn, make mistakes, and ultimately flourish on their own, especially if there really isn’t room for new technologies or taking any risks while they’re on the clock.
Having this kind of growth mindset and trying to challenge developers will keep them and your company from stagnating. If you’re the company leader, or even if you’re a manager, challenge yourself. Take this article to heart and take a long look at your development team and your company, where do they have room to grow? Are your developers challenging themselves? Is your company’s general trend one of stagnation or growth? Could your development team right now succeed with any challenge they may face?
If this article doesn’t provide all the answers, it will encourage team leads and managers to ask pertinent questions and shed insight regarding how to create a development team that can really succeed.