8 ms·

This! My dream job is to have none-to-few meetings and to have my head in code all day. I do have something close to this right now, but I really hope that in

by epgui 4y ago

This! My dream job is to have none-to-few meetings and to have my head in code all day. I do have something close to this right now, but I really hope that in 10 years I can still be writing code.

zasdffaa 4y ago
I'm a dev and I see my job very much in contrast to what you've described. My job is to solve business problems, typically using code, but it all the things around it like requirements gathering etc. It also definitely includes trying to solve business problems by not writing code; by saying "this is a business problem not a technical one, how about trying <some non-coding approach>" Not to disagree with you, just giving a contrast.
- VyseofArcadia 4y ago
  Frankly, I see it as my job to write code. That this code happens to solve business problems is a lucky coincidence. Of course, this attitude may be a reflection of the fact that I have never written software for a domain in which I have expertise. Maybe if I were working on a product that I myself used, I would be able and happy to help solve business problems. As is, that is better left to a SME, and I am happy to solve technical problems.
  - rconti 4y ago
    I'd say "your day is spent writing code. That this code happens to solve business problems is why someone pays you to do it".
- epgui 4y ago
  I don't disagree, but saying my job isn't to write code is like saying a surgeon's job is not to fix people up, or a bricklayer's job is not to lay brick. Anyone's job can be described as "solving a business problem" or "adding value", but that's not usually the best way to describe it unless you're in a room full of MBAs. (And even a bricklayer's job goes beyond "merely laying bricks".) IMO, it goes (or should go) without saying that my work output is valuable, and that I do what I do for a reason, and that "writing code" does not encapsulate everything there is to know about the job.
  - zasdffaa 4y ago
    I once solved an urgent business problem (related to interfaces FYI) by realising there must have been a 3rd party solution. A quick search and I found it. It went onto client sites soon after. To be fair, the problem had to be solved using code anyway (why I was originally brought in), so another team wrote that, but it took several man-years. My interim 'fix' bought the company a lot of time. This isn't a great example as the code had to be written anyway, but you get my point I hope.
    - epgui 4y ago
      I do, and oftentimes as a professional, not taking action (or taking some alternative action, or referring to another professional, etc) is the best thing you can advise a client. A good surgeon will also very often advise a patient that surgery is not indicated.
  - idontpost 4y ago
    > saying my job isn't to write code is like saying a surgeon's job is not to fix people up A surgeon is a perfect example against your argument -- the surgeon's job is to achieve a positive patient outcome, not to cut someone open. Sometimes achieving the first is best done by cutting someone open, but when it is not then it is the surgeon's job to say that a different approach is needed.
    - epgui 4y ago
      That goes without saying, and is not incompatible with a reasonable reading of what I said.
unity1001 4y ago
You will likely get bored eventually. For you'll start to see patterns, you'll start to see much further ahead after some time. You'll be able to see things from a much wider perspective. You will see that there are many things that can be done, must be done, and must be avoided. Many potential opportunities and pitfalls. Your horizon will broaden. You are now able to think and plan much further ahead and you are able to plan much bigger things. But you will notice that you are just one person. Its impossible to do all of that alone. Then you realize that you need to work as a team.
- epgui 4y ago
  Most engineers I hear say this ("you get bored and after a while it's all the same") don't seem to share my interest for learning very-different languages or academic computer science theory. I am interested in all of that, and I am pretty confident I will never run out of things to learn.
  - epolanski 4y ago
    You say that with few years under the belt. Come in a decade.
    - epgui 4y ago
      I studied biochem for 12 years and know what it's like to reach the edge of human knowledge on a very very very narrow and specialized topic. I know enough about the breadth and depth of computer science to know how insane it is for any one person to think they've run out of things to learn.
      - unity1001 4y ago
        > I know enough about the breadth and depth of computer science Its not about learning. Its about creating. After a while, you will have created a majority of the potential things you can create and everything will start to look the same. If you are a CS researcher and will remain as such, your perspective may be applicable. In the actual industry that apps, services are created and provided to the users, its not. So as long as you stay in research and not go into actually making apps, you'll be fine. That is, if constantly learning and not creating does not start to bother you...

