4 ms·

“Understand why you’re building it. If you’re building it, there should be value to your users and the business. What is that value? Do you agree with it?” Is

“Understand why you’re building it. If you’re building it, there should be value to your users and the business. What is that value? Do you agree with it?” Is that really your concern? If you are following the spec, it should be irrelevant - sometimes as an engineer you are not privy to how things will integrate until later, unless you have a real concern, the “value add” is irrelevant. I dislike these “non article articles” for exactly this reason, it just is not reflected in reality Edit: The whole article just annoyed me, I don’t know why, so maybe I’m just snapping at things

deleted 5y ago
[deleted]
jason-phillips 5y ago
The how and the why are what separates the garden variety codemonkey from the staff/principal levels.
- bennyp101 5y ago
  Yep,if you can do the how, then you’ll learn the why
Chris_Newton 5y ago
Is that really your concern? That surely depends upon both the individual’s role and the culture in the organisation, but I tend to agree with the original author. As a developer, I can often provide better results if I’m aware of the context and not operating in isolation. As a manager, I get better results from the people working for me if we’re communicating openly and often enough to address any questions or problems quickly, and this applies to software developers as much as any other field. Of course this matters more as you get more senior as a developer or perhaps start to take on hybrid roles like tech lead or software architect. However, in my experience the principle works very widely, except maybe for juniors who have enough to learn already and new starters who are still finding their way around. No doubt there are some projects where for legitimate security reasons there is a culture of need-to-know and compartmentalisation of information, but I suspect that across the industry as a whole, variations of wilful ignorance among developers do far more harm than good. It happens at large scale, like pigeonholing developers into narrow roles and trying to make everything possible into someone else’s problem. It happens at smaller scales, like being too dogmatic about pretending we have no idea what we’re going to be working on a few days or even a few hours later and stubbornly refusing to make any allowance for it in code we’re currently writing. That kind of culture can become toxic and unproductive, but it can often be fixed by sharing information more freely with those who might find it useful and then having those people take the extra context into account when making their own plans and decisions. A lot of the points in the article here could be specific examples of that general idea, and IMHO those are all sensible advice.
- bennyp101 5y ago
  Possibly not, but the article annoyed me. I think I agree with a lot of your post, but I do still disagree that everybody needs to be aware of the end goal.
  - Jtsummers 5y ago
    A lack of awareness of the purpose of work can often cause the work to be done in a way which harms the actual objective. This is because the internal group doing the work (without any insight into why or to what end) will have its own objectives and incentives that are distinct from or in conflict with the overall objective. In order for an internal group like this to function blindly, their incentive structure needs to be properly established by some other group with proper insight. So even if the people doing the work are blind to the purpose, the ones establishing their measures and controls cannot be blind. This can work, and often seems to work well enough, but it also can fail spectacularly. See the recent Ask HN discussion on Google's 50 billion messaging clients.
marcosdumay 5y ago
Hum... Are you talking from the point of view of a developer working in a feature fabric? If so, ok, your work will become much better if you ask those questions, but the party paying you does not care about it at all. You are just expected to deliver this feature. But if you have any amount of goal alignment with the people that will get the software (as little as wanting them to perceive your work is useful), you will get much better results by having a picture of what your software is supposed to do. If you do not have access to this information, it's relevant to be aware that you are not receiving all the tools you need to succeed.
- bennyp101 5y ago
  Sorry, I don’t know what feature fabric means?
  - Jtsummers 5y ago
    Probably "feature factory". A group that exists just to churn out what they're told to do, versus a group that works with their customers to build what the customers actually want/need.
    - marcosdumay 5y ago
      Yes, feature factory. Thanks. That was my native language pushing itself over English for a moment.
