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.
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.
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.
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.
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...
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.
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.
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.
* 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
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...
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.
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.
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.
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.
A good surgeon will also very often advise a patient that surgery is not indicated.
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.