4 ms·

meh. i work at a small shop. most of the code i see that sucks was written by competent programmers under high schedule pressure. the code is clearly not well u

meh. i work at a small shop. most of the code i see that sucks was written by competent programmers under high schedule pressure. the code is clearly not well understood anymore, but if you trace the history you can see it's due to a few years of tacking on features as quickly as possible. the technical debt surely slows us down sometimes, but hey that was a business decision, maybe even a correct one! core business functionality is rock solid, its mostly UI code that sucks. I wonder what the average startup codebase looks like?

david927 15y ago
I get tired of the "blame the shitty programmers" line of thought. We're all shitty programmers. Yet we all "understand variable scope" and "what the code was supposed to do." Some of us have such a large ego that we think it's others. No, Sancho. It's you. Code gets complex as hell very quickly. If it was building a house, it would be built in a week and architected on the fly. The person mixing the concrete, who has to know the concrete grade and drying time, also has to know that the upstairs has just shifted and now the load is too much on the center beam. The reality is that, unless your dealing with tiny apps, that "bad programmer"? It's you.
- true_religion 15y ago
  I've seen applications with fairly large scope that have clean code. For the most part the Django codebase has clean code, and its rapidly understandable. Where that's not true is the original SQL db, and the Forms library. Elsewhere its a dream to hack with. I'd also praise the codebase of SQLite, and Lighttpd---these two are very clean.
  - dustingetz 15y ago
    good low level backend stuff takes years of iteration under static business requirements. its also a well-understood domain with many prior implementations to learn from, and the 'companies' tend to be product-based so you have much less customer pressure. teams reacting to changing or poorly-understood requirements (think enterprise and defense software contracts) have a much harder task. nobody has solved the problem before, nobody understands the problem, and project managagement is typically forced into waterfall in order to make sales, so its not like there's time to redo things that get duct-taped together, if the duct-tape holds.
- Kisil 15y ago
  I agree that we are too slow to point the blame at ourselves. It's healthy to be self-critical. That said, there are programmers who are legitimately lacking both in basic skills and desire to attain those skills. It's orthogonal to the problem you're talking about, but these people do exist, and they're not as uncommon as one might hope. I can teach the difference between pointers and references; I can't teach you to care.
  - dodecaphonic 15y ago
    This. I have ascended to a managerial position a couple of years ago, rising from the ranks to steer what used to by a group of my peers. A lot of cruft had been ailing the team for years, but one guy stood out: he had been fired, rehired and now acted as if there was nothing he could do to damage his standing in the team. When we were peers, it bothered me; when I became his boss, I really tried to sway his attention into the product, into learning, into becoming more than a "drag this out of the component box" programmer. Needless to say, it failed. The guy was irreparably lazy, and trying to get him excited about building the things we are fortunate enough to get paid to build only made him try to put me under a bus when he got the chance. I had to let him go, and have slept better ever since.
- jt2190 15y ago
  That's SENIOR Sancho to you, bub. :-p

david927 15y ago

I get tired of the "blame the shitty programmers" line of thought. We're all shitty programmers. Yet we all "understand variable scope" and "what the code was supposed to do." Some of us have such a large ego that we think it's others. No, Sancho. It's you. Code gets complex as hell very quickly. If it was building a house, it would be built in a week and architected on the fly. The person mixing the concrete, who has to know the concrete grade and drying time, also has to know that the upstairs has just shifted and now the load is too much on the center beam. The reality is that, unless your dealing with tiny apps, that "bad programmer"? It's you.

true_religion 15y ago
I've seen applications with fairly large scope that have clean code. For the most part the Django codebase has clean code, and its rapidly understandable. Where that's not true is the original SQL db, and the Forms library. Elsewhere its a dream to hack with. I'd also praise the codebase of SQLite, and Lighttpd---these two are very clean.
- dustingetz 15y ago
  good low level backend stuff takes years of iteration under static business requirements. its also a well-understood domain with many prior implementations to learn from, and the 'companies' tend to be product-based so you have much less customer pressure. teams reacting to changing or poorly-understood requirements (think enterprise and defense software contracts) have a much harder task. nobody has solved the problem before, nobody understands the problem, and project managagement is typically forced into waterfall in order to make sales, so its not like there's time to redo things that get duct-taped together, if the duct-tape holds.
Kisil 15y ago
I agree that we are too slow to point the blame at ourselves. It's healthy to be self-critical. That said, there are programmers who are legitimately lacking both in basic skills and desire to attain those skills. It's orthogonal to the problem you're talking about, but these people do exist, and they're not as uncommon as one might hope. I can teach the difference between pointers and references; I can't teach you to care.
- dodecaphonic 15y ago
  This. I have ascended to a managerial position a couple of years ago, rising from the ranks to steer what used to by a group of my peers. A lot of cruft had been ailing the team for years, but one guy stood out: he had been fired, rehired and now acted as if there was nothing he could do to damage his standing in the team. When we were peers, it bothered me; when I became his boss, I really tried to sway his attention into the product, into learning, into becoming more than a "drag this out of the component box" programmer. Needless to say, it failed. The guy was irreparably lazy, and trying to get him excited about building the things we are fortunate enough to get paid to build only made him try to put me under a bus when he got the chance. I had to let him go, and have slept better ever since.
jt2190 15y ago
That's SENIOR Sancho to you, bub. :-p