schwartzworld 5y ago
I can't count the number of times I've done these exact steps: - see a feature request that sounds weird. - ask what problem they are trying to solve - come up with a less weird / more useful solution. As engineers we have information and skills that designers and pms often lack. You can just build what you're asked to build and you'll be fine, but understanding the value that's added will make sure you build it better.
codingdave 5y ago
As a former developer, who now mostly writes those specs... Yes. Yes, I want my team to understand why. They do better when they understand. They have insights into what choices to make when writing the code. We have better conversations about the product and the work to enhance it. And they correct my errors. I'm not perfect just because I write specs, and I appreciate most of the suggestions and corrections that the devs bring to me.
Zababa 5y ago
> Is that really your concern? If you are following the spec, it should be irrelevant - sometimes as an engineer you are not privy to how things will integrate until later, unless you have a real concern, the “value add” is irrelevant. I have the opposite view, I think it matters a lot. As an engineer, I understand things better when I can see the "why". Being aware of the "why" means that I will follow more easily the spirit of the spec instead of just the word. It means I will be more aligned with the users, the business. All of these avoid the classic trap of having a dev team disconnected from the business, which usually leads to a bad atmosphere, late/failed projets.
- kwhitefoot 5y ago
  > follow more easily the spirit of the spec instead of just the word. It also allows you to use your experience and expertise to tell the writer of the spec that they have written a pile of junk and that what they are asking for is not what they need. Sometimes when I have done that I have also discovered that it was not what they wanted either but simply what they thought was practicable. Together we were able to thrash out a better spec that achieved the ends that were necessary. I wish that people would remember that the vast majority of people writing code are doing it inside the same company or even department that will be using the final program. It is often the case that at least some of the software developers in such teams have as much or more expertise in the domain as the customers commissioning the software; it would be a dereliction of duty to fail to question a specification that seemed pointless, inconsistent, or inadequate to the problem it was purported to solve.
  - Zababa 5y ago
    I agree. I noticed the same as you, when I talk to people; sometimes they don't know what's easy, what's hard or even what's possible to do with code. Talking to them and trying to understand what they're trying to do often leads to a better result.
asdfge4drg 5y ago
Understanding why you're doing something at the strategic level, helps you make decisions at the tactical level without having to go back up the chain every time. Without this knowledge, someone else has to make decisions that you are best placed to make.
plorkyeran 5y ago
I particularly don’t believe that it is possible to have a spec which does a good enough job of explaining what is needed that the implementor doesn’t need to know why. I’ve certainly never encountered such a thing, and all of the best specs I’ve worked with explain the why as well. It’s like claiming that your code doesn’t need any comments saying why things are done because you can see what is happening.
jcun4128 5y ago
I had a thought about this regarding not seeing users using what I built. I generally know what it's for (medical) but I just make it, it gets released, cool onto the next one. Only time I hear about it is if something is broken. On the other side I like seeing metrics/feedback of something I made get used. Always sad when a venture dies/nothing happens to it.

deleted 5y ago

[deleted]

jason-phillips 5y ago

The how and the why are what separates the garden variety codemonkey from the staff/principal levels.

bennyp101 5y ago
Yep,if you can do the how, then you’ll learn the why

Chris_Newton 5y ago

Is that really your concern? That surely depends upon both the individual’s role and the culture in the organisation, but I tend to agree with the original author. As a developer, I can often provide better results if I’m aware of the context and not operating in isolation. As a manager, I get better results from the people working for me if we’re communicating openly and often enough to address any questions or problems quickly, and this applies to software developers as much as any other field. Of course this matters more as you get more senior as a developer or perhaps start to take on hybrid roles like tech lead or software architect. However, in my experience the principle works very widely, except maybe for juniors who have enough to learn already and new starters who are still finding their way around. No doubt there are some projects where for legitimate security reasons there is a culture of need-to-know and compartmentalisation of information, but I suspect that across the industry as a whole, variations of wilful ignorance among developers do far more harm than good. It happens at large scale, like pigeonholing developers into narrow roles and trying to make everything possible into someone else’s problem. It happens at smaller scales, like being too dogmatic about pretending we have no idea what we’re going to be working on a few days or even a few hours later and stubbornly refusing to make any allowance for it in code we’re currently writing. That kind of culture can become toxic and unproductive, but it can often be fixed by sharing information more freely with those who might find it useful and then having those people take the extra context into account when making their own plans and decisions. A lot of the points in the article here could be specific examples of that general idea, and IMHO those are all sensible advice.

bennyp101 5y ago
Possibly not, but the article annoyed me. I think I agree with a lot of your post, but I do still disagree that everybody needs to be aware of the end goal.
- Jtsummers 5y ago
  A lack of awareness of the purpose of work can often cause the work to be done in a way which harms the actual objective. This is because the internal group doing the work (without any insight into why or to what end) will have its own objectives and incentives that are distinct from or in conflict with the overall objective. In order for an internal group like this to function blindly, their incentive structure needs to be properly established by some other group with proper insight. So even if the people doing the work are blind to the purpose, the ones establishing their measures and controls cannot be blind. This can work, and often seems to work well enough, but it also can fail spectacularly. See the recent Ask HN discussion on Google's 50 billion messaging clients.

marcosdumay 5y ago

Hum... Are you talking from the point of view of a developer working in a feature fabric? If so, ok, your work will become much better if you ask those questions, but the party paying you does not care about it at all. You are just expected to deliver this feature. But if you have any amount of goal alignment with the people that will get the software (as little as wanting them to perceive your work is useful), you will get much better results by having a picture of what your software is supposed to do. If you do not have access to this information, it's relevant to be aware that you are not receiving all the tools you need to succeed.

bennyp101 5y ago
Sorry, I don’t know what feature fabric means?
- Jtsummers 5y ago
  Probably "feature factory". A group that exists just to churn out what they're told to do, versus a group that works with their customers to build what the customers actually want/need.
  - marcosdumay 5y ago
    Yes, feature factory. Thanks. That was my native language pushing itself over English for a moment.

schwartzworld 5y ago

I can't count the number of times I've done these exact steps: - see a feature request that sounds weird. - ask what problem they are trying to solve - come up with a less weird / more useful solution. As engineers we have information and skills that designers and pms often lack. You can just build what you're asked to build and you'll be fine, but understanding the value that's added will make sure you build it better.

codingdave 5y ago

As a former developer, who now mostly writes those specs... Yes. Yes, I want my team to understand why. They do better when they understand. They have insights into what choices to make when writing the code. We have better conversations about the product and the work to enhance it. And they correct my errors. I'm not perfect just because I write specs, and I appreciate most of the suggestions and corrections that the devs bring to me.

Zababa 5y ago

> Is that really your concern? If you are following the spec, it should be irrelevant - sometimes as an engineer you are not privy to how things will integrate until later, unless you have a real concern, the “value add” is irrelevant. I have the opposite view, I think it matters a lot. As an engineer, I understand things better when I can see the "why". Being aware of the "why" means that I will follow more easily the spirit of the spec instead of just the word. It means I will be more aligned with the users, the business. All of these avoid the classic trap of having a dev team disconnected from the business, which usually leads to a bad atmosphere, late/failed projets.

kwhitefoot 5y ago
> follow more easily the spirit of the spec instead of just the word. It also allows you to use your experience and expertise to tell the writer of the spec that they have written a pile of junk and that what they are asking for is not what they need. Sometimes when I have done that I have also discovered that it was not what they wanted either but simply what they thought was practicable. Together we were able to thrash out a better spec that achieved the ends that were necessary. I wish that people would remember that the vast majority of people writing code are doing it inside the same company or even department that will be using the final program. It is often the case that at least some of the software developers in such teams have as much or more expertise in the domain as the customers commissioning the software; it would be a dereliction of duty to fail to question a specification that seemed pointless, inconsistent, or inadequate to the problem it was purported to solve.
- Zababa 5y ago
  I agree. I noticed the same as you, when I talk to people; sometimes they don't know what's easy, what's hard or even what's possible to do with code. Talking to them and trying to understand what they're trying to do often leads to a better result.

asdfge4drg 5y ago

Understanding why you're doing something at the strategic level, helps you make decisions at the tactical level without having to go back up the chain every time. Without this knowledge, someone else has to make decisions that you are best placed to make.

plorkyeran 5y ago

I particularly don’t believe that it is possible to have a spec which does a good enough job of explaining what is needed that the implementor doesn’t need to know why. I’ve certainly never encountered such a thing, and all of the best specs I’ve worked with explain the why as well. It’s like claiming that your code doesn’t need any comments saying why things are done because you can see what is happening.

jcun4128 5y ago

I had a thought about this regarding not seeing users using what I built. I generally know what it's for (medical) but I just make it, it gets released, cool onto the next one. Only time I hear about it is if something is broken. On the other side I like seeing metrics/feedback of something I made get used. Always sad when a venture dies/nothing happens to it.