5 ms·

"The most experienced programmer uses hacks all the time; the important part is that you're getting stuff done." I couldn't disagree more, the grown up program

"The most experienced programmer uses hacks all the time; the important part is that you're getting stuff done." I couldn't disagree more, the grown up programmers use a strategic approach, not a tactical one. As Jonh Ousterhout put it in his book A Philosophy of Software Design "The first step towards becoming a good software designer is to realize that working code isn't enough."

rooam-dev 7y ago
100% agree. The "hacks" and "get stuff done" approach gains quick and short benefit, which probably fits a freelancer/contractor role. Maintainable and testable code should be implied. It's not about how fast you get to code to production, it's about how fast code/product can be adapted to new or unexpected requirements.
- gazelle21 7y ago
  That sounds great but in real life, when your boss wants his crud app fixed yesterday and the previous dev left no documentation for random code, you have to do what you have to do.
ewidar 7y ago
Judging by the rest of the article, I don't think the author is advocating pushing hacks to production. But rather to use hacks to move forward, and then improve once you have a working version.
apotheon 7y ago
Elsewhere in this discussion, I described my first Flux experience. In that same job, the boss decided (after we switched to a pseudo-Flux, Frankenstein's monster of MVC component libs that slowed development to an excruciating crawl) to bring in a consultant to "help". He was the "crap out apparently-working code quickly" brand of "10x Programmer". Some basic functionality for new features got added in a hurry, over a couple weeks' time. The following couple weeks were dedicated to fixing everything he wrote. Yes, I agree: "grown up" programmers think beyond what seems to work right now. Sure, I use dirty hacks semi-regularly, but only when I'm first feeling out how something works. It doesn't last more than a couple hours, usually far less, because the point isn't to commit that code but to learn how to think about the problem so I can do it right, and a "done right" rewrite takes less time to get working than the initial dirty hack. The "done right" rewrite also doesn't impose tremendous maintenance and continuing development costs over months to come the way the dirty hack would. If the author means real programmers use dirty hacks to figure out what they're doing, then they make it right, that's fine. If not, that's not fine at all.

rooam-dev 7y ago

100% agree. The "hacks" and "get stuff done" approach gains quick and short benefit, which probably fits a freelancer/contractor role. Maintainable and testable code should be implied. It's not about how fast you get to code to production, it's about how fast code/product can be adapted to new or unexpected requirements.

gazelle21 7y ago
That sounds great but in real life, when your boss wants his crud app fixed yesterday and the previous dev left no documentation for random code, you have to do what you have to do.

ewidar 7y ago

Judging by the rest of the article, I don't think the author is advocating pushing hacks to production. But rather to use hacks to move forward, and then improve once you have a working version.

apotheon 7y ago

Elsewhere in this discussion, I described my first Flux experience. In that same job, the boss decided (after we switched to a pseudo-Flux, Frankenstein's monster of MVC component libs that slowed development to an excruciating crawl) to bring in a consultant to "help". He was the "crap out apparently-working code quickly" brand of "10x Programmer". Some basic functionality for new features got added in a hurry, over a couple weeks' time. The following couple weeks were dedicated to fixing everything he wrote. Yes, I agree: "grown up" programmers think beyond what seems to work right now. Sure, I use dirty hacks semi-regularly, but only when I'm first feeling out how something works. It doesn't last more than a couple hours, usually far less, because the point isn't to commit that code but to learn how to think about the problem so I can do it right, and a "done right" rewrite takes less time to get working than the initial dirty hack. The "done right" rewrite also doesn't impose tremendous maintenance and continuing development costs over months to come the way the dirty hack would. If the author means real programmers use dirty hacks to figure out what they're doing, then they make it right, that's fine. If not, that's not fine at all.