Ask HN: What skills are worth learning long-term against AI?
38 comments
In 45 years? I predict the skills you'll need then will include:
foraging, scavenging, hacking, repurposing old junk into shelter and transportation, hydroponics, stealing electricity, small scale farming, digging, ammo reloading, evading AI, creating improvised explosive devices, smuggling, ICE breaking, soldering, welding, firearms maintenance, broadcasting pirate radio and television, etc.
foraging, scavenging, hacking, repurposing old junk into shelter and transportation, hydroponics, stealing electricity, small scale farming, digging, ammo reloading, evading AI, creating improvised explosive devices, smuggling, ICE breaking, soldering, welding, firearms maintenance, broadcasting pirate radio and television, etc.
You forgot, fire making, water filtration (essential) and fishing (protein, fat, vitamins).
How can you do all the stuff without energy? Are you running on sunlight, or do you do nuclear fission inside your body?
I tend to like the view of AI maximalist. All the post apocalyptic stuff is not great for your mood day to day.
Either that or just know how to enjoy yourself, since our benevolent AI God has got life covered.
I kinda agree given the developing situation.
Reads like a sceene from terminator movie...
In truth, I'm partly (maybe even mostly?) joking. I'm generally an optimistic in regards to technology.
And yet...
I have my doubts, and some concerns about what the future holds with the way some things are going. A tinge of concern that a cyberpunk dystopia might just be in our future has started to creep in around the edges.
And yet...
I have my doubts, and some concerns about what the future holds with the way some things are going. A tinge of concern that a cyberpunk dystopia might just be in our future has started to creep in around the edges.
Fun fact: those movies are just easter eggs thrown into our timeline by future ChatGPT
[deleted]
Writing has proven to be surprisingly resistant to Ai. Or re-writing people's AI-generated papers to sound more human or readable. AI-generated writing has a certain unmistakable clunkiness that tends to give it away.
Totally agree, it’s the textual equivalent of the visual uncanny valley. Communication in general is obviously not gonna go away. Certain kinds of corporate copy-writing where the tone matches the LLM is probably not as resistant. It’ll be interesting to see to what extent that uncanny effect will be reduced over the next decade.
Give it another year at maximum. Claude already sounds a lot less robotic than GPT4, and I heard of some smaller models sounding quite natural.
It may sound banal but the more i live the more i see it’s true.
Learning basics never gets old.
Philosophy, logic, seeking truth, foundations of math, of basic nature laws etc.
Whatever skills gonna be needed in future- you’ll adapt, if you’re smart and flexible.
And only seeking the truth keeps you in shape, exploring basics helps you get smarter.
Learning basics never gets old.
Philosophy, logic, seeking truth, foundations of math, of basic nature laws etc.
Whatever skills gonna be needed in future- you’ll adapt, if you’re smart and flexible.
And only seeking the truth keeps you in shape, exploring basics helps you get smarter.
Who knows what the future will bring (will we ever get AGI)?
Needless to say, fundamentals, that is, math (geometry, algebra, and calculus) and physics (mechanics, electromagnetism, thermodynamics).
Some basic algorithms/techniques such as backpropagation, triangle ray tracing and rasterization, and some fundamental awareness that you can compute anything given 5-6 instructions (Turing completeness). Knowing how to program in a language like Python might suffice.
Then there are skills that are essential to maintain your life, such as fire making, fishing, and water filtration. You need to get energy someway.
See also Maslow's pyramid.
Needless to say, fundamentals, that is, math (geometry, algebra, and calculus) and physics (mechanics, electromagnetism, thermodynamics).
Some basic algorithms/techniques such as backpropagation, triangle ray tracing and rasterization, and some fundamental awareness that you can compute anything given 5-6 instructions (Turing completeness). Knowing how to program in a language like Python might suffice.
Then there are skills that are essential to maintain your life, such as fire making, fishing, and water filtration. You need to get energy someway.
See also Maslow's pyramid.
Building something the right way doesn’t matter if you don’t build the right thing. Requirements are never fully specified and it is your job to use good judgment on the ambiguous parts. Figure out what business problem you are being asked to solve and recommend solutions accordingly. “If I asked people what they wanted, they would have said a faster horse” - Henry Ford
Also, you most likely think your job is what’s in the job description. That is not true. Unless you are in a field where output is super easy to measure (e.g., professional golf) your job is to make life easier for your boss and other people above you at your company.
Also, you most likely think your job is what’s in the job description. That is not true. Unless you are in a field where output is super easy to measure (e.g., professional golf) your job is to make life easier for your boss and other people above you at your company.
Performance, security, and written communication. In my experience CS graduates are hilariously and profoundly bad at each of those.
When it comes to performance most developers are absolutely and utterly incapable of measuring things, a bridge too far. As a result most developers simply just guess at this. The problem with guessing is that people tend to guess wrong more 80% of the time and more those 50% of those wrong guesses are off by one to three orders of magnitude.
In my experience most developers have absolutely no idea about security best practices and yet somehow believe themselves quite brilliant at it. Security in software is Dunning-Kruger at its finest, and the confidence therein is superbly comedic. Don’t lie to yourself about security. If you want to prove to the world just how much you aren’t full of shit get a CASP, CISA, or CISSP. In my experience you are typically much safer listening to the security opinions of software developers and executing the exact opposite.
Written communication is also a poor developed skill for most software developers. I have seen people insane things to avoid having to send brief emails. Your ability to articulate your thoughts in writing with precision and clarity are the best way to unintentionally prove to the world just how brilliant you are. Good written communication requires practice. Don’t be that coward that hides from this because you are only harming your own professional development.
When it comes to performance most developers are absolutely and utterly incapable of measuring things, a bridge too far. As a result most developers simply just guess at this. The problem with guessing is that people tend to guess wrong more 80% of the time and more those 50% of those wrong guesses are off by one to three orders of magnitude.
In my experience most developers have absolutely no idea about security best practices and yet somehow believe themselves quite brilliant at it. Security in software is Dunning-Kruger at its finest, and the confidence therein is superbly comedic. Don’t lie to yourself about security. If you want to prove to the world just how much you aren’t full of shit get a CASP, CISA, or CISSP. In my experience you are typically much safer listening to the security opinions of software developers and executing the exact opposite.
Written communication is also a poor developed skill for most software developers. I have seen people insane things to avoid having to send brief emails. Your ability to articulate your thoughts in writing with precision and clarity are the best way to unintentionally prove to the world just how brilliant you are. Good written communication requires practice. Don’t be that coward that hides from this because you are only harming your own professional development.
> Performance, security, and written communication.
AIs are good at all of these. Performance & security is largely a knowledge problem which AIs are very good at. And LLMs are great at written communication.
AIs are good at all of these. Performance & security is largely a knowledge problem which AIs are very good at. And LLMs are great at written communication.
I asked GPT-4 today to optimise a function for me, giving it a hint at what algorithm to use and it produced something incorrect and about 100x slower than what I was trying to optimise.
If that is true then why bother hiring expensive humans to write slow, insecure, inferior software products at all. Replace them all.
That's the plan everybody is working on, yes
I think if you understand the fundamentals of how computers work and can debug anything to figure out what is causing a problem you will be valuable for a long time. most people either don't have the requisite knowledge to do this, or just simply lack the drive and curiosity to figure out weird bugs. also, there are senior engineers with 10+ years exp. at the company that I work at that don't bother to google or do any real debugging before asking a question in slack. don't be one of those people.
Poker. Game of skill. Looks like gambling from the outside. Rich people use it as a way to socialize while wasting money. Not dependent on any technology. Has existed for hundreds of years (Lindy).
Practice enough to win at an average table and then know at any time you can get on a plane for Vegas, Atlantic City, or another place with consistent games and make a living playing cards.
Perfect as a backup plan / hedge. Poker also teaches lots of life skills so still useful if you never really use it too.
Practice enough to win at an average table and then know at any time you can get on a plane for Vegas, Atlantic City, or another place with consistent games and make a living playing cards.
Perfect as a backup plan / hedge. Poker also teaches lots of life skills so still useful if you never really use it too.
Fundamentals don't go away. I'd recommend getting into understanding how LLMs work, from scratch, and getting into that corner of the industry. Even if the LLMs write all the code, someone still has to direct them on what to write. They're not going away, so expertise on how to train and operate them is going to be valuable for the foreseeable future. What is MoE or RAG? If I'd just graduated, I'd force myself into that corner of the industry.
You have to learn to maths and to code, that takes about a decade. It requires a lot of output from you. There’s no way around that. Even if it was all redundant due to AI , it is essential mental scaffolding for higher thought unreachable without it.
> essential mental scaffolding for higher thought
Yes, definitely. And as AI grows into more and more facets of intellectual output, humans will need to reach those higher thoughts to find a niche to occupy. The best thing one can do today is exactly to start building that scaffolding that will allow that to happen.
Yes, definitely. And as AI grows into more and more facets of intellectual output, humans will need to reach those higher thoughts to find a niche to occupy. The best thing one can do today is exactly to start building that scaffolding that will allow that to happen.
Coding will change but still exist. If the computer is coding for you you still need to understand what it did, review it etc. If it can automate everything to do with coding it can probably automate sales, marketing, finance and support :-).
I have almost 45 years experience in software development, so I can describe the skills that led to my own longevity.
Hardware and the tools and languages available for writing software changed and improved in many ways during my career. My phone has more compute power and memory than the mainframes I worked on in the '70s and '80s. We have more expressive and safer languages, and better tools for writing and testing code. On the other hand I still use, every day, things that date from early in my career: C and C-family languages, relational databases and SQL, Unix in the form of Linux, modern versions of the vi editor. Very little about the practice of software development changed in the last 4.5 decades -- programming books written in the '70s have the same lessons as those published last year, you just have to read PL/I in one and Javascript or Rust in another. Read anything by Brian Kernighan to understand how little software development has actually changed in 40 years, and how programmers continue to repeat the same mistakes, "reinvent the flat tire," as Alan Kay put it.
A big lesson learned way back in the history of software development: Getting the requirements right is the hard part. That hasn't changed, software projects still succeed or fail mostly due to success or failure in the requirements and specification steps. A lot of programmers don't have the experience or interest to learn the business domain or engage with management and users, so they can't write or even correctly interpret requirements. When I started my career I worked with analysts who translated business domain expertise and business requirements into actionable software development plans for the programmers to implement [1] [2]. The analyst role faded away in many companies as software development changed from an ancillary activity (supporting an accounting or logistics department, for example) to a standalone discipline producing products that businesses would adapt to. Today software often dictates requirements rather than the other way around -- if you've ever worked at a company that adopted Salesforce or SAP or Oracle you know what I mean.
Another lesson known as least as far back as Brooks[3] wrote a book about it: People and organizational issues determine the success of software projects to a greater degree (I'd say much greater) than technical skill or choice of language. Learning how to manage teams and projects and work with all of the business stakeholders will prove more durable and valuable than learning the new language of the year.
Writing code got more mechanical over the years, and bugs and performance issues and resource usage became less critical because modern hardware can handle sloppy and bloated code, and modern operating systems and programming languages have a lot more guardrails and fault tolerance. That glosses over a lot of bad code, which in my opinion led to even more sloppy programming. Since LLMs will train mostly on modern code in modern languages I think we can expect more of the same -- workable code that just reiterates what someone else already wrote. That describes what a majority of programmers do now, plugging APIs together, so LLMs can join the team.
To answer your question: I would focus on the fundamentals, which have little to do with programming languages. The fundamental technologies that have stood up for decades with no sign of going away:
- Relational databases and SQL.
- Unix-family operating systems [4].
- C, because it influenced so many later languages, and expresses the essence of programming succinctly.
- Lisp, because it offers a counterpoint to the imperative C style that came to dominate, even if almost no one writes Lisp code today.
- Algorithms and data structures, and algorithmic complexity, which you can learn from '70s-era books by Knuth and Wirth.
I'll add networking and security, things we didn't have or worry much about pre-internet, but today I see a lot of demand for actual experts and few people going that direction, preferring to join the front-end web dev React swarm because of the relatively low bar to entry.
I would also focus on learning business domains and the systems that keep businesses running. I can't get a job today because I know Javascript or Go, but I can get a job because I know a lot about enterprise-level logistics. Outside of the Silicon Valley tech meat grinder you find millions of companies solving business problems they can describe and attach actual costs and risks to, not looking for the next disruption (or grift) with a small chance of success. Businesses don't have requirements like "We need another thousand lines of Javascript by next month." They have requirements like "We need to reduce late deliveries and mistakes by 20%." So learn at least one business domain (best to learn on the job), pay attention to the whole organization and the people, make contacts and friends who aren't fellow Rust geeks, and hone your skills translating business needs into actionable software specifications.
Learn and practice speaking and writing. People who can effectively communicate have a significant advantage over those who can't. [5]
You face a tough job market, especially for people trying to enter the field. Look beyond the big tech companies. You can't ignore AI (what we're calling "AI" this decade) and the possibility it will eventually write entire working software applications, though today that's more hype and VC dreams than reality. But if that does happen I think businesses will still need actual experts who have experience and skills, not just a good memory and algorithm for spewing out code. And I know businesses will need people who can solve business problems rather than just write code.
[1] https://www.amazon.com/Structured-Design-Fundamentals-Discip... (for example)
[2] https://www.amazon.com/Reliable-software-through-composite-d... (for example)
[3] https://en.wikipedia.org/wiki/The_Mythical_Man-Month
[4] http://doc.cat-v.org/bell_labs/utah2000/
[5] https://www.dreamsongs.com/Files/PatternsOfSoftware.pdf
Hardware and the tools and languages available for writing software changed and improved in many ways during my career. My phone has more compute power and memory than the mainframes I worked on in the '70s and '80s. We have more expressive and safer languages, and better tools for writing and testing code. On the other hand I still use, every day, things that date from early in my career: C and C-family languages, relational databases and SQL, Unix in the form of Linux, modern versions of the vi editor. Very little about the practice of software development changed in the last 4.5 decades -- programming books written in the '70s have the same lessons as those published last year, you just have to read PL/I in one and Javascript or Rust in another. Read anything by Brian Kernighan to understand how little software development has actually changed in 40 years, and how programmers continue to repeat the same mistakes, "reinvent the flat tire," as Alan Kay put it.
A big lesson learned way back in the history of software development: Getting the requirements right is the hard part. That hasn't changed, software projects still succeed or fail mostly due to success or failure in the requirements and specification steps. A lot of programmers don't have the experience or interest to learn the business domain or engage with management and users, so they can't write or even correctly interpret requirements. When I started my career I worked with analysts who translated business domain expertise and business requirements into actionable software development plans for the programmers to implement [1] [2]. The analyst role faded away in many companies as software development changed from an ancillary activity (supporting an accounting or logistics department, for example) to a standalone discipline producing products that businesses would adapt to. Today software often dictates requirements rather than the other way around -- if you've ever worked at a company that adopted Salesforce or SAP or Oracle you know what I mean.
Another lesson known as least as far back as Brooks[3] wrote a book about it: People and organizational issues determine the success of software projects to a greater degree (I'd say much greater) than technical skill or choice of language. Learning how to manage teams and projects and work with all of the business stakeholders will prove more durable and valuable than learning the new language of the year.
Writing code got more mechanical over the years, and bugs and performance issues and resource usage became less critical because modern hardware can handle sloppy and bloated code, and modern operating systems and programming languages have a lot more guardrails and fault tolerance. That glosses over a lot of bad code, which in my opinion led to even more sloppy programming. Since LLMs will train mostly on modern code in modern languages I think we can expect more of the same -- workable code that just reiterates what someone else already wrote. That describes what a majority of programmers do now, plugging APIs together, so LLMs can join the team.
To answer your question: I would focus on the fundamentals, which have little to do with programming languages. The fundamental technologies that have stood up for decades with no sign of going away:
- Relational databases and SQL.
- Unix-family operating systems [4].
- C, because it influenced so many later languages, and expresses the essence of programming succinctly.
- Lisp, because it offers a counterpoint to the imperative C style that came to dominate, even if almost no one writes Lisp code today.
- Algorithms and data structures, and algorithmic complexity, which you can learn from '70s-era books by Knuth and Wirth.
I'll add networking and security, things we didn't have or worry much about pre-internet, but today I see a lot of demand for actual experts and few people going that direction, preferring to join the front-end web dev React swarm because of the relatively low bar to entry.
I would also focus on learning business domains and the systems that keep businesses running. I can't get a job today because I know Javascript or Go, but I can get a job because I know a lot about enterprise-level logistics. Outside of the Silicon Valley tech meat grinder you find millions of companies solving business problems they can describe and attach actual costs and risks to, not looking for the next disruption (or grift) with a small chance of success. Businesses don't have requirements like "We need another thousand lines of Javascript by next month." They have requirements like "We need to reduce late deliveries and mistakes by 20%." So learn at least one business domain (best to learn on the job), pay attention to the whole organization and the people, make contacts and friends who aren't fellow Rust geeks, and hone your skills translating business needs into actionable software specifications.
Learn and practice speaking and writing. People who can effectively communicate have a significant advantage over those who can't. [5]
You face a tough job market, especially for people trying to enter the field. Look beyond the big tech companies. You can't ignore AI (what we're calling "AI" this decade) and the possibility it will eventually write entire working software applications, though today that's more hype and VC dreams than reality. But if that does happen I think businesses will still need actual experts who have experience and skills, not just a good memory and algorithm for spewing out code. And I know businesses will need people who can solve business problems rather than just write code.
[1] https://www.amazon.com/Structured-Design-Fundamentals-Discip... (for example)
[2] https://www.amazon.com/Reliable-software-through-composite-d... (for example)
[3] https://en.wikipedia.org/wiki/The_Mythical_Man-Month
[4] http://doc.cat-v.org/bell_labs/utah2000/
[5] https://www.dreamsongs.com/Files/PatternsOfSoftware.pdf
This is fantastic, thank you so much for the thoughtful response!
I happen to be super interested in systems programming (OSes, DBs, PLs), but I've worried that those fundamentals might be superseded by AI, whether through a higher-level abstraction or just better automated code generation. Glad to hear an experienced opinion to the contrary.
I think I'll need to come back and read this a couple more times to pull out all the advice here, I appreciate this much to chew on :)
I happen to be super interested in systems programming (OSes, DBs, PLs), but I've worried that those fundamentals might be superseded by AI, whether through a higher-level abstraction or just better automated code generation. Glad to hear an experienced opinion to the contrary.
I think I'll need to come back and read this a couple more times to pull out all the advice here, I appreciate this much to chew on :)
Absolutely Agree!
If I may, I would like to ask you something a bit hyperbole.
You outlined a few key points which include learning people skills, communication, and requirements engineering.
Do you think it wouldn't be possible for AI/AGI of the future to supercharge this process?
What I feel people like OP and I are experiencing is the impending doom that is about to fall on us as a result of automation.
We are inexperienced, and our only feedback from the real world is job applications, which are getting rejected at an enormous rate. Adding AI on top of that doesn't paint a good picture, especially when we (our generation) have easily adopted it into our workflow and started producing results. In rejection emails we get responses like, "we found a better candidate". This means our effort is futile and what we compare against is AI because it is the only thing we can see. We can't see the profile of someone who was better and got into the job.
What we fear is people with AI + communication skills will outperform us, who just honed our skills in computing. Simply because they are better communicators and have improved efficiency. This would mean senior engineers will be demanded more and no one would care for juniors.
Now without any job, building a career is a nightmare. On top of that, even after a job, having a secured career is a problem, like OP said.
Final questions,
1. Regarding communication:
What is a benchmark that indicates if someone is a adept communicator? Is communication a skill that can be learnt? And can those who have hard time communicating be better at it than AI that spits out almost correct sounding hallucinations?
2. Beyond programming:
How to prove that we have better fundamentals than other people? What screams "I want to work with them"? How to show that we can design systems that last long?
Looking forward to hearing from you.
If I may, I would like to ask you something a bit hyperbole.
You outlined a few key points which include learning people skills, communication, and requirements engineering.
Do you think it wouldn't be possible for AI/AGI of the future to supercharge this process?
What I feel people like OP and I are experiencing is the impending doom that is about to fall on us as a result of automation.
We are inexperienced, and our only feedback from the real world is job applications, which are getting rejected at an enormous rate. Adding AI on top of that doesn't paint a good picture, especially when we (our generation) have easily adopted it into our workflow and started producing results. In rejection emails we get responses like, "we found a better candidate". This means our effort is futile and what we compare against is AI because it is the only thing we can see. We can't see the profile of someone who was better and got into the job.
What we fear is people with AI + communication skills will outperform us, who just honed our skills in computing. Simply because they are better communicators and have improved efficiency. This would mean senior engineers will be demanded more and no one would care for juniors.
Now without any job, building a career is a nightmare. On top of that, even after a job, having a secured career is a problem, like OP said.
Final questions,
1. Regarding communication:
What is a benchmark that indicates if someone is a adept communicator? Is communication a skill that can be learnt? And can those who have hard time communicating be better at it than AI that spits out almost correct sounding hallucinations?
2. Beyond programming:
How to prove that we have better fundamentals than other people? What screams "I want to work with them"? How to show that we can design systems that last long?
Looking forward to hearing from you.
I don't have answers to all of your questions. I don't know where the current wave of AI will go, or what jobs it might eliminate. I have gone through one "AI winter" already and multiple popped bubbles and supposed threats to my career. The hype and expectations have never matched the reality.
Because developing software costs so much money, and requires taking a lot of risk -- because software development lacks the predictability and repeatability of "real" engineering, see my other comment -- corporate executives are always looking for ways to reduce those costs and get something they can plausibly call "working software." Those execs have tried no-code/low-code several times. COBOL and SQL both promised end-user coding, with the usual result, because learning a language is the easy part of programming. Offshore outsourcing made a dent for a while but demand increased faster than supply of programmers, and now the offshore places have their own domestic demand for programmers. The current thing is LLMs, what we're calling AI these days. The VCs and companies who have a lead and a lot to gain are selling a big pile of hype to corporations. And some of it may work, I don't know. Based on history I expect LLMs to displace people in lower-end rote jobs, and that will likely include at least some of the easiest kind of programming. If VSCode can write 75% of the code for you and underline the errors an LLM can probably do even better.
I started in my career in the late '70s, and have stayed consistently employed since then. I never planned to make programming a career (I studied history at school and my parents hoped I'd go to law school), but it was challenging, came natural to me, and paid really well, so I've stuck with it (and now I can't do anything else to make a living). But I can't really put myself in your shoes, or relate to the OP's concerns except in an abstract way. I don't apply for jobs or go through hellish (and useless) interviews, although I read about those. I don't see LLMs taking over my job in what's left of my working years, but I suppose it could happen.
I'd like to tell you to sit out the hype cycle, the AI/LLM bubble will burst, the hype won't turn into a workplace revolution, the jobs will come back. I don't know that for sure but that's what I would bet on. But that doesn't do you or anyone else any good, looking for a job today, in a terrible job market full of recently laid off people who have at least some experience and (if they paid attention) some professional contacts.
Friends and professional contacts -- real people I know, not connections on LinkedIn -- have always worked best for me, so I advise meeting people and making friends, both in tech and in other fields. I have got some surprise job leads and freelance opportunities just chatting with people. I make it a habit to talk to strangers (to keep my natural shyness in check), you can try that. Word of mouth really works. If I had to find work today I would be talking to everyone I know, people I worked with 20 years ago, not filling out online job applications. I understand that's harder for someone without a lot of work experience.
As I wrote in my original comment, employers always need people who can solve business problems and add value. They don't always need more programmers. Figure out how to present yourself as a person who can solve problems, figure things out, work with the organization, add value, and you will find jobs, because people who can do that are always needed. It just isn't that rare anymore to have the ability to crank out web app code, and LLMs will make that meager skill even less valuable.
If you can speak and write effectively people will tell you, I guess that's the benchmark. If you can keep someone's attention, persuade someone to change their mind, communicate your skill and see someone use that knowledge, that's effective. You certainly can learn to speak and write better. Try joining Toastmasters to get over fear of speaking to groups. Watch videos of good presenters and speakers, or go see them in person. Read books about good writing, read novels that have held up for a long time (classics), and read essays and books by people who love reading and writing (Umberto Eco comes to mind). Go to writing classes and workshops.
Communicating well, and having the ability and knowledge to talk about more than one thing, will make you more appealing to other people, including potential employers and customers. I have freelanced for over ten years, and the number one thing I hear from new customers -- almost without exception -- is how the last people they hired stopped communicating with them. It doesn't take much effort to acknowledge and answer an email or call, but too many people fail even at that.
I like to say that maybe there's no such thing as the 10X programmer, or the 10X communicator. But you can easily observe that most people are at 0X or just barely above that. Be at least the 1X, worry about 10X later.
As for fundamentals, I don't know how to show that directly. A lot of it comes from practice and mentoring from more senior people, at least in my own experience. I'll repeat that if you can solve actual business problems and add value you will have a big advantage. You show, don't tell. Knowing the fundamentals will let you show and perform with confidence because you will see the same problems over and over, and if you already know how to approach the problem your employer or customer will understand that you know the fundamentals.
Because developing software costs so much money, and requires taking a lot of risk -- because software development lacks the predictability and repeatability of "real" engineering, see my other comment -- corporate executives are always looking for ways to reduce those costs and get something they can plausibly call "working software." Those execs have tried no-code/low-code several times. COBOL and SQL both promised end-user coding, with the usual result, because learning a language is the easy part of programming. Offshore outsourcing made a dent for a while but demand increased faster than supply of programmers, and now the offshore places have their own domestic demand for programmers. The current thing is LLMs, what we're calling AI these days. The VCs and companies who have a lead and a lot to gain are selling a big pile of hype to corporations. And some of it may work, I don't know. Based on history I expect LLMs to displace people in lower-end rote jobs, and that will likely include at least some of the easiest kind of programming. If VSCode can write 75% of the code for you and underline the errors an LLM can probably do even better.
I started in my career in the late '70s, and have stayed consistently employed since then. I never planned to make programming a career (I studied history at school and my parents hoped I'd go to law school), but it was challenging, came natural to me, and paid really well, so I've stuck with it (and now I can't do anything else to make a living). But I can't really put myself in your shoes, or relate to the OP's concerns except in an abstract way. I don't apply for jobs or go through hellish (and useless) interviews, although I read about those. I don't see LLMs taking over my job in what's left of my working years, but I suppose it could happen.
I'd like to tell you to sit out the hype cycle, the AI/LLM bubble will burst, the hype won't turn into a workplace revolution, the jobs will come back. I don't know that for sure but that's what I would bet on. But that doesn't do you or anyone else any good, looking for a job today, in a terrible job market full of recently laid off people who have at least some experience and (if they paid attention) some professional contacts.
Friends and professional contacts -- real people I know, not connections on LinkedIn -- have always worked best for me, so I advise meeting people and making friends, both in tech and in other fields. I have got some surprise job leads and freelance opportunities just chatting with people. I make it a habit to talk to strangers (to keep my natural shyness in check), you can try that. Word of mouth really works. If I had to find work today I would be talking to everyone I know, people I worked with 20 years ago, not filling out online job applications. I understand that's harder for someone without a lot of work experience.
As I wrote in my original comment, employers always need people who can solve business problems and add value. They don't always need more programmers. Figure out how to present yourself as a person who can solve problems, figure things out, work with the organization, add value, and you will find jobs, because people who can do that are always needed. It just isn't that rare anymore to have the ability to crank out web app code, and LLMs will make that meager skill even less valuable.
If you can speak and write effectively people will tell you, I guess that's the benchmark. If you can keep someone's attention, persuade someone to change their mind, communicate your skill and see someone use that knowledge, that's effective. You certainly can learn to speak and write better. Try joining Toastmasters to get over fear of speaking to groups. Watch videos of good presenters and speakers, or go see them in person. Read books about good writing, read novels that have held up for a long time (classics), and read essays and books by people who love reading and writing (Umberto Eco comes to mind). Go to writing classes and workshops.
Communicating well, and having the ability and knowledge to talk about more than one thing, will make you more appealing to other people, including potential employers and customers. I have freelanced for over ten years, and the number one thing I hear from new customers -- almost without exception -- is how the last people they hired stopped communicating with them. It doesn't take much effort to acknowledge and answer an email or call, but too many people fail even at that.
I like to say that maybe there's no such thing as the 10X programmer, or the 10X communicator. But you can easily observe that most people are at 0X or just barely above that. Be at least the 1X, worry about 10X later.
As for fundamentals, I don't know how to show that directly. A lot of it comes from practice and mentoring from more senior people, at least in my own experience. I'll repeat that if you can solve actual business problems and add value you will have a big advantage. You show, don't tell. Knowing the fundamentals will let you show and perform with confidence because you will see the same problems over and over, and if you already know how to approach the problem your employer or customer will understand that you know the fundamentals.
Thank you for your detailed answer. I will take some time to sink it in.
One key takeway is to create value. As someone who is barely starting out, what is value?
Is it revenue? Is it efficiency? Is it growth?
What is a proper way to clarify value? How can one show that they are indeed valuable?
One key takeway is to create value. As someone who is barely starting out, what is value?
Is it revenue? Is it efficiency? Is it growth?
What is a proper way to clarify value? How can one show that they are indeed valuable?
Value means whatever your employer or customer considers valuable and worth paying for. That may mean increased revenue, decreased costs, more efficient process, competitive advantage, even a happier team.
I'll give an example from my freelancing experience. When I meet a potential customer I don't try to sell them on my programming skills or experience. I ask them to tell me the unmet priorities or pains in their company remotely related to IT/software. I've heard things like "Our system doesn't correctly charge shipping on customer orders," or "We think our internet bill is too high." Those both sound like problems I can fix, so I ask how much that's costing the business, to get some idea of how the customer values a possible solution. Then I will propose I deal with it. If I can fix it they pay me some price I come up with based on their perception of the cost, and if I can't I won't charge them anything. And invariably once I fix one problem -- show that I can add value or reduce costs -- they think of other things I might help with. I'm simplifying but basically that's how it works. I don't have to persuade the customer that I have this or that skill on my resume. Of course you need to actually solve problems. That's how you build long-term relationships with customers, because every business needs people who can solve problems. As a freelancer I focus on smaller companies, not necessarily mom & pop, but small enough that I'm talking to someone who can make a decision.
You can use similar techniques in full-time job interviews, but again it will work better if the interviewer has hiring authority -- rare in larger organizations these days when you have layers of people to get through. Rather than sit there while the interviewer goes over my resume and tries to mentally match that to whatever job they have posted, I ask "What can I start on tomorrow to solve an actual problem you're having?" And chances are good they have a list of things they would like to get someone to deal with. Now I'm not getting grilled over why I quit a job eight years ago, I'm getting a description of something that maybe I can do to show my value.
When I have been in the interviewer seat I see the same deer in the headlights faces over and over, worried and nervous, not asking any real questions (or asking something irrelevant), waiting to defend themselves if asked about details on their resume. Don't be that person sitting in the chair sweating it out. You have just a few minutes to make an impression so show confidence, make eye contact, show that you researched what the company does, and ask about problems and pain points you can help solve. That changes the tone of the interview, and the interviewer will remember you as someone who at least showed some spirit and initiative. You have nothing to lose -- worst case is you don't get the job, which is where you were when you walked in the door.
I'll give an example from my freelancing experience. When I meet a potential customer I don't try to sell them on my programming skills or experience. I ask them to tell me the unmet priorities or pains in their company remotely related to IT/software. I've heard things like "Our system doesn't correctly charge shipping on customer orders," or "We think our internet bill is too high." Those both sound like problems I can fix, so I ask how much that's costing the business, to get some idea of how the customer values a possible solution. Then I will propose I deal with it. If I can fix it they pay me some price I come up with based on their perception of the cost, and if I can't I won't charge them anything. And invariably once I fix one problem -- show that I can add value or reduce costs -- they think of other things I might help with. I'm simplifying but basically that's how it works. I don't have to persuade the customer that I have this or that skill on my resume. Of course you need to actually solve problems. That's how you build long-term relationships with customers, because every business needs people who can solve problems. As a freelancer I focus on smaller companies, not necessarily mom & pop, but small enough that I'm talking to someone who can make a decision.
You can use similar techniques in full-time job interviews, but again it will work better if the interviewer has hiring authority -- rare in larger organizations these days when you have layers of people to get through. Rather than sit there while the interviewer goes over my resume and tries to mentally match that to whatever job they have posted, I ask "What can I start on tomorrow to solve an actual problem you're having?" And chances are good they have a list of things they would like to get someone to deal with. Now I'm not getting grilled over why I quit a job eight years ago, I'm getting a description of something that maybe I can do to show my value.
When I have been in the interviewer seat I see the same deer in the headlights faces over and over, worried and nervous, not asking any real questions (or asking something irrelevant), waiting to defend themselves if asked about details on their resume. Don't be that person sitting in the chair sweating it out. You have just a few minutes to make an impression so show confidence, make eye contact, show that you researched what the company does, and ask about problems and pain points you can help solve. That changes the tone of the interview, and the interviewer will remember you as someone who at least showed some spirit and initiative. You have nothing to lose -- worst case is you don't get the job, which is where you were when you walked in the door.
Wow, thank you for sharing. Tons of wisdom in this comment.
I myself only had the realization recently (5 years into this career) that being a good software engineer isn’t about learning any particular programming language. The fundamentals of all languages are roughly the same, and understanding those fundamentals deeply is the knowledge which will be transferable over time. I learned this lesson in an online course called “Programming Languages”, taught by a professor at University of Washington.
Question for you - do you think the “engineering” side of “software engineering” has been forgotten over time? Did it ever exist?
I myself only had the realization recently (5 years into this career) that being a good software engineer isn’t about learning any particular programming language. The fundamentals of all languages are roughly the same, and understanding those fundamentals deeply is the knowledge which will be transferable over time. I learned this lesson in an online course called “Programming Languages”, taught by a professor at University of Washington.
Question for you - do you think the “engineering” side of “software engineering” has been forgotten over time? Did it ever exist?
I never refer to myself as an "engineer." I got to "Senior Programmer/Analyst" in my 20s and I've just continued to call myself a programmer. I've found that titles don't mean much in the software industry. I meet people just out of school a few years going by Senior Software Engineer. Either you can solve problems and add value to the businesses you work for, or you can't. Either way the title you use makes no difference.
I know that many companies have internal designations tied to pay grades, like SWE II and so on. Other than the implied higher pay and more responsibility I don't think those titles mean much either, because they vary too much across companies.
If you mean can we credibly call programming an engineering discipline, personally I don't think so, but I have friends who argue the other side. I think of engineering as a trade that has established standards and practices so every new batch of juniors doesn't have to start from scratch and make the same mistakes. Those practices should allow engineers to reliably, predictably, and repeatedly make something from a plan or specification. I'm sure I could find exceptions, but most of what gets called software engineering has none of those attributes. We can't predict or estimate software projects accurately, not even close. We can't promise a reliable result, or even that the result will meet requirements. Even if the project succeeds we can't confidently repeat the performance, or show another team how to succeed.
I did some work in the automotive industry. The engineers who design cars and the processes to manufacture and test the cars work from very detailed specifications, and they can refer to a long history of what worked, what didn't, and why. Cars got incrementally better during my lifetime along multiple axes: safety, efficiency, performance, features, comfort. And the engineers who design and build cars can predict costs, schedule, and promise a working vehicle. It doesn't always go right, of course, but real engineering processes like that are a couple of orders of magnitude better at delivering as promised than software engineering.
Literally decades of study have gone into making programming a more engineering-like craft. A lot of good ideas got written about and tried, but then forgotten and rediscovered and renamed, repeated over and over. When companies stopped mentoring and expected junior programmers to hit the ground running, trained at university or a boot camp or on their own, they discarded the apprenticeship part of the training actual engineers and people who work in the skilled trades still get. It doesn't help that juniors start calling themselves senior when they get their third or fourth tutorial project to run, but I think the failure to cultivate and grow talented programmers goes beyond a few eager young people wanting more pay. I feel lucky that I got into programming at a time when employers had to put some effort into training and mentoring, and growing their people into more responsible roles, because I don't see that at all today. That really was better in the past than it is now. And I think that's what separates real engineering from just calling something engineering: a shared body of history and understanding of the fundamentals of the craft, what has worked and what hasn't, and some provably correct principles that lead to predictable and repeatable software development.
If you want to learn about how people get training in a difficult and competitive trade, learn their craft through apprenticeship and mentoring, read how Anthony Bourdain or Gordon Ramsey worked their way up as chefs. They didn't just get out of culinary school and call themselves masters the first time they didn't burn scallops. Mastering any complex skill takes time, practice, and the opportunity to learn from experts, and to learn from your own mistakes and the mistakes other people made.
I know that many companies have internal designations tied to pay grades, like SWE II and so on. Other than the implied higher pay and more responsibility I don't think those titles mean much either, because they vary too much across companies.
If you mean can we credibly call programming an engineering discipline, personally I don't think so, but I have friends who argue the other side. I think of engineering as a trade that has established standards and practices so every new batch of juniors doesn't have to start from scratch and make the same mistakes. Those practices should allow engineers to reliably, predictably, and repeatedly make something from a plan or specification. I'm sure I could find exceptions, but most of what gets called software engineering has none of those attributes. We can't predict or estimate software projects accurately, not even close. We can't promise a reliable result, or even that the result will meet requirements. Even if the project succeeds we can't confidently repeat the performance, or show another team how to succeed.
I did some work in the automotive industry. The engineers who design cars and the processes to manufacture and test the cars work from very detailed specifications, and they can refer to a long history of what worked, what didn't, and why. Cars got incrementally better during my lifetime along multiple axes: safety, efficiency, performance, features, comfort. And the engineers who design and build cars can predict costs, schedule, and promise a working vehicle. It doesn't always go right, of course, but real engineering processes like that are a couple of orders of magnitude better at delivering as promised than software engineering.
Literally decades of study have gone into making programming a more engineering-like craft. A lot of good ideas got written about and tried, but then forgotten and rediscovered and renamed, repeated over and over. When companies stopped mentoring and expected junior programmers to hit the ground running, trained at university or a boot camp or on their own, they discarded the apprenticeship part of the training actual engineers and people who work in the skilled trades still get. It doesn't help that juniors start calling themselves senior when they get their third or fourth tutorial project to run, but I think the failure to cultivate and grow talented programmers goes beyond a few eager young people wanting more pay. I feel lucky that I got into programming at a time when employers had to put some effort into training and mentoring, and growing their people into more responsible roles, because I don't see that at all today. That really was better in the past than it is now. And I think that's what separates real engineering from just calling something engineering: a shared body of history and understanding of the fundamentals of the craft, what has worked and what hasn't, and some provably correct principles that lead to predictable and repeatable software development.
If you want to learn about how people get training in a difficult and competitive trade, learn their craft through apprenticeship and mentoring, read how Anthony Bourdain or Gordon Ramsey worked their way up as chefs. They didn't just get out of culinary school and call themselves masters the first time they didn't burn scallops. Mastering any complex skill takes time, practice, and the opportunity to learn from experts, and to learn from your own mistakes and the mistakes other people made.
Thank you so much for this comment, my blown away by both this comment and your follow up´s!
From time to time, this kind of post reminds me why I still love HN.
Thank you for great advice for this young man !
Thank you for great advice for this young man !
Everyone and their dog has been told in the last decade that learning to code is important. I've grown up hearing that sentiment consistently and I'm sure it contributed a lot to me falling in love with this field.
However, coding (at least in its current form) seems like one of the most at-risk forms of work in terms of AI automation. I love writing code and I think I'm good at it, but I'm not so sure I'll be able to compete long-term with AI. I'm sure there'll be a few "John Henry"s, but many devs will probably change. Keep in mind, I'm thinking on the scale of length of a whole career and not saying this is happening already. However, with LLM context lengths increasing and special hardware made for ML inference (like groq), it feels like we're not far out from repo-level AI coding. At this rate of development, I could imagine a decade of progress might transform many aspects of day-to-day work for software development.
With all that being said, what advice would you give to someone just starting their career who wants to avoid shorter-term local maxima? I've heard lots of mixed reviews on PhDs and advanced degrees compared to working in industry, but should that calculus change with AI? Thank you!