3 ms·

I really can't write code other than a) experimental (when testing a new library that encompasses a totally new concept) or b) absolutely readable and SOLID. a)

by dep_b 7y ago

I really can't write code other than a) experimental (when testing a new library that encompasses a totally new concept) or b) absolutely readable and SOLID. a) code never makes it to production before it became b) since when I understand the problem and my solution I can't leave dead or unreadable code. I've seen people that write nice code by day check in horrible entangled vomit because they wanted to make a deadline. So the next time I pull it, "it has just a few issues" and it takes me two days to sort out their mess where just writing it cleanly myself might have cost me only one day. My code just looks the same no matter what pressure. I just don't believe I go faster by making code harder to understand and maintain.

SamuelAdams 7y ago
> I've seen people that write nice code by day check in horrible entangled vomit because they wanted to make a deadline. So the next time I pull it, "it has just a few issues" and it takes me two days to sort out their mess where just writing it cleanly myself might have cost me only one day. I've checked in "bad" code before. Maybe I can shed some light on the other side of this. The business needed a feature a week ago, because all their marketing material had a hard date on the go-live date for this feature. They could not miss that launch date. Unfortunately the dev team was overloaded and they couldn't deliver all the features on time. So I, a consultant, was tasked with a few last-minute things. Fortunately this new feature was very similar to an existing feature. It used a lot of the same code as something already in the system. So I copied that into a new class (C#), made some (very minor) adjustments, and checked it in. We were able to launch the product on time. But now there was quite a lot of code duplication. Yes, I could have just "written it cleanly myself". But this was a tremendously complex product. We had unit tests, integration tests, and more. But we still had to perform hours of manual testing on any code that changed prior to a release. Refactoring the old code would have introduced more testing requirements, which slows down the entire release cycle - the risk was too great for our timeline. It's important to consider the total cost of your work, not just the amount of time a certain task takes you, individually. It's also worth noting, we made a new Jira ticket about the code duplication right away, and we were able to fix the code duplication in the next sprint, after the product release. The next iteration, 1.0.1, had the "correct / ideal" code.
- dep_b 7y ago
  Yeah, duplicating code that by itself isn't quite what I was getting at. I mean one big god class full of flags that is shared by two quite distinctive views that happen to share just a bit of functionality. In fact duplicating code in that particular scenario would perhaps have been a more sane thing to do but that didn't happen. It's just not helping me to ship something faster, slapping together crap. "Create new file" takes 15 seconds, adding a function there and calling it from the original class I was working in another 15. Debugging sessions to figure out where what flag in what condition was misplaced take 10 minutes. Every time. Where am I really winning time?

by dep_b 7y ago

SamuelAdams 7y ago

> I've seen people that write nice code by day check in horrible entangled vomit because they wanted to make a deadline. So the next time I pull it, "it has just a few issues" and it takes me two days to sort out their mess where just writing it cleanly myself might have cost me only one day. I've checked in "bad" code before. Maybe I can shed some light on the other side of this. The business needed a feature a week ago, because all their marketing material had a hard date on the go-live date for this feature. They could not miss that launch date. Unfortunately the dev team was overloaded and they couldn't deliver all the features on time. So I, a consultant, was tasked with a few last-minute things. Fortunately this new feature was very similar to an existing feature. It used a lot of the same code as something already in the system. So I copied that into a new class (C#), made some (very minor) adjustments, and checked it in. We were able to launch the product on time. But now there was quite a lot of code duplication. Yes, I could have just "written it cleanly myself". But this was a tremendously complex product. We had unit tests, integration tests, and more. But we still had to perform hours of manual testing on any code that changed prior to a release. Refactoring the old code would have introduced more testing requirements, which slows down the entire release cycle - the risk was too great for our timeline. It's important to consider the total cost of your work, not just the amount of time a certain task takes you, individually. It's also worth noting, we made a new Jira ticket about the code duplication right away, and we were able to fix the code duplication in the next sprint, after the product release. The next iteration, 1.0.1, had the "correct / ideal" code.

dep_b 7y ago
Yeah, duplicating code that by itself isn't quite what I was getting at. I mean one big god class full of flags that is shared by two quite distinctive views that happen to share just a bit of functionality. In fact duplicating code in that particular scenario would perhaps have been a more sane thing to do but that didn't happen. It's just not helping me to ship something faster, slapping together crap. "Create new file" takes 15 seconds, adding a function there and calling it from the original class I was working in another 15. Debugging sessions to figure out where what flag in what condition was misplaced take 10 minutes. Every time. Where am I really winning time?