5 ms·

I agree. I've had a couple of stints as a manager, now as a CTO for a small startup, and it's giving me so much insight into thinking about engineering from a b

I agree. I've had a couple of stints as a manager, now as a CTO for a small startup, and it's giving me so much insight into thinking about engineering from a business perspective. As an IC it's hard to get that birds eye view, but it's possible.

BurningFrog 4y ago
Can you mention one or two such insights about thinking about engineering from a business perspective?
- ben30 4y ago
  I've got this bookmarked: https://github.com/kuchin/awesome-cto https://github.com/kuchin/awesome-cto
- danielvaughn 4y ago
  1. A developers job is not to write code. You happen to write code as part of your job, but your core responsibility is to implement solutions to business problems. Sounds simple, but it's harder to realize in practice. Case in point was a recent freelance job I took on. This client had paid some devs for months of work on a Stripe integration. They had built all this custom code on the front-end and back-end. I came in, read the docs since I was new to Stripe, and quickly learned that a custom solution puts the company on the hook for 300+ security requirements for PCI compliance. I scrapped all the code and directed users to Stripe's own checkout page. Not as nice of a UX, but that company's customers are now much more secure, there is less code to maintain, and the client is happy. 2. Your managers aren't perfect people, but their livelihood is in your hands. It's incredibly stressful to be a manager, so try to have compassion and empathy for the position they're in. They have to explain to the executive team the progress you're making, and if no progress is being made, they take the blame. 3. If you can't connect the dots between what you're doing on a daily basis, and the overall trajectory of the company, then something's wrong. There's a broken connection somewhere, and no one other than you is going to realize it. Speak up if you don't think what you're doing is useful.
  - s1artibartfast 4y ago
    I really like #3. If you don't know why you are doing something, it is very unlikely that somebody else knows better.
  - worik 4y ago
    > . A developers job is not to write code. You happen to write code as part of your job, but your core responsibility is to implement solutions to business problems. My job is to write code. Nobody is interested in my opinions about business problems. I have to be aware, of course. I propose code to write some times, and I have to have some idea that it is a vaguely practical thing in business terms. I want to write code in groovy system A but mundane system B has a better chance of success then my desire for system A goes by the wayside. But it is my job to write code. That is all.
    - danielvaughn 4y ago
      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.
samstave 4y ago
>As an IC it's hard to get that birds eye view, but it's possible. Unless you actually have a consultancy which is based on seeing the ways in which you may plug a hole in the dyke... And IC should ADD value to the org, not just slurp off of a need the company needs to fill.

BurningFrog 4y ago

Can you mention one or two such insights about thinking about engineering from a business perspective?

ben30 4y ago
I've got this bookmarked: https://github.com/kuchin/awesome-cto https://github.com/kuchin/awesome-cto
danielvaughn 4y ago
1. A developers job is not to write code. You happen to write code as part of your job, but your core responsibility is to implement solutions to business problems. Sounds simple, but it's harder to realize in practice. Case in point was a recent freelance job I took on. This client had paid some devs for months of work on a Stripe integration. They had built all this custom code on the front-end and back-end. I came in, read the docs since I was new to Stripe, and quickly learned that a custom solution puts the company on the hook for 300+ security requirements for PCI compliance. I scrapped all the code and directed users to Stripe's own checkout page. Not as nice of a UX, but that company's customers are now much more secure, there is less code to maintain, and the client is happy. 2. Your managers aren't perfect people, but their livelihood is in your hands. It's incredibly stressful to be a manager, so try to have compassion and empathy for the position they're in. They have to explain to the executive team the progress you're making, and if no progress is being made, they take the blame. 3. If you can't connect the dots between what you're doing on a daily basis, and the overall trajectory of the company, then something's wrong. There's a broken connection somewhere, and no one other than you is going to realize it. Speak up if you don't think what you're doing is useful.
- s1artibartfast 4y ago
  I really like #3. If you don't know why you are doing something, it is very unlikely that somebody else knows better.
- worik 4y ago
  > . A developers job is not to write code. You happen to write code as part of your job, but your core responsibility is to implement solutions to business problems. My job is to write code. Nobody is interested in my opinions about business problems. I have to be aware, of course. I propose code to write some times, and I have to have some idea that it is a vaguely practical thing in business terms. I want to write code in groovy system A but mundane system B has a better chance of success then my desire for system A goes by the wayside. But it is my job to write code. That is all.
  - danielvaughn 4y ago
    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.

samstave 4y ago

>As an IC it's hard to get that birds eye view, but it's possible. Unless you actually have a consultancy which is based on seeing the ways in which you may plug a hole in the dyke... And IC should ADD value to the org, not just slurp off of a need the company needs to fill.