by epgui 4y ago

This! My dream job is to have none-to-few meetings and to have my head in code all day. I do have something close to this right now, but I really hope that in 10 years I can still be writing code.

zasdffaa 4y ago

I'm a dev and I see my job very much in contrast to what you've described. My job is to solve business problems, typically using code, but it all the things around it like requirements gathering etc. It also definitely includes trying to solve business problems by not writing code; by saying "this is a business problem not a technical one, how about trying <some non-coding approach>" Not to disagree with you, just giving a contrast.

VyseofArcadia 4y ago
Frankly, I see it as my job to write code. That this code happens to solve business problems is a lucky coincidence. Of course, this attitude may be a reflection of the fact that I have never written software for a domain in which I have expertise. Maybe if I were working on a product that I myself used, I would be able and happy to help solve business problems. As is, that is better left to a SME, and I am happy to solve technical problems.
- rconti 4y ago
  I'd say "your day is spent writing code. That this code happens to solve business problems is why someone pays you to do it".
epgui 4y ago
I don't disagree, but saying my job isn't to write code is like saying a surgeon's job is not to fix people up, or a bricklayer's job is not to lay brick. Anyone's job can be described as "solving a business problem" or "adding value", but that's not usually the best way to describe it unless you're in a room full of MBAs. (And even a bricklayer's job goes beyond "merely laying bricks".) IMO, it goes (or should go) without saying that my work output is valuable, and that I do what I do for a reason, and that "writing code" does not encapsulate everything there is to know about the job.
- zasdffaa 4y ago
  I once solved an urgent business problem (related to interfaces FYI) by realising there must have been a 3rd party solution. A quick search and I found it. It went onto client sites soon after. To be fair, the problem had to be solved using code anyway (why I was originally brought in), so another team wrote that, but it took several man-years. My interim 'fix' bought the company a lot of time. This isn't a great example as the code had to be written anyway, but you get my point I hope.
  - epgui 4y ago
    I do, and oftentimes as a professional, not taking action (or taking some alternative action, or referring to another professional, etc) is the best thing you can advise a client. A good surgeon will also very often advise a patient that surgery is not indicated.
- idontpost 4y ago
  > saying my job isn't to write code is like saying a surgeon's job is not to fix people up A surgeon is a perfect example against your argument -- the surgeon's job is to achieve a positive patient outcome, not to cut someone open. Sometimes achieving the first is best done by cutting someone open, but when it is not then it is the surgeon's job to say that a different approach is needed.
  - epgui 4y ago
    That goes without saying, and is not incompatible with a reasonable reading of what I said.

unity1001 4y ago

You will likely get bored eventually. For you'll start to see patterns, you'll start to see much further ahead after some time. You'll be able to see things from a much wider perspective. You will see that there are many things that can be done, must be done, and must be avoided. Many potential opportunities and pitfalls. Your horizon will broaden. You are now able to think and plan much further ahead and you are able to plan much bigger things. But you will notice that you are just one person. Its impossible to do all of that alone. Then you realize that you need to work as a team.

epgui 4y ago
Most engineers I hear say this ("you get bored and after a while it's all the same") don't seem to share my interest for learning very-different languages or academic computer science theory. I am interested in all of that, and I am pretty confident I will never run out of things to learn.
- epolanski 4y ago
  You say that with few years under the belt. Come in a decade.
  - epgui 4y ago
    I studied biochem for 12 years and know what it's like to reach the edge of human knowledge on a very very very narrow and specialized topic. I know enough about the breadth and depth of computer science to know how insane it is for any one person to think they've run out of things to learn.
    - unity1001 4y ago
      > I know enough about the breadth and depth of computer science Its not about learning. Its about creating. After a while, you will have created a majority of the potential things you can create and everything will start to look the same. If you are a CS researcher and will remain as such, your perspective may be applicable. In the actual industry that apps, services are created and provided to the users, its not. So as long as you stay in research and not go into actually making apps, you'll be fine. That is, if constantly learning and not creating does not start to bother you...