3 ms·

> In my opinion, only the extremely good developers seem to comprehend that they are almost always writing what will be considered the "technical debt" of 5 yea

> In my opinion, only the extremely good developers seem to comprehend that they are almost always writing what will be considered the "technical debt" of 5 years from now when paradigms shift again. I've also seen really bad developers with that attitude: it's all crap, so just ship whatever already. The good developers write code that can be replaced, rewritten, or rescaled later. Though, charitably, both monolithic service and microservice people are trying to do exactly that. It's just what sort of scale they're thinking about and what part of the software development lifecycle they think will be especially difficult going forward.

elgenie 9y ago
The critical distinction between "it's all crap, so just ship whatever already" and what the grandparent wrote is that "technical debt" doesn't reside in easily disposable code/components, but rather as may-need-to-be-rectified-but-maybe-not-right-now downsides in what is enormously useful and producing value. Good developers create code that's prepared for the possibility of being modified repeatedly and becoming foundational; on the other hand, preparing for code/components to be thrown away is a no-op.
- humanrebar 9y ago
  > ...preparing for code/components to be thrown away is a no-op. You might be agreeing, but I find that the bad code that sticks around is bad code that is hard to get rid of. So in that sense, code that is removable isn't a no-op. It takes some effort, for instance, to keep a clear dividing line between two components so that either may be replaced someday.
foo101 9y ago
> The good developers write code that can be replaced, rewritten, or rescaled later. You make a very good point. Over the years, I learnt that almost nobody except the developer and maybe one or two peer-developers cares about good quality code. The management just wants to ship services/products. They don't care how good the code is. All they care is that they can meet their deadlines. Of course, good quality code can increase the chance of meeting deadlines, but working long hours can also increase the chance of meeting deadlines. Management does not understand code, but they understand working long hours. If I ignore this and still care enough to write good quality code, in nearly all projects, I am not going to be the only one to work on the code. There is going to be a time, when someone else has to work on the code (because responsibilities change, or because I am busy with some other project). As per my anecdata, the number of people who do not care about code quality far exceeds those who do. So this new person would most likely start developing his features on the existing clean code in a chaotic manner without sufficient thought or design. So any carefully written code also tends to become ugly in the long term. In many cases, you know that you yourself would move out the project/organization to another project/organization in a year or so, and the code would become ugly in the long term no matter what you do, so why bother writing good code in the first place! It is very disappointing to me that the field of programming and software development that I once used to love so much out of passion has turned out to be such a commercial, artless, and dispassionate field. How do you retain your motivation to be a good developer in such a situation?
- BatFastard 9y ago
  There are good organizations out there, at least teams that are good. Problem is most organizations are just in it for the short term...
- deleted 9y ago
  [deleted]
- mauritzio 9y ago
  Maybe go to where hardcore stuff is done? Compilers or Spaceships satellites airplanes? I've no idea... :/ Tell me if you find one. I just stopped it and started drawing again at least anyone can 'see' it. Well modern art is a lot of bullshit too ;)
- brain5ide 9y ago
  I think that's a problem of money flooding the gates. Until just recently I was afraid of the tech bubble popping, but with seeing people, who never cared or understood tech entering the field I'm afraid it may never pop. Of course, if I was any good I shouldn't care about that and be working my own way, but that's not the case.
- virgilp 9y ago
  > good quality code can increase the chance of meeting deadlines, but working long hours can also increase the chance of meeting deadlines. No, that's not true, except in a very superficial sense. Yes long hours _can_ increase the chance of meeting deadlines... but often, it doesn't - or more precisely, it only works if the code quality is decent. "Code quality" is not about following whatever patterns are en vogue today, or using the latest dev language. It is mostly about simplicity - dealing with few things at a time, and making those things explicit. If you need to understand the entire solution, and the entire domain model, and all the edge cases before making the tiniest of modifications - long hours are not going to help you. To go back to microservices: many companies claim to build microservices, but actually build a distributed monolith. This doesn't help productivity, it actively harms it.
  - dkersten 9y ago

elgenie 9y ago

The critical distinction between "it's all crap, so just ship whatever already" and what the grandparent wrote is that "technical debt" doesn't reside in easily disposable code/components, but rather as may-need-to-be-rectified-but-maybe-not-right-now downsides in what is enormously useful and producing value. Good developers create code that's prepared for the possibility of being modified repeatedly and becoming foundational; on the other hand, preparing for code/components to be thrown away is a no-op.

humanrebar 9y ago
> ...preparing for code/components to be thrown away is a no-op. You might be agreeing, but I find that the bad code that sticks around is bad code that is hard to get rid of. So in that sense, code that is removable isn't a no-op. It takes some effort, for instance, to keep a clear dividing line between two components so that either may be replaced someday.

foo101 9y ago

> The good developers write code that can be replaced, rewritten, or rescaled later. You make a very good point. Over the years, I learnt that almost nobody except the developer and maybe one or two peer-developers cares about good quality code. The management just wants to ship services/products. They don't care how good the code is. All they care is that they can meet their deadlines. Of course, good quality code can increase the chance of meeting deadlines, but working long hours can also increase the chance of meeting deadlines. Management does not understand code, but they understand working long hours. If I ignore this and still care enough to write good quality code, in nearly all projects, I am not going to be the only one to work on the code. There is going to be a time, when someone else has to work on the code (because responsibilities change, or because I am busy with some other project). As per my anecdata, the number of people who do not care about code quality far exceeds those who do. So this new person would most likely start developing his features on the existing clean code in a chaotic manner without sufficient thought or design. So any carefully written code also tends to become ugly in the long term. In many cases, you know that you yourself would move out the project/organization to another project/organization in a year or so, and the code would become ugly in the long term no matter what you do, so why bother writing good code in the first place! It is very disappointing to me that the field of programming and software development that I once used to love so much out of passion has turned out to be such a commercial, artless, and dispassionate field. How do you retain your motivation to be a good developer in such a situation?

BatFastard 9y ago
There are good organizations out there, at least teams that are good. Problem is most organizations are just in it for the short term...
deleted 9y ago
[deleted]
mauritzio 9y ago
Maybe go to where hardcore stuff is done? Compilers or Spaceships satellites airplanes? I've no idea... :/ Tell me if you find one. I just stopped it and started drawing again at least anyone can 'see' it. Well modern art is a lot of bullshit too ;)
brain5ide 9y ago
I think that's a problem of money flooding the gates. Until just recently I was afraid of the tech bubble popping, but with seeing people, who never cared or understood tech entering the field I'm afraid it may never pop. Of course, if I was any good I shouldn't care about that and be working my own way, but that's not the case.
virgilp 9y ago
> good quality code can increase the chance of meeting deadlines, but working long hours can also increase the chance of meeting deadlines. No, that's not true, except in a very superficial sense. Yes long hours _can_ increase the chance of meeting deadlines... but often, it doesn't - or more precisely, it only works if the code quality is decent. "Code quality" is not about following whatever patterns are en vogue today, or using the latest dev language. It is mostly about simplicity - dealing with few things at a time, and making those things explicit. If you need to understand the entire solution, and the entire domain model, and all the edge cases before making the tiniest of modifications - long hours are not going to help you. To go back to microservices: many companies claim to build microservices, but actually build a distributed monolith. This doesn't help productivity, it actively harms it.
- dkersten 9y ago