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.
How I come with the idea of Crime Scene Investigation Software Engineer
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.
CSI SE Definition
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.
Why we need this position
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.
What is a benefit for the company
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.
Is this an executive role?
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.
Conclusion
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.
Top comments (12)
Love this idea Damnjan! Where do I sign up? Maybe after this
DevOpscrazy settles down CSI SE can be the next big trend? If it bring quality and responsibility I am onboard!Hi David, thank you so much on such positive feedback :)
I planned already for some months to give a talk at a conference about CSI SE, as a serious proposition to management to think about forming such a position/role. I'll be so happy to hear more of your thoughts on this topic if you have some now, or you come with some idea later.
Cheers,
Contact your local FBI office. Recruiting efforts at my college in the early 2000s included the tag line, "You'll get to track down predators while carrying a laptop on your back and a .45 on your hip." 🤣
Enhance that
I got a feeling that HR will be including this job title when they are hiring
Ironically, when I do stuff like this, I also use CSI: Commenting Showing Intent. Once I've fully commented the code, which may take anywhere from minutes to days (depending on the size of the code base), I can better see what I'm doing.
Hi Jason, thank you for your comment. I prefer self-explanatory code + unit tests as in-place documentation (explanation) of the code.
However, I read the idea behind CSI (Commenting Showing Intent) in the article you shared, and I can only say that it is not my style, which does not mean that it is not working for someone. For example my team-mate, who is sitting next to me, his role is to writing automated feature tests in PHP and he doing all the time "Commenting Showing Intent" style. That apparently works for him; I'll be glad to share this article with him :)
Interesting idea - thankfully in CSI, it is not required for the detective to have prior murdering experience. It might be more accurate to call the software engineering counterpart Dexter SE :P
I would argue that hacky code happens even in the best teams. The main vector of hacks sneaking in are requirement modifications to an existing codebase. The process looks like:
(I just updated my handbook Programming Without Anxiety with a chapter on Bugs and Debugging)
New system gets designed, interactions with neighboring systems mapped.
New system gets implemented, hopefully tested, etc. After some unavoidable early bugs, it runs just fine in production.
Small new feature request pops up. Think of it as the final straw. Even if small, it can turn the whole design upside down.
Guess if the whole system will be redesigned for the new feature to nicely fit, or if it is hacked in at some semi-convenient place.
Isn't it a part of a role of principle engineers?
I would say it should be the role of every engineer to know clean code standards, principles of object-oriented design, etc. It should be every dev person responsibility not to merge dead code, dirty hacks, etc.
But it's not... unfortunately.
And that's how this role is born because we can't count that engineers will stop creating more garbage and mess.
That's what I am saying - it us responsibility of a seasoned engineer with very good mature level to enforce best practices.
If we can't count on engineers to control software mess, that would require legislation and regulations on which your agency would run, otherwise software CSI role would be nothing, but a woodoo practice similar to dark agile scrum master.
I don't watch TV nor series anymore, but I love the analogy!