Ignoring the several hours troubleshooting terrible developer work (my role is change management, not developer), I have been thinking there have been some benefits to working with such troublesome developers.
I learn a lot. I learned about the history of text encoding. I knew about UTF-8 and Unicode which helped me go down that route. Guiltily, I did go down a rabbit hole and probably didn't need to know the wikipedia version of its history. Surprisingly, there is no easy way to identify when text encoding a file uses. I ended up just using notepad and the open as option. I had to guess and hope I can read the file. There are some apps that I could download, but my work laptop is annoyingly locked down where I didn't want to spend time working around that.
I learn how underpaid I have been for so many years as a developer. Sometimes I wish I had a mentor but life can always be better. I feel fortunate that I was born smart enough to figure things on my own.... eventually. I have to teach our developers about file encoding. How did some of them figure out how to mess that up? I may never know but at least I know there is such an option. Also how do they do that in between version? The files were not even brand new. You open, you modify the one line, save, and commit. Yet, they managed to mess that up and not know why.
While on that note... how did they figure out how to change the configuration to change all EOL characters? When I review the git diff, I see a wall of changes for something that should be a line or two. I can even see the visible text being the same. Initially, I threw this over the wall to the developers to figure it out. A month later, still an issue. Because I was already looking into why git would think files were binary, I thought this would be related.
Having a hex editor would have saved me so much time on both these issues... but I simply just did a diff to ignore white spaces and suddenly only the one line is highlighted. 5 minutes of my time and paid developers couldn't figure it out for a month.
It is also interesting to learn how the value of just having the bare minimum work is financially positive. We just went through a layoff and lost about half our staff. The next couple months, they backfilled with cheaper developers. The remaining staff basically just spends their time fixing all the bugs, reviewing their codes where they basically rewrite about 80% of them. They all complain that they no longer just code. Yet, it seems we are doing well. The senior developers seem to be more stressed but that doesn't impact me. With more changes due to poor code and misunderstood requirements, my job is even more secure.
I have gained more experience on how much people are willing to lie and deceive about their work when there is so much evidence to show otherwise. And how unwilling management to action on these reports turn so many employees into quite drones yet wonder why no one says anything.
So in conclusion, it has been kind of good to me personally to work with such poor workmanship. I am continuously learning how to manage all the developers who don't want to do things properly, learning how much time is wasted yet still profitable, and learning how to remain positive throughout the entire turmoil.
No comments:
Post a Comment