Hacker News new | past | comments | ask | show | jobs | submit login

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.




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.


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.


You say that with few years under the belt. Come in a decade.


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.


What I'm saying is that it sounds naive to think you will be the same person in one year, let alone a decade and to think that your interests won't change.

We've got only one life, and as much as I like programming and engineering, and fp, maths, logic I really hope life has also other things to show me and enrich me, and I hope I moved my interests elsewhere in a decade.


I think what other commenters are getting at is that at some point you won't be interested in

* manipulating lists with functional programming * manipulating lists with OOP * manipulating lists with a non memory managed language * manipulating lists with a hard type safe language

and will start being interested in * guiding people to manipulate lists as simply as possible to MAKE SOME MONEY


Yeah, I hear that, but there are so many deeper things to learn, and it's totally possible to continue learning these things while building real things and making good money (not necessarily in any job, but there are jobs out there that give you more or less autonomy and latitude).

Proof languages, dependent types, other category theory -inspired abstractions... For example I've been really enjoying reading this journal lately: https://www.cambridge.org/core/journals/journal-of-functiona...


> 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...


> After a while, you will have created a majority of the potential things you can create and everything will start to look the same.

This sounds like the famous quote: “Everything that can be invented has been invented.”

It’s as wrong now as it was a century ago. We’re surrounded by opportunities, things waiting for someone to invent them. If you don’t see them, maybe you’re not looking hard enough. I certainly work with plenty of people who feel like we’ve basically solved it, our system works fine. It doesn’t. It’s shit, they just don’t feel like building anymore.

I’m in my third professional decade, for what it’s worth. Far from leveling off in the long run, an IC’s capability is exponential, if you keep trying.


> This sounds like the famous quote: “Everything that can be invented has been invented.”

Thats for science and invention. Not engineering. Less, the current tech space in which we are catering to the public. Even when there are new inventions, it takes decades for one of them to materialize.

You could definitely work in a large research organization, do research with large funding - the research that your funders want you to do, of course. Then you can spend a few decades researching something, and maybe you can invent something new. If that would satisfy you, that's also a career option.


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.


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.


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.


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.


> 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.


That goes without saying, and is not incompatible with a reasonable reading of what I said.


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.


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".




Join us for AI Startup School this June 16-17 in San Francisco!

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: