This must be job position of the future, maybe it won't be called CSI SE, but it will be described like in this post. Someone has to investigate all the crime scene of dirty hacks, late-night patches, dead code, bad practices. We have enough developers in most places, but with poor enforcing good practices and no discipline, we waste their power to create beautiful structures. Instead, software developers are used for creating more of bad code.
My mother asked me what is my daily tasks in my new workplace and what’s my job position. I could tell her that I’m a senior software developer, which is quite a dull answer already every time I change a company, but this time it felt just different.
My job was not just to jump into the code and do my work from 9 to 5. I got a job offer because of some specific skills I can bring to the company, some particular knowledge and urge for the fresh ideas they needed. The company already had software developed, but it was not in any pipeline of deployment, not tested, very fragile and maintained in a way to keep it alive. Someone has to jump there and observe where are the mistakes, what software crime has been performed, how to avoid it in future etc.
Back to my mother. She used to watch CSI Miami before (and other CSI related TV shows), and she is quite familiar with the concept, crime scene, and investigation.
That’s how I got an idea to call my job: CSI Software Engineer. It just perfectly explains what I’m doing, I have a crime scene of bad code, and I investigate how it happened and how to prevent it in the future.
Definition 1 (short one):
CSI SE is a scrum master but not to organize the team, then for organizing the code
Definition 2 (long one):
CSI SE, short from Crime Scene Investigation Software Engineer is a person able to identify, explore and examine the crime scene in the software. One who understands, and already experience all bad practices, anti-patterns, bad engineer behaviors, and repeatable mistakes.
CSI Engineer act like a Software forensic, he sees the crime scene of dead code, spaghetti code, fragile and dirty code and he tries to understand the reasons first, and then propose solutions.
We reached a point when it is not that hard anymore to get a person for a dev job position. But to get a good one, that's very difficult. Also, so many companies struggle with development force they have, they have enough developers, well paid, working hours seems to be fair, but still, they struggle with quality.
It becomes acceptable to write bad code, write code in a rush and deploy it, make only things work, but not follow any pattern or practice.
All of this happened, because some time ago, we had such a massive deficit of engineers, so everyone got employed, no matter what skills or formal/informal education they have. Good practice or patterns wasn’t enforced, because employees were scared that they would lose developers.
So everyone who type a code, call themselves developer, even they poorly or never learn, never test, and continuing struggle to duck-tape their software, and nobody seems to see a problem there.
This is how we come to the need of CSI SE. A new job position which brings knowledge, practice, discipline, and guidelines to the already existing dev team. Crime Scene Investigation Software Engineer should be able to immediately spot all failures mentioned above and propose a solution which is acceptable for a team.
The company who employes CSI SE have an advantage immediately and on the long run. Good CSI SE can immediately propose a couple of good exercises and practices to the team.
For example, if there is many places with "dead code", then CSI SE can propose that all "dead code" should be treated in a particular way (see examples here).
If the problem is unclear git messages, too unfrequent commits or inconsistent naming convention, also readily acceptable solutions and practices can be applied and be a quick win for everybody.
On the long run, CSI SE should spot weak points in dev skills, dev practices, and workflows and introduce either, learning or continuous movement, to improve. Learnings can be sessions, pair programming or training, and seminars, while by continuous movement I consider building strategies and plans where we want to go and which steps we have to implement.
Not necessarily. CSI SE can be just like any other developer in the team, only with a specific side role. If I get back to this definition: CSI SE is a scrum master, but not to organize the team, then for organizing the code, it clearly shows that CSI SE is not a role as a team-lead or CTO. CSI SE is just part of the team with the additional task of making sure that code continually improves and removing obstacles.
CSI SE also needs to be able to transfer knowledge to other team members inside the team. Teaching others on the fly is much easier if she/he is a part of the team on the same hierarchical level.
I expect that is next couple of years we will have a higher demand for CSI SE, maybe industry won’t call it that way how I named it, but I guess description will be as I just described it above. Message for one who wants to jump into this wave, learn good CI/CD practices, learn TDD learn good agile and extreme programming practices, learn how to transfer your knowledge, there will be high demand for the people of the ability to apply it.
Following folks on dev.to has always been key to customizing the kind of content you're more likely to see in your feed and notifications, but now that we have DEV Connect I feel like there is even more we can do by following folks with shared interests and willingness to be helpful.