Syndicode is still looking for new developers and we decided to find out the initial sense of the programmer’s occupation. This profession is relatively new for the humankind. But it already has got its own features and culture, what is proved and important. In the last 50 years programming uncovered the new horizons for our world. And we need to eventually understand what is it like to be a programmer.
This text is created on the base of 3 questions of programmer article by Andrew Batutin and aims to find the borderline between our expectations of being a programmer and the reality we face. No need to romanticize, but no need to be sad also.
Reality vs Expectations
Have you ever been in a situation when your email correspondence has become longer than the history of the commits? Or have you ever deleted a reminder in your calendar about another endless and unnecessary meeting? Or do you remember your disappointment about the next unpredictable changes in requirements and tasks on the project? Confess that you had these all. But you’re not a project manager, you are a programmer! And you did not want to spend most of your time talking about nothing in the stuffy meeting rooms with a bunch of unfamiliar men. You wanted to program.
For such cases, when the project starts to move away from the optimal development trajectory, Andrew (the programmer) developed 3 main questions the answers to which will allow you to quickly get back to your favorite work. We want to share these questions with you.
- Question number one: who are we?
Sometimes it’s hard to answer this question. Each singe team needs the understanding of itself to compare expectancy and reality from the actions it takes. If most of your colleagues used to work as programmers and as the project managers at the same time you can do nothing with it. Get used to it and work as the most of your team members do. You can ask yourself:
- How many of us are in the team?
- How professional are we?
- What are our motives?
These questions help to understand your team, its capabilities, and limits. If you are a group of JS-devs, then you probably shouldn’t tackle embedded-development. Just as it does not make much sense to send a person with 15 years of C ++ development experience to develop a site for selling cat food.
If you are the only senior in your team with a flock of immature junior developers around, it is worth sticking to conservative, well-known techniques and frameworks. And do not take on the newest technology stack and drive your team to an empty page in Stack Overflow with a question without answers.
- Question number two: where are we?
This issue is vital because it belongs to an extremely valuable resource – time. It is necessary to understand the type of project or product that you are working on. And at what stage of development is it. And also understand the state of the company you work in. The list of subquestions for this section is:
- Are we making a product?
- Do we work like outsourcers / outstaffs?
- Do we position ourselves as IT-consulting?
- Are we a big/small company?
- Are we at the beginning / middle / end of a large / medium / small project?
- Are we at the product support stage?
To move a large project to a different type of database before the release is not a good idea. At the same time, just writing code without looking at the documentation and autotests can be a completely justified strategy for a small team in a startup. It depends on the answers to the questions you can see above.
- Question number three: where are we going?
How many times was the silence the answer to this question? The destination is extremely important for the success of the project. Without the set goal, you can not even really measure the result of the team’s work. Basically, you should be interested in the nearest milestones and release dates. And also the functionality that needs to be provided. The list of subquestions for this section might have next points:
- Do we expect the major release of a new bundle of features next month?
- Should we release MVP as soon as possible?
- When is the nearest demo for stakeholders?
- Should we release a beta version to test it with real customers?
If you need just an internal demo for the team, then don’t spend too much time on the CI / CD and the documentation. But if you are making a major release of your library that will break half of your old APIs, you should take the documentation as seriously as possible. If you go to live for the first time – you should be prepared for a quick bug fixing.
If you can not answer these subquestions, you can replace the main question with: “How to understand where we are going?”. Ask the other people who might know. There’s no magic bullet. The truth is somewhere in the middle.
All of the above sounds obvious. Then what is the meaning of this article? Your story as a programmer begins when you combine all three questions together and start acting according to the answers.
For example, consider the following situation: you are a small team in a large company with the task of maintaining an old system with very large user activity. The optimal option, most likely, is simply to preserve the old code with the minimum necessary changes for the bug fix. If you did not ask yourself 3 main questions, then you could easily succumb to the instinct and start refactoring the old spaghetti code that you inherited from previous generations. And by this you are very likely to put down an extremely important service for the company, not having enough resources to quickly restore its efficiency.
Imagine the other situation: you are a large team in a large company with the task of maintaining an old system with very large user activity. In this case, you can select some of your team members to refactor the old code in a secure, isolated environment with the proper QA. And then smoothly release the new code base.
One more example: you are a small team in a small start-up, which must quickly develop a product to get the next round of investment for your company.
In this case, the quality of your code will not matter if you do not provide the result quickly enough to receive money to continue the project.
Compare with this situation: you are a medium-sized team in a start-up, which has already gained some popularity. And now you compete for the attention of a wide range of users. You still have to move fast. But now the quality of your product will require more attention. You do not want to lose existing ones and scare away potential users due to an awkward update or security breach in your product. Now you need to find a balance between code quality and development speed.
Can you see now how questions where you are, who you are, where you are going can help you to choose the right tools and approaches for solving the problems?
The software development process is iterative. According to this, you should ask yourself 3 main questions before each iteration.
Responsibility and leadership
You need to understand that the answers to these questions require some degree of responsibility and leadership. Sometimes you can not get a clear answer to your questions not because there are no answers. But because no one wants to take responsibility to answer. If you feel that you can take this responsibility, ask these 3 questions loud enough for your team.
A programmer’s occupation is a dynamic process of making hundreds of decisions in the conditions of limited time and lack of information. And here there are no ideal answers for all teams and projects. But there are 3 right questions for your team and project. And the right questions give the right answers. We hope you would use this for your next projects.
Subscribe to our weekly newsletter to get the most interesting articles right into your mailbox!