Making it Easier was originally posted on the main page of LDSTech. It was written by Christopher Cieslinski.
In the day-to-day life of a developer there are always new projects to finish, new deadlines to meet, and new challenges to overcome. Sometimes the problems we face are new to us, and sometimes they are similar to ones we’ve solved before. Perhaps someone else has already solved a particular problem, or has a well thought-out approach to solving the same type of problem. We may “spin our wheels” unnecessarily on a particular challenge for days because we didn’t have those already-existing solutions or processes at our fingertips.
An individual developer within an organization can solve many problems alone and learn a lot. A team of developers can work with each other and become even better. To become first-class, though, an organization must enable all developers and teams to take advantage of collective knowledge and solutions already in existence. To be most effective, organizations should spend time, money, and effort creating and collecting those solutions and then disseminating the information.
I would like to focus on three ways that this can be done: creating and adopting best practices and standard processes; creating and consolidating code libraries and common functionality; and facilitating the spread of knowledge.
As we work on projects to create and then deploy applications, we encounter both good and bad ways to do things. We should keep track of the right ways to do things and also take note of how to avoid the wrong ways. We should continually ponder ways to further streamline the right methods so that they are even better.
The processes and best practices that we define can make it easier to get things done. The less we have to struggle with questions like “How do I actually deploy this thing?” or “Where do I even begin on debugging this?” the more we can focus on new problems and hence, the more we can accomplish.
When we have tried and true methods for doing things, we should do our best to follow these methods. We should help others follow them. However, we must remind ourselves that technology is always changing. We must be able and willing to adapt our processes and best practices to meet current and future needs.
As we write applications we often see the need to reuse parts of our code. We create libraries of functions for them. If we are extra-diligent, we may even document those functions to make them more easily understood by others on the team or by those who might maintain them in the future.
We should do more than that, though. That library of functions could be shared with other developers and other teams. Various libraries can be packaged together and made available for use in other applications. Why re-invent the wheel when we have so many nice ones at our disposal?
And we should still do more. We should spend a little time and effort solving some of the common problems people face, and maybe even a little time solving the problems we know they will inevitably face in the future. Libraries of these solutions can be packaged with the rest and we can get things done just a little bit faster.
So, we have all these great solutions, we have these packages of code that can make our lives easier, and now we need to let everyone know. If developers in the organization don’t know the processes and best practices, or aren’t aware of available code libraries, the developers won’t be able to use them.
We can spread the wealth with good documentation, articles, and even knowledge stores. We can give trainings on how to follow the correct processes and how to use the appropriate libraries. All that matters, really, is that we do something to increase the reach of this knowledge.
The time, money, and effort spent on streamlining the development process are not a waste. While we must manage our time and energies on this, and not dream up elegant but unnecessary solutions, we must avoid simply doing nothing at all. As we expend appropriate effort working towards efficiency, productivity, and simplicity, we will find that development becomes a little easier and we can get a whole lot more done.
Christopher Cieslinski is a lead consultant for the Church.
Discuss the feature articles on the LDS Tech Home Page.
2 posts • Page 1 of 1
At the Church, I feel like standard processes are no problem. We have a set menu of technologies and mature, established stacks w/in the strategic techs. Where I would like to do a lot more is in the space between your last two points, the transfer of knowledge about common libraries. We can stuff common code in the corporate Maven repo. We should include source jars much more often. Some sort of syndication on the repo would also be helpful.
Who is online
Users browsing this forum: No registered users and 1 guest