How to be a successful INTJ computer programmer
Thursday July 28, 2016
TL;DR: Be very cautious about pursuing a career as a person who makes things. Programming is sometimes a better fit as an INTJ hobby. And if you’re trying to learn through academia, that’s sometimes double-hard for INTJs, who generally learn best through hands-on, real-life projects and build theory from the ground up via experience. I’ve included learning tips and relevant details below. Also be sure to read to the end, because TL;DR isn’t really a great learning paradigm, right?
How can you be super successful as an INTJ computer programmer?
Related Article: An INTJ-friendlier Introduction to Programming
For many INTJs, the answer seems like: You can’t. And the longer you stare at online developer portfolios and see what everyone else is doing, the longer you watch your goals outstretch your worst-case deadlines, the more you talk up your goals when your friends ask about them, the more you will tend to wonder why.
Why can’t I do this? I know others who do. Those guys are idiots compared to me. They didn’t even know about framework X when we talked tech at lunch last week. Framework X is the best framework available right now.
I already know that. I’ve been building a…building a…build. Build, man. Why can’t I build anything?
I talk the talk but I procrastinate everything. Am I lazy?
I just took a super long lunch. I mean, I got the job, they like me. The boss has been asking about that big project I promised to make progress on.
But here I am on this park bench and I’d rather be doing just about anything else. This morning from 10 to 10:30 I sat in the quiet corporate bathroom on the other side of the building and read Dostoyevsky.
Who’s this guy? Don’t make eye contact. Wow he looks like…
I’m future you.
You’re using your gifts right now, you know that? Sitting on this park bench, listening to your perception.
You are very gifted when it comes to perception.
Have you thought about perception as a career? Forecasting? Strategy? Research and analysis? Contingency planning?
I know, programming is none of those things.
But one implication of your interest in programming is, you may think you need to be programming, creating things by hand.
Programming can be a mental stand-in, symbolizing scheduling. “Get with the program.”
So, try scheduling things more often, see if you’re still interested in programming.
The act of programming itself may not really be where your main gifts are. It’s a part of you that might even be pretty weak. You might get anxious when you try to do it more than a tiny bit at a time. So be sure to feel out this skill and look for objective ways to evaluate your progress.
In general, INTJs can also be biased to think they need to be the ones to do all of the things by themselves. No systematization, no delegation—just you, doing it all. You should also determine whether you need to be that involved in the “little picture,” or if you’d rather find a way to base your career on the INTJ’s “big picture” gifts: Planning, strategy, and so on.
After all, when the waves of details come up and bury you, you might feel crushed. You wanted to put on a good show, and instead your hands became tied again.
This is also a good time to mention: If you’re looking into such cold, logical, mechanistic things, please also start taking better care of yourself. Hard must be supported by soft, so to speak.
When things are hard, learn to let them feel hard. Feel it! Then go home and relax. Allow yourself to take breaks, evenings and weekends off, and schedule vacations.
When you’re ready once again to dive in, start doing research. Attack the problem. Add in some analysis—theories of what would be good for you. Make a simple list of next steps. Put effort into that. It won’t get as hard nearly as fast as programming will. There’s no guarantee it’ll make you a billionaire, but none of the really mature, happy INTJs need that stuff anyway. (I know, I coach them. They’re amazing, but mostly they want to feel like they are solving problems and learning things.)
Eventually, you’ll build your own frameworks and rule sets for success in various areas.
And as you refine those rules and frameworks, they’ll start to work even better.
You were right to come to the park bench. And the bathroom time was well used, believe it or not! Your body knows what it needs. Don’t blame yourself. Hang in there.
[Note: This first part of the article was a compilation of my thoughts and experiences around the phenomenon of many, many INTJs being ground to bits by university-level CS programs, or by new jobs in the field. I hear from them all the time. If you are reading this and feeling deja vu, get in touch please, as I’d love to hear your experience]
Let’s say you’ve come up against this problem, but you need to be programming right now. Or you’re already a programmer and want to improve.
Here are the keys I’d encourage:
- Fix what you (intentionally) broke
- Constant Brain Dumps
- Ongoing Rule Refinement
- Remaining Open to Delegation and Oversight Roles
First: Fix what you (intentionally) broke
You may be familiar with INTJ Mark Zuckerberg’s original Facebook motto, “move fast and break things.” The motto was later changed to something less risky, but I thought the original was a good lesson in how INTJs can learn to program.
Here are the steps:
- Intentionally do something that won’t work
- Think: Damn, it’s broken! On purpose, but still broken!
- Use your logic & research skills to figure out what’s broken
- Fix what’s broken
Eventually, you’ll learn to program backwards, which is important for INTJs. While a university CS department will probably teach it to you forwards, starting with a bunch of tiny little definitions of abstract concepts, you probably need to start with the big picture in mind. You need a big blob of stuff with problems.
If you’ll be programming using a framework, download the framework, get it configured, and let it sit there. Later on, list what your next steps are.
If you’ll be programming from scratch, you probably at least need a pile of pseudocode to troubleshoot. So start writing comments—and then attack the pseudocode that seems most interesting OR easy to you.
And: Start googling up solutions like there’s no tomorrow. Your pseudocode says “detect if the user submitted a form”? Then google, “how to detect if the user submitted a form.” Start copying & pasting and seeing what sticks.
This is a fantastic way to start fast, with broken stuff that kind of works! Congrats, you are moving fast and your stuff is broken!
Over time, you’ll learn to make it yours. And then you’ll discover first principles. And then you’ll probably be able to create new programs by starting from first principles, if you want.
(And look, I’m not here to tell you how to ideally learn how to code. I’m telling you what will probably work for somebody with cognition like the INTJ.)
Second: Constant Brain Dumps
In order to be most effective, the INTJ brain needs opportunities to dump information. You might do this in:
- A journal (example: Jordan Mechner’s Prince of Persia and Karateka development journals)
- A text file (example: John Carmack’s .plan files)
- A website or web page (example: JWZ’s web pages and blog at jwz.org)
Personally I feel these are least effective when done for an audience. You should feel very little pressure to compose for some public blog audience, and spend most of the time getting information and ideas out of your brain.
It’s crucial to eventually bring your writing around to the most daunting items that you need to accomplish. If you write thousands of words and avoid those things, your brain dump isn’t really a brain dump.
Once you have externalized the most stressful items, you should start to explore them, ask questions about them, prod at them. This is known as extraversion and is critical for us introverts. This kind of extraversion will help us solve problems in the exact way that avoidance won’t.
[Personally, I keep a text editor open at all times, and write down whatever comes to mind. Away from the computer I keep a pocket notebook with me.]
Third: Engage in Ongoing Rule Refinement
You should also begin to treat your workday as a laboratory. An ongoing experiment. You can do this by:
- Proposing new ideas that will better your work
- Testing those ideas
- Finding and extracting key leverage points
- Refining the ideas into a framework that is reusable
For example, let’s say you just spent your first week at your new programming job in complete desperation: You highly dislike one of your closest coworkers, the technical documentation is a mess, and you keep getting your lunch stolen.
- Regarding the coworker, start to propose & test ideas for making the relationship work, even if it’ll never be the best. Dive into the research.
- Regarding the documentation, start to propose & test ideas for learning what you need to learn. Perhaps, for example, you think it’d be worth trying to write your own documentation as you go along.
- Regarding the stolen lunches, perhaps you brainstorm a few different ideas: Letting your boss know about it, asking people online, marking your bag, keeping lunch in a cooler inside your car. The cooler turns out to be great! You discover that keeping lunch in your car reminds you to get outside and take a brisk walk during lunchtime. That is known as a leverage point. It goes a great distance toward helping you solve the problem, perhaps even surpassing the original goal. Maybe the goalposts are now moved forward a bit, into “how to have the best lunchtime” or similar.
With each point, the process is the same: Propose, test, look for leverage points, refine. You now know how to develop frameworks that give you huge amounts of leverage over your problems.
Finally: Remain Open to Delegation and Oversight Roles
Eventually it’ll be time to detach from the same day-to-day work you’ve always done. If not completely, at least in some ways, this is going to be crucial.
For example, let’s say you continue coding, but your in-house framework is giving you headaches.
A lot of INTJs would, at that point, figure that the problem is them, and not the framework. This often turns into “let’s keep using the broken framework,” or potentially even worse, “I must quit my job.”
But it’s a good idea to keep an open mind. Perhaps you decide to gradually phase out your in-house code framework and bring in a simple, flexible third-party framework to help you out. And maybe you also contact the company that develops the third-party framework and get referrals to contractors who can help you focus on what’s most important, while they fill in the details here and there.
Keeping an open mind also means pushing a bit. It’s healthy to negotiate with the people on your team—your boss, your coworkers. You can tell them your thoughts, tell them what you don’t want to do anymore, give them potential solutions, and make sure the problem is in everyone’s lap, not just yours.
As an INTJ, your gifts, maximized, are very impressive. Objective measurement coupled with subjective framework-building should get you very far.
But don’t forget to take care of yourself—let your inner ESFP (all four letters, flipped) help determine your life development path. Don’t suppress the inner lazy guy forever. Learn to listen to your heart and be OK with “I’m just done with this.” Have fun, and make sure others know you’re having fun.
If you’re not having fun, I hope this article helped. If you are having fun, I hope you got some new ideas here.
By the way, if you want more concrete programming-learning tips, be sure to check out An INTJ-friendlier Introduction to Programming.
Introduction to than Ward Flen, lang whem →
Blog Updates, 2022-10 →
Keeping a List of Almost 1,100 Personal Interests: Recent Thoughts →
Emotional Eating is Yummy, So Why Not Become an Expert? →
Do you change your body language, mannerisms, or speech with different people? →
Things I Made for You
Own your procrastination with Whole Productivity, a new system → Get my free INTJ COVID-19 Guide → Explore your gifts with my INTJ Workbook → Other Publications → ...and the fake word of the hour: "Edber." Pretty sure it has to do with trial versions of poorly made software.