There are more principles and best practices in Job Safety-Driven Development than can be described. Still, this is just a frivolous article on a serious topic. It is intended only to highlight the problem, even if it is in the form of a joke.
Blindly following stereotypes
There are a lot of useful tools and approaches in the world of Django development company. They need to be used, but how can this be combined with JSDD? Everything is simple. Don’t use original sources. No need to figure out what ideas were originally invested in Fowler’s refactoring, Gang of Four design patterns, and so on. After several iterations of reprinting without understanding, even an excellent approach will become suitable for JSDD.
But the information gypsies do not understand, they tell a cool and difficult story. And they constantly need new content. This is your true JSDD ally. And you can always refer to “conventional opinion” and “community”.
Of course, blindly follow stereotypes in such a way as to shoot yourself in the foot at least once. If this did not happen, most likely, the original source has not yet been completely corrupted, so you should not use this approach.
Also, do not blindly follow all the stereotypes. Sometimes something very useful and effective enters the market, it is important not to use it accidentally. Develop “tunnel vision”, worship only a select set of stereotypes, and shut yourself off from everything new.
No backward compatibility
Attention! Important. You have to constantly rewrite and add functionality. Lose backward compatibility, this is useful. Then close the problem with crutches.
Ideally, you should write the first layer of the API. Then start writing the second version of the API, drop it halfway, and start writing the third version of the API, including new methods there. Methods in the first, second, and third versions of the API must refer to each other. Promise to fix everything in the fourth new version of the API, which will only have new API methods.
At some point, you just need to abandon one version of the API, get a huge regression, and deal with a bug fix by writing crutches. Over time, your code will get so tired that you don’t have to make any special efforts to make the code voluminous, complex, and incomprehensible, and it really takes time to solve simple problems. And any new person looking at your work of art would just quit.
Bicycle building and innovation
Difficult but important point. You must constantly strive to use new technologies, preferably raw ones, and promise that they will solve all problems. In addition, they often have an active and large “community”, refer to the frequency of commits to the repository. And even write them yourself. We need innovation for innovation to lose job in the great company (https://www.softformance.com/).
It also needs bicycles. Right at the core of what you do. It is ideal to write your own framework around which to hang innovative microservices. Even if someone has already solved some problem 1000 times before you, then your 1001 individual solutions are still necessary for the world. After all, you will do better. After all, if you were not sitting in your company, but, for example, would launch people to Mars, then people would already be flying to Alpha Centauri.
Leave a Reply