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 al...
For further actions, you may consider blocking this person and/or reporting abuse
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!