So software engineering isn't working out for you

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.

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