2 ms·

Code is an expression of a business solution. The meat of any application is in the business rules it enables and enforces. In a very well oiled machine it migh

Code is an expression of a business solution. The meat of any application is in the business rules it enables and enforces. In a very well oiled machine it might be possible to just receive some behavioral requirements and get to it, but in my experience that isn't the norm. To be an effective engineer, you need to have a solid understanding of how the code you're writing solves the needs of the company.

worik 4y ago
Unpacking that: > Code is an expression of a business solution At some very high level that may be true. The person who makes the final decision on what code I work on (who happens to be the brother of the CEO, poor fellow!) may have to consider "business requirements", but only lightly. We implement what we are told to implement. I am a worker. > The meat of any application is in the business rules it enables and enforces No. That is crazy, and very high level. Where I work the "meat" is tight loops, memory allocation, network latency, data reliability.... > To be an effective engineer I have not been to Engineering School. I am not an engineer. Engineers are people who have been to engineering school. I am a computer programmer working on low level iOS plumbing. "Engineer"? Huh! Putting on airs, I do not do that. > To be an effective engineer, you need to have a solid understanding of how the code you're writing solves the needs of the company. To be an effective computer programmer I have to understand the requirements that my firm has of the hardware. I can give very good advice about whether the hardware can be persuaded to do what they want. I cannot give (good or valuable) business advice about whether the things the firm wants are the correct things. I understand a lot of people here really want to be successful "founders" and come at it from an engineering perspective. Very good. It is different for them than for me. A lot of us (at least one of us...) here are workers who want to do a job, for a salary. Happy to work for one of those founders if the money is right. (I have to make a business decision about who I work for, in the best scenario. In my case I took what I could get, and got lucky - thank you universe!) I am not qualified (I am actually, another story) and am not employed to give business advice, or to care. I am more valuable to everybody if I stick to my knitting.
- danielvaughn 4y ago
  You’re not unpacking anything in what I said, you’re just disagreeing with each point, and each disagreement is mostly rooted in a misunderstanding of what I’m saying. My point is that the code, and all it’s material constructs that you pointed out (loops, allocation etc), do not exist apart from the business, because it’s the only reason those things exist in the first place. I’m not sure how much experience you have, but if you have enough, you should know how easy it is for an engineering team to become disconnected with the goals of the company. I’ve seen devs waste literal months on things that, had the primary stakeholders known about it, they’d never have agreed to. Now, you could look at that situation and envy the job security. Sure you could just see yourself as just a cog in the machine, with no responsibility whatsoever in wondering why the fuck you’re doing what you’re doing. But I certainly would not hire you.
  - michaelcampbell 4y ago
    > Sure you could just see yourself as just a cog in the machine, with no responsibility whatsoever in wondering why the fuck you’re doing what you’re doing. But I certainly would not hire you. But there are lots, and LOTS of people who would, and want EXACTLY THAT. They want people to be told what to do, and do it, and not question why.
    - danielvaughn 4y ago
      Yep, and maybe I was being too harsh in how I said it. It's an understandable sentiment; I've just never seen it work in practice. Inevitably, the team (over time) begins to move orthogonally to the company. Like I said above, you'd need a very well-oiled machine, ala a super tight chain of command with clear directives at each layer. I see it in the same way I see security. A company is only as secure as its most vulnerable employee, so everyone must be vigilant about their own personal security practices. Same goes for "product security" - ensuring that the micro-actions taken by each IC reflect the company's objectives. It's an all-hands-on-deck practice.
  - worik 4y ago
    > code, and all it’s material constructs that you pointed out (loops, allocation etc), do not exist apart from the business, because it’s the only reason those things exist in the first place. I What else is that true for? All the way down. Biology, chemistry, physics, quantum physics.... All that we work on exists in those contexts too. Yet we just swim in the sea and ignore the water. The same is true of business matters. They are the ocean I swim in > I’ve seen devs waste literal months on things that, had the primary stakeholders known about it, they’d never have agreed to. That is poor communication. Communication is a necessary skill for all cooperative endeavours. I am a cog in a machine. Unusually for some one in my position I actually have a good understanding of business (studied it for years) and I prefer computer programming. Having computer programmers stick their oar in over financial matters, unasked, is not good. So I do not do it. I know my place, I like my place.

worik 4y ago

Unpacking that: > Code is an expression of a business solution At some very high level that may be true. The person who makes the final decision on what code I work on (who happens to be the brother of the CEO, poor fellow!) may have to consider "business requirements", but only lightly. We implement what we are told to implement. I am a worker. > The meat of any application is in the business rules it enables and enforces No. That is crazy, and very high level. Where I work the "meat" is tight loops, memory allocation, network latency, data reliability.... > To be an effective engineer I have not been to Engineering School. I am not an engineer. Engineers are people who have been to engineering school. I am a computer programmer working on low level iOS plumbing. "Engineer"? Huh! Putting on airs, I do not do that. > To be an effective engineer, you need to have a solid understanding of how the code you're writing solves the needs of the company. To be an effective computer programmer I have to understand the requirements that my firm has of the hardware. I can give very good advice about whether the hardware can be persuaded to do what they want. I cannot give (good or valuable) business advice about whether the things the firm wants are the correct things. I understand a lot of people here really want to be successful "founders" and come at it from an engineering perspective. Very good. It is different for them than for me. A lot of us (at least one of us...) here are workers who want to do a job, for a salary. Happy to work for one of those founders if the money is right. (I have to make a business decision about who I work for, in the best scenario. In my case I took what I could get, and got lucky - thank you universe!) I am not qualified (I am actually, another story) and am not employed to give business advice, or to care. I am more valuable to everybody if I stick to my knitting.

danielvaughn 4y ago
You’re not unpacking anything in what I said, you’re just disagreeing with each point, and each disagreement is mostly rooted in a misunderstanding of what I’m saying. My point is that the code, and all it’s material constructs that you pointed out (loops, allocation etc), do not exist apart from the business, because it’s the only reason those things exist in the first place. I’m not sure how much experience you have, but if you have enough, you should know how easy it is for an engineering team to become disconnected with the goals of the company. I’ve seen devs waste literal months on things that, had the primary stakeholders known about it, they’d never have agreed to. Now, you could look at that situation and envy the job security. Sure you could just see yourself as just a cog in the machine, with no responsibility whatsoever in wondering why the fuck you’re doing what you’re doing. But I certainly would not hire you.
- michaelcampbell 4y ago
  > Sure you could just see yourself as just a cog in the machine, with no responsibility whatsoever in wondering why the fuck you’re doing what you’re doing. But I certainly would not hire you. But there are lots, and LOTS of people who would, and want EXACTLY THAT. They want people to be told what to do, and do it, and not question why.
  - danielvaughn 4y ago
    Yep, and maybe I was being too harsh in how I said it. It's an understandable sentiment; I've just never seen it work in practice. Inevitably, the team (over time) begins to move orthogonally to the company. Like I said above, you'd need a very well-oiled machine, ala a super tight chain of command with clear directives at each layer. I see it in the same way I see security. A company is only as secure as its most vulnerable employee, so everyone must be vigilant about their own personal security practices. Same goes for "product security" - ensuring that the micro-actions taken by each IC reflect the company's objectives. It's an all-hands-on-deck practice.
- worik 4y ago
  > code, and all it’s material constructs that you pointed out (loops, allocation etc), do not exist apart from the business, because it’s the only reason those things exist in the first place. I What else is that true for? All the way down. Biology, chemistry, physics, quantum physics.... All that we work on exists in those contexts too. Yet we just swim in the sea and ignore the water. The same is true of business matters. They are the ocean I swim in > I’ve seen devs waste literal months on things that, had the primary stakeholders known about it, they’d never have agreed to. That is poor communication. Communication is a necessary skill for all cooperative endeavours. I am a cog in a machine. Unusually for some one in my position I actually have a good understanding of business (studied it for years) and I prefer computer programming. Having computer programmers stick their oar in over financial matters, unasked, is not good. So I do not do it. I know my place, I like my place.