5 ms·

That's the everyday struggle; as developers we can produce so much wealth just by typing at a keyboard. Yet we let ourselves be controlled by people who don't k

by omouse 11y ago

That's the everyday struggle; as developers we can produce so much wealth just by typing at a keyboard. Yet we let ourselves be controlled by people who don't know what's what and can't even prove their ideas have any return on investment. As you say, don't make magic happen. It doesn't matter how cool it would be if, or how you think you'll show them your ideas are better; when you say "it cannot be done" don't go and try and do it. Don't let the manager bully you and don't let them try and get another developer to tackle the impossible. I've had that happen to me where I said it will take X amount of time to do it so let's not do it till next sprint. Then the manager went around my back when I was gone for a day and gave the task to another dev. The dev, who caused the mess, of course was able to fix it within an hour. Why did I say X amount of time? To cleanup and make sure the bug stays fixed. When you work with other developers, actually work together. Stand up for them, don't make bad comments about them, and always stick together when you're asked to do the impossible.

sokoloff 11y ago
If I understand your story correctly, that other dev accomplished the task in some characteristically short amount of time, plus an hour for fixing a bug. While you didn't specify what your "X" was, it sounds like the manager (and the company) got a better outcome by going around you and it was far from being "asked to do the impossible".
- _asummers 11y ago
  I believe his point was that there's often a difference between finishing the task and actually fixing the issue.
- collyw 11y ago
  Because the quickest way to fix something is usually the most robust solution for the long term?
- omouse 11y ago
  I'm not going to slag on the developer; the manager got a better short term outcome. The longer than 1 week outcome is that I've had to go back and re-visit that code and make sure it's "done done for reals it's done" due to the lack of unit tests and thorough thought given to it. On a long enough timeline, the better outcome turns into multiple bugs.
moron4hire 11y ago
This is what I'm talking about with offering the alternatives. You can't hide the distasteful "make the pain go away, but not fix the underlying problem" option. You have to give people enough rope to hang themselves, which is thankfully also the same thing as giving them the opportunity to surprise you with their leadership. When you have a heavy-handed PM over you, you have to give them all the information, force the decision on them. Don't make the decisions for them that option A or option B is best. If they want to lead, they have to take responsibility for this stuff. It's up to you to present the options appropriately. "A) I hide the bug, maybe takes an hour, B) I fix it, probably takes a week". You don't know, you might be surprised, he might tell you "do both, A right now then get right on B." Or he might only be interested in A. Either way, if you don't want responsibility for the failures, you have to abdicate responsibility for the successes.
7Figures2Commas 11y ago
> That's the everyday struggle; as developers we can produce so much wealth just by typing at a keyboard. Yet we let ourselves be controlled by people who don't know what's what and can't even prove their ideas have any return on investment. That's the everyday misconception. Nobody produces wealth just by typing at a keyboard. Products don't design and sell themselves and it's arrogant to pretend that product people and salespeople aren't a huge part of the value creation process in tech. There are of course developers who are capable of identifying a market opportunity, conceptualizing a product to exploit the opportunity, building the actual product and getting it into market successfully. But if this is common, why are so many talented developers sitting at desks in open office spaces working 10-12 hours a day for low six figure salaries?
- omouse 11y ago
  > That's the everyday misconception. Nobody produces wealth just by typing at a keyboard. Products don't design and sell themselves and it's arrogant to pretend that product people and salespeople aren't a huge part of the value creation process in tech. Okay you've got a point, it is fairly arrogant; on the other hand, any sort of automation or small script or product is valuable enough that we don't need to be subservient. > But if this is common, why are so many talented developers sitting at desks in open office spaces working 10-12 hours a day for low six figure salaries? That's what I'm asking, why are talented developers allowing themselves to be subservient? That's why I'm wondering why technical managers all the way up to the CTO level are subservient to other departments when it's the product based on technology that determines the success of the company in the end? And actually, your idea is optimistic; I wouldn't mind low six figures for 10-12 hours a day ;) maybe that's why we're so subservient, we look at our peers in other industries and they're making much less cash money and it's easy to see that we're lucky to be working in a nice air-conditioned office working with something we're typically passionate about.
  - 7Figures2Commas 11y ago
    > That's what I'm asking, why are talented developers allowing themselves to be subservient? Answer: trying to get a real product to market successfully requires a lot more than small scripts that automate processes. It's not that automation and the like doesn't have value, but ask the average developer to get on the phone and sell something, or to have a meaningful conversation with a customer, and you might start to understand why other people in an organization (salespeople, product managers, etc.) have some sway too. If you simply put a bunch of talented developers in a room, chances are you're not going to end up with a successful business.

by omouse 11y ago

sokoloff 11y ago

If I understand your story correctly, that other dev accomplished the task in some characteristically short amount of time, plus an hour for fixing a bug. While you didn't specify what your "X" was, it sounds like the manager (and the company) got a better outcome by going around you and it was far from being "asked to do the impossible".

_asummers 11y ago
I believe his point was that there's often a difference between finishing the task and actually fixing the issue.
collyw 11y ago
Because the quickest way to fix something is usually the most robust solution for the long term?
omouse 11y ago
I'm not going to slag on the developer; the manager got a better short term outcome. The longer than 1 week outcome is that I've had to go back and re-visit that code and make sure it's "done done for reals it's done" due to the lack of unit tests and thorough thought given to it. On a long enough timeline, the better outcome turns into multiple bugs.

moron4hire 11y ago

This is what I'm talking about with offering the alternatives. You can't hide the distasteful "make the pain go away, but not fix the underlying problem" option. You have to give people enough rope to hang themselves, which is thankfully also the same thing as giving them the opportunity to surprise you with their leadership. When you have a heavy-handed PM over you, you have to give them all the information, force the decision on them. Don't make the decisions for them that option A or option B is best. If they want to lead, they have to take responsibility for this stuff. It's up to you to present the options appropriately. "A) I hide the bug, maybe takes an hour, B) I fix it, probably takes a week". You don't know, you might be surprised, he might tell you "do both, A right now then get right on B." Or he might only be interested in A. Either way, if you don't want responsibility for the failures, you have to abdicate responsibility for the successes.

7Figures2Commas 11y ago

> That's the everyday struggle; as developers we can produce so much wealth just by typing at a keyboard. Yet we let ourselves be controlled by people who don't know what's what and can't even prove their ideas have any return on investment. That's the everyday misconception. Nobody produces wealth just by typing at a keyboard. Products don't design and sell themselves and it's arrogant to pretend that product people and salespeople aren't a huge part of the value creation process in tech. There are of course developers who are capable of identifying a market opportunity, conceptualizing a product to exploit the opportunity, building the actual product and getting it into market successfully. But if this is common, why are so many talented developers sitting at desks in open office spaces working 10-12 hours a day for low six figure salaries?

omouse 11y ago
> That's the everyday misconception. Nobody produces wealth just by typing at a keyboard. Products don't design and sell themselves and it's arrogant to pretend that product people and salespeople aren't a huge part of the value creation process in tech. Okay you've got a point, it is fairly arrogant; on the other hand, any sort of automation or small script or product is valuable enough that we don't need to be subservient. > But if this is common, why are so many talented developers sitting at desks in open office spaces working 10-12 hours a day for low six figure salaries? That's what I'm asking, why are talented developers allowing themselves to be subservient? That's why I'm wondering why technical managers all the way up to the CTO level are subservient to other departments when it's the product based on technology that determines the success of the company in the end? And actually, your idea is optimistic; I wouldn't mind low six figures for 10-12 hours a day ;) maybe that's why we're so subservient, we look at our peers in other industries and they're making much less cash money and it's easy to see that we're lucky to be working in a nice air-conditioned office working with something we're typically passionate about.
- 7Figures2Commas 11y ago
  > That's what I'm asking, why are talented developers allowing themselves to be subservient? Answer: trying to get a real product to market successfully requires a lot more than small scripts that automate processes. It's not that automation and the like doesn't have value, but ask the average developer to get on the phone and sell something, or to have a meaningful conversation with a customer, and you might start to understand why other people in an organization (salespeople, product managers, etc.) have some sway too. If you simply put a bunch of talented developers in a room, chances are you're not going to end up with a successful business.