Hardest grind for software was probably for my "integrated design" class. Microcontrollers have a way of making easy seeming problems become hard, and we were tasked with making a pulse oximeter with an arduino uno. Arduinos are certainly easier to work with than something like a TI microcontroller, but the uno was severely underpowered for our mostly software implementation. The main problem was that we had built an entire working system and debugged over USB, when we finally tried to implement the required screen readout, we learned that the oled driver library used over HALF of the arduino's memory. Had we tried this earlier like any experienced engineer would, we would have realized this and pushed more functionality onto analog signal processing (or allocate time into rewriting the oled library). Unfortunately we were in too deep at that point and I remember spending weeks up late just to shave off literal bytes of memory usage so we could get our previously functional (and rather impressive) product to a state of barely working.
Worth it because of the grade and the story, but definitely not a healthy or productive way to work. If we had been smarter earlier on we could have avoided the grind. I was very stressed those weeks and honestly pretty mean as well because of it. Grind is not meant nor should it be a way of life. Your product quality will suffer, your efficiency will plummet, and you'll run into a slew of mental health and personal issues if you make a habit out of grinding. Everyone does it once in a while, but grinding needs to be seen as the result of a failure in the process (be it in planning, management, problem specification, or implementation), not a needed step.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Hardest grind for software was probably for my "integrated design" class. Microcontrollers have a way of making easy seeming problems become hard, and we were tasked with making a pulse oximeter with an arduino uno. Arduinos are certainly easier to work with than something like a TI microcontroller, but the uno was severely underpowered for our mostly software implementation. The main problem was that we had built an entire working system and debugged over USB, when we finally tried to implement the required screen readout, we learned that the oled driver library used over HALF of the arduino's memory. Had we tried this earlier like any experienced engineer would, we would have realized this and pushed more functionality onto analog signal processing (or allocate time into rewriting the oled library). Unfortunately we were in too deep at that point and I remember spending weeks up late just to shave off literal bytes of memory usage so we could get our previously functional (and rather impressive) product to a state of barely working.
Worth it because of the grade and the story, but definitely not a healthy or productive way to work. If we had been smarter earlier on we could have avoided the grind. I was very stressed those weeks and honestly pretty mean as well because of it. Grind is not meant nor should it be a way of life. Your product quality will suffer, your efficiency will plummet, and you'll run into a slew of mental health and personal issues if you make a habit out of grinding. Everyone does it once in a while, but grinding needs to be seen as the result of a failure in the process (be it in planning, management, problem specification, or implementation), not a needed step.