I used to be solidly on team "anyone can code." That changed when I talked to my therapist about it.
ME: I'm a big believer in neuroplasticity. I think anyone can learn to do anything, it's just a matter of how long it takes.
THERAPIST (visibly uncomfortable): I don't think that's fair.
ME: Why not?
THERAPIST: Well, for example, my partner and I have very different skills. I'm no good at some things she's really good at, like math, and it wouldn't matter how long I try to be good at them, I'd be wasting my time. People are just different.
ME: Hmmm. It is true that people are different.
THERAPIST: You can't choose how someone else spends their time, but if you go in with the attitude that everyone can be good at everything, you're putting unrealistic expectations on people who may not be cut out for something.
I gravitated to "anyone can code" because it sounded egalitarian and humane, a battle cry against gatekeepers and elitists. But that was false empathy. "Anyone can code" sounds like a motivational poster, but in practice it behaves like a standard of judgment. If anyone can code, but you meet someone who really can't—despite years of studious effort—how do you resolve that without putting them down? "They just need more time" is a nice thought, but it won't hold up forever. No one should waste years of their career on something they're not good at. It isn't fair to them.
Maybe that person is you. You did the four-year degree, or the bootcamp, or Codecademy, and you floated around looking for contracts for a little while or joined a tech company. You've been paying attention and asking questions and trying to wrap your head around business requirements. You've been doing this for a year or more. But at the end of the day, it's not clicking. You look at code and all you see is a solid wall of gibberish. Even if you spend all day chipping away at it, you won't understand what it's doing. And forget contributing; unless someone tells you where to go and what to do, you can't figure out how to make things happen.
NOTE: For all you devs with imposter syndrome: if you've been at this for less than a year, or you regularly fix bugs and complete small tasks without guidance, I'm not talking about you. Go find something else to worry about.
If this sounds familiar, the first thing you need to know is it's okay. Not everyone can code. There are lots of smart and driven people who can't code. Coding is its own thing. If you're not good at it, that doesn't mean anything about you.
The other thing you should know: you don't need to throw away all the time you've spent trying. Maybe your next job title isn't "Software Engineer." But being almost a software engineer is a powerful credential that can set you up for success in a lot of other careers.
Let's talk about a few of those.
Project Manager
Job description: A project manager coordinates the efforts of a team of developers, making sure they reach project goals on time and on budget. They translate those goals into features and tasks, then prioritize and assign them to their team. Along the way they collaborate daily with developers to understand the cost and impact of each task, resolve any ambiguities in the specifications, and figure out who's best suited to build and own each piece of the project. They also facilitate communication with QA, UX, and upper management.
Why you, why now: You'll be more effective as a project manager if you know a few things about code. You'll be better at knowing what's feasible and what's not, estimating the size of tasks, and suggesting ideas to help meet customer needs without introducing too much complexity to the project. You'll also be able to understand a lot of developer-speak that many project managers struggle with. You'll recognize when something's wrong with the development process and know the right terminology to talk about it. You don't have to know any code to be a great project manager, but it helps a lot.
Quality Assurance
Job description: QA Analysts test software to find bugs, performance issues, unmet requirements, and other deficiencies. They write test cases as features are built, then re-test them regularly to make sure new code doesn't break what came before. Some QA Analysts are also QA Engineers, writing end-to-end tests with tools like Selenium and Cypress to test applications quickly and automatically. QA sometimes has the reputation of being a "stepping stone" to software development, or a "less-than" career in terms of prestige and salary, but this is changing. Smart companies recognize that QA is a unique profession with its own skillset and significance, and a great QA is just as valuable as a great developer.
Why you, why now: QA Analysts with a background in code write better bug reports. They know what kinds of mistakes can cause bugs, what else they should test to help narrow down the problem, and where to look for additional context. A well-written bug report can make the difference between a bug that takes all day to fix and one that only takes a few minutes. Basic coding skills are even more beneficial to a QA Engineer, since automated tests are typically written in (or supplemented by) code. But even if software engineering isn't right for you, you may be a great QA Engineer; automated tests use a smaller code vocabulary and are less abstract than applications.
Technical Writer
Job description: Technical writers leverage a deep understanding of applications and APIs to write documentation, release notes, video scripts, courses, and even marketing materials. These make it possible for end users and others in the organization to understand and use their team's software. Technical writing is multidisciplinary: it sits at the intersection of technical skills and communication skills, making it a great fit for people who take a lot of notes and are good at explaining things.
Why you, why now: The better you understand something, the better you can explain it to someone else. You'll need to spend time talking to developers or project managers to understand what they're building. If you already know some coding terminology, it'll save you a lot of time. You'll also have the ability to understand not just what, but why. This will help you communicate more clearly and avoid setting false expectations for readers.
UX Designer / UI Designer
Job description: UX designers work directly with users to understand how they use a product, then translate that information into specific changes the development team can implement to improve the product's design and flow. Depending on where you work, "UI designer" and "UX designer" may be synonyms, but UI designers are typically more focused on an application's branding, style, and appearance, while UX designers specialize in understanding workflows and gathering user feedback.
Why you, why now: If you have an artistic bent, transitioning to a career in design is a great way to put your programming knowledge to use. Designers who know code are better at understanding what kinds of UI elements and changes are easy or hard to implement, so they can make more efficient, practical decisions and help engineering teams deliver faster. They can also suggest improvements that may not be obvious on the surface, but make applications more unified and maintainable under the hood.
CTO / Engineering Director
Job description: Managers and executives in technical organizations are in charge of vision, strategy, policy, and resourcing. In other words, they make decisions that affect teams and careers over the long term, so the people working for them can focus on decisions that affect products and interactions in the short term. A good leader knows how to find obstacles and bottlenecks before they become showstoppers, and they can be trusted to fix them.
Why you, why now: As a leader with a programming background, you'll know what to expect from programmers and how to get the best out of them. You'll understand the rhythm of development, so you'll be able to sense when something is wrong. You'll also have instant rapport with the people who make your product happen; programmers are more likely to trust someone who speaks their language, and in leadership, trust is everything.
And a thousand others...
Job description: Science, healthcare, law, public policy, sales, administration, and just about everything else.
Why you, why now: Learning to code isn't just about vocabulary and syntax rules. First and foremost, it's about learning to think methodically, understand abstract concepts, work with constraints, come up with creative solutions, see details without missing the big picture, and make your own path from A to Z. These are helpful skills in most careers. You'll never regret learning how to see things the way a computer sees them.
Top comments (22)
I liken it to Anton Ego's explanation of the motto in the Pixar film Ratatouille: "Anyone can cook".
"Not everyone can become a great artist, but a great artist can come from anywhere."
And, of course, everyone has their own "genius", too, as you alluded to. Not everyone will excel at coding, but everyone has something of equal importance they can excel at.
I really like this point. For some people the genius is coding and for some its QA and breaking the code. You need both to have a quality product. All around things I wish my friends could understand when they want to learn to code.
This is similarly false. It's something we say to make ourselves feel better. And it is very obviously false. I am better at coding than most coders I know, but am I the Michael Jordan or the Tiger Woods of coding? Hell, no. And I never will be.
I will never be the Michael Jordan or Tiger Woods of anything. Talents are not, no matter how badly we want them to be, evenly distributed.
A wiser approach, I think, is: find something you enjoy and can do reasonably well and then do it as well as feels right to you. Stop comparing yourself to others. Stop desiring to be great. Be good enough. Then enjoy your life.
The things I do make me happy. I do them well enough. I waste exactly zero time worrying about how much better others may be. Actually, when I find such people, I happily learn what I can from them.
The constant pressure on everyone to be "great" when by definition only a tiny minority can be is the cause of much frustration, pain, and suffering. And pointlessly.
I explained this in an essay a few years ago. I stand by it.
Well, I never said you'd be as good at your talent as someone else is at theirs. But you can still excel. It's not a competition.
Sorry if I misread you. But I am not sure that everyone can excel at something. I don't see any evidence for it. It just seems like something we tell ourselves to feel better.
But it's only an issue if we think that "excelling" is some praise worthy goal. I question why we need to excel at anything. Sure, if you are doing something (e.g., surgery) where lives are at stake, then maybe. But isn't good enough by definition good enough?
Excelling at anything takes a huge amount of time and effort (and often money). What makes it worth it? Ego? Pride?
This is a very Western capitalist mentality meant, I think, to get the most out of laborers. Many societies even in the modern world have a much more laid back approach to living. What exactly is it that we are rushing to? Why the urgency? Why the pressure to excel?
And isn't the definition of excel "to be distinguishable by superiority : surpass others"? Why this need to surpass others? To be superior? Why the constant comparison? And if excel means to "surpass others", then how is it not a competition?
So there's this weird irony that saying "everyone can excel at something" appears to be promoting equality and inclusion, but then the word "excel" implies competition and superiority. Odd.
But maybe it's just not the right word for what you mean.
I don’t think most people use “excel” strictly to mean “by comparison with others in the field.” To me the word is about forward progress and suitability to a niche. My five year old kid excels at building Mega Bloks. Is he better at it than anyone else? I dunno. But it’s his thing. He’s having a great time and building things he’s proud of, and I’m enjoying watching him.
Everyone can do something like that. If it’s not “excel” by strict definition, that’s okay.
What I’m saying is, I think you’re both right.
Ah! A postmodernist, I see. :-)
You’re (not) wrong. 😉
☝️ YES. Perfectly said.
When I hear "Anyone can code" I also hear the line from the Pixar film "Anyone can cook".
I've personally never believed that anyone can do it, as I've seen and experienced how different people have different mindset which in a way inhibits them from getting into coding or anything close to it.
Maybe the never generations are going to be a bit different as they where born with technology...
Whenever I explain this to people, they tend to think that I have some God complex, but in my opinion, people need to learn what they are good and comfortable with. People have different talents.
An anecdote from my life: I've met one of my best friends while majoring computer science. While concepts just clicked for me, it took him tremendous amounts of time to get them. It was really demotivating for him, as he always had that mentality that everybody could learn anything. After failing first year, he accepted it and now he is an amazing micro-biologist.
From my view, it is part of life to figure out what your talents and passions are. Acceptance is sometimes a big part of it and denying yourself what you're really good at can sometimes block happiness.
Agreed. I believe it’s not bragging to say “I’m good at X” and it’s not fishing for compliments to say “I’m bad at Y”. If you’re being honest and upfront about your skills and challenges, that benefits everyone.
This reminds me of an argument I had with my employers when I was teaching web development "bootcamps" a decade ago. They essentially accepted anyone with the money to pay for the course. And they told them all, "you can learn to code". Worse they said that they could learn enough to get a job in 12 (or 18) weeks.
As a teacher with more than forty years experience and a coder for roughly thirty, I can say with certainty that not everyone can learn to code. Coding is a very specific skill that involves an ability to think both very abstractly and very logically. And an ability to both analyze and synthesize.
Some people can't code at all, no matter how much effort they put into learning. Those people got screwed by the bootcamps. They spent $10k+ and gave months of their time and endured endless frustration and in the end, after a fruitless job search, they gave up. They never should have been accepted in the first place.
Then there was another group that might be able to memorize enough and learn a few patterns, and they might survive in some commodity coding role, i.e., mostly configuration and the same thing over and over again. But they will never write quality bespoke code.
So I commend you on your realization that just because something came easily to you, it is not automatically doable by everyone. I'm never going to be a dancer or a singer or a poet. (For a small donation I will sign a document promising never to try.) But I can code. It just comes naturally.
Know when to pivot. Do what you're good at.
I actually wrote an essay on this recently.
And even within software development domain, different people are good at different aspects.
Coders are analogous to plumbers sweating out with elbow grease and spanners.
Q: what are some of the elbow "greases" of the software realm?
I think it is fair to list out some of those and post them.
I don't see lots of that.
Instead, there's a sense of software being cool with the perks of high salaries, free food plus working from home, etc.
No one talking about 60hrs work week and mental and psychological agonizing at 3 am over bugs or support rotations and the dreaded SPRINT standup daily.
Anyone can bake a cake alright. But to really bake a sumptuous one consistently is another story.
Same with coding.
None of this is normal and someone needs to say that. I've worked some 60 hour weeks in my career, but not a lot—fewer than 10 in as many years. I don't think I've ever been up at 3 AM fixing a bug. I've done support rotations, but they're usually uneventful.
You're right about standup, though. It is a daily thing with a lot of teams and it always goes way too long.
Interesting point of view. I do think everyone has different skills, personalities, and mindsets that contributes to a "I'm not getting this!".
How would you incorporate someone's interest or enjoyment in coding? Do you think that can have an effect in the person's ability to code?
I really like this realization you've laid out here, Isaac. Coding is not meant for everyone, I totally agree. We all have our set of skills and quirks that makes us unique and I wish for everyone that they can find a field where they can put them to use 🙌
I disagree with becoming a CTO or even a Project Manager as an alternative to keep improving your coding skills, though. If software development and coding are not your cup of tea, I recommend that you avoid being a technical lead in any of their forms 😵
This comes from my experience in both watching inexperienced bosses lead teams to their doom and being in charge of developers that exceed my skill. Sadly, devs won't respect bosses that can't keep up with the team. The solution is not to hire worse devs, but to have a better CTO or PM. So, even if bosses are not coding all the time, they should be reading, learning and keeping their skills up to date. I've found that this kind of technical leads are the ones that foster teams where everyone wants to work at 🙂
I’ve never had a project manager or CTO that could code at the level of the team (at least not in the stack we were working in). Some of them have been really good, others not so much. So maybe there’s some experiential bias there on my part.
I feel the “anyone can code” idea (now grown into a meme) comes from (suspicious) sources, such as:
As others say the issue is not about who can code, it’s about who chooses to and can make a living in software development. I can dance … but have no ability (or interest) in trying to make a living dancing.
Thank you for saying this! I to have tried to tow the "anyone can code" line and while technically it's true (just like anyone can play basketball) it does not mean anyone can make a living doing it.