5 ms·

But that's exactly the kind of employee that most businesses want: interchangeable bricklayers. I get that getting good developers and facilitating good code r

But that's exactly the kind of employee that most businesses want: interchangeable bricklayers. I get that getting good developers and facilitating good code requires incentives, but this is usually at odds with the perspective of business owners, which is that employees are both a liability and an asset. Lousy developers are (seemingly) low-liability and good assets because they can make it work for cheap and, if something goes wrong in the future because of all the spaghetti code, that's when you can hire the good developers to come clean up the mess.

wolco 7y ago
The truth is spaghetti works better for the ever changing requirement. After awhile the product gets rewritten.
- johnsimer 7y ago
  IMO this is extremely false Clean code is most valuable in the fact that you can add new features without old ones breaking You should be able to write clean code from the start without it ever being classified as spaghetti as long as you stick to principles like Law of Demeter, SOLID, etc
  - childintime 7y ago
    I deal (and compete) with smart but professionally mediocre programmers (and hardware designers). Their knowledge is usually limited, but they get 80% of the job done and the customer need is addressed. Only when the product gets used in a non-typical way or in non-typical circumstances, do the (inevitable) bugs appear. They didn't think their design choices through or they didn't know the limitations of the tool used. So bugs are considered a known risk, and are managed. Hardware, for example, is swapped under guarantee. The most ugly bugs are fixed, and others are too costly and wait until a redesign. But the employer likes their qualities: - he gets a mostly rapid schedule, - he gets an employee that doesn't get lost in abstractions, and - he gets to charge the customer again for the next major iteration Basically they get him an MVP, and the customer keeps paying for each design iteration. We all know how important that is to the bottom line. To him Quality is optional, like benefits are to a job: they end up being important, but the salary usually comes first.
PopeDotNinja 7y ago
> But that's exactly the kind of employee that most businesses want: interchangeable bricklayers. That's what they want... until their needs change. I did a contract at a company where I was the test automation guy. The dev team didn't want to right tests, and they were happy to convert requirements thrown over wall A into the code the threw over wall B. The QA team caught the wall B code, and threw their results over wall D. Things took forever, but everyone was happy... until pressure to ship faster started to come down from the top. To speed things up, they hired me to automate all the things. Well, the dev team weren't interested in helping me learn anything, and the dev manager even told me to my face that he wouldn't ass test coverage unless management asked him to & gave him extra time to make that happen. The QA team weren't coders, and they didn't really have any incentive to help me make things go faster. The build & release guy wasn't interested in getting tests integrated into the Rube Goldberg of a process that he managed. They were all great bricklayers who told themselves they were agile because they had 1 week sprints, daily stand ups, and a all sorts of other processes. But when taking forever was no longer good enough, instead of trying to grow with it, they resisted & fought it. My role was pretty miserable, and I quit after a few months. On my way out the door, I learned that I was like the 5th person to walk, and they were planning on seeking interchangeable bricklayer #6. In my experience, companies want interchangeable bricklayers, but they usually don't usually like the results of what they asked for.
- WrtCdEvrydy 7y ago
  > but they usually don't usually like the results of what they asked for. We're not allowed to say it work because someone thought it was a race thing but... 'pay peanuts, get monkeys'
- draw_down 7y ago
  Their problems sound a lot bigger than "too many bricklayers".
- james_s_tayler 7y ago
  That's a totally broken culture / machine. Unfortunately, they're out there.

wolco 7y ago

The truth is spaghetti works better for the ever changing requirement. After awhile the product gets rewritten.

johnsimer 7y ago
IMO this is extremely false Clean code is most valuable in the fact that you can add new features without old ones breaking You should be able to write clean code from the start without it ever being classified as spaghetti as long as you stick to principles like Law of Demeter, SOLID, etc
- childintime 7y ago
  I deal (and compete) with smart but professionally mediocre programmers (and hardware designers). Their knowledge is usually limited, but they get 80% of the job done and the customer need is addressed. Only when the product gets used in a non-typical way or in non-typical circumstances, do the (inevitable) bugs appear. They didn't think their design choices through or they didn't know the limitations of the tool used. So bugs are considered a known risk, and are managed. Hardware, for example, is swapped under guarantee. The most ugly bugs are fixed, and others are too costly and wait until a redesign. But the employer likes their qualities: - he gets a mostly rapid schedule, - he gets an employee that doesn't get lost in abstractions, and - he gets to charge the customer again for the next major iteration Basically they get him an MVP, and the customer keeps paying for each design iteration. We all know how important that is to the bottom line. To him Quality is optional, like benefits are to a job: they end up being important, but the salary usually comes first.

PopeDotNinja 7y ago

> But that's exactly the kind of employee that most businesses want: interchangeable bricklayers. That's what they want... until their needs change. I did a contract at a company where I was the test automation guy. The dev team didn't want to right tests, and they were happy to convert requirements thrown over wall A into the code the threw over wall B. The QA team caught the wall B code, and threw their results over wall D. Things took forever, but everyone was happy... until pressure to ship faster started to come down from the top. To speed things up, they hired me to automate all the things. Well, the dev team weren't interested in helping me learn anything, and the dev manager even told me to my face that he wouldn't ass test coverage unless management asked him to & gave him extra time to make that happen. The QA team weren't coders, and they didn't really have any incentive to help me make things go faster. The build & release guy wasn't interested in getting tests integrated into the Rube Goldberg of a process that he managed. They were all great bricklayers who told themselves they were agile because they had 1 week sprints, daily stand ups, and a all sorts of other processes. But when taking forever was no longer good enough, instead of trying to grow with it, they resisted & fought it. My role was pretty miserable, and I quit after a few months. On my way out the door, I learned that I was like the 5th person to walk, and they were planning on seeking interchangeable bricklayer #6. In my experience, companies want interchangeable bricklayers, but they usually don't usually like the results of what they asked for.

WrtCdEvrydy 7y ago
> but they usually don't usually like the results of what they asked for. We're not allowed to say it work because someone thought it was a race thing but... 'pay peanuts, get monkeys'
draw_down 7y ago
Their problems sound a lot bigger than "too many bricklayers".
james_s_tayler 7y ago
That's a totally broken culture / machine. Unfortunately, they're out there.