(and vice versa)
It’s often implied that my two chosen careers are distinctive.
Upon first glance, they do seem contradictory — the mental image of posing in a put-together outfit is at odds with the one spent furiously typing away on a keyboard. It’s “interesting” how I model despite the fact that I also write code professionally, or how I program despite the fact that I also pose for photos professionally. But are the two really that different?
Not really, as it turns out. I started my blog around the time I started programming, and I got serious with shooting and editing photos as I started considering being a full-time software engineer. When I refined my skills in the two areas, I started noticing how the mentality and best practices I picked up from one trade easily translated to the other.
Both are highly technical at the core, but require a certain amount of intuition and creativity to enjoy. Both are essentially creating something (hopefully beautiful) out of nothing. Both require solid project management skills and an eye for detail.
I use tools from the two trades on an everyday basis — I gather requirements, estimate work times, and use a Kanban board for my shoots. I debug and approach code reviews with the perception of a model after the perfect shot. I’m not an engineer despite being a model, or a model despite being an engineer. I am one (at least a far better one) because of the other.
Defining “modeling” and “software engineering”
Before I go on, I want to specifically clarify my usage of the terms “modeling” and “software engineering”, since they may not be the same as yours.
I define “software engineering” as “designing systems, breaking down requirements, writing code, and collaborating with teams to create software intended for people to use.” This includes following Agile principles, using source control properly, and participating in regular code reviews.
I define “modeling” as “styling, posing for, and editing photos to create a coherent set of images that display a specific aesthetic.” This includes taking pictures with Christopher, utilizing various photo editing programs, and directly distributing the final product to either my followers or the points of contact at the companies I work with. (It’s definitely not “modeling” in the traditional sense — I talk more about my specific process here).
How modeling has made me a better software engineer
I’m much more detail-oriented
I want to achieve a specific look with my photos, so I pay extra attention to the small details both when I pose and when I edit. After two years of shooting almost daily, I can spot the most miniscule difference between two very similar photos. Is my head being turned an extra inch to the right on one of them? Is the color temperature of the other too warm by 4%? I can see that shit instantly.
This attentiveness has also enabled me to find misspelled variable names, extra semicolons, and wrong inputs in code extremely quickly (especially when I’m being annoying and using a text editor with no syntax highlighting/compiling and running on the command line). A misplaced dot or equal sign may seem trivial, but little mistakes like those cause the entire program to break.
Of course, some bugs aren’t caused by typos but from fundamental problems in the architecture, but that’s a whole different animal. When it comes to spotting tiny discrepancies, the faster I get to the source of the error, the quicker I can get on fixing it.
I stop trying to make fetch happen
There have been times during shoots where I try a pose for more than thirty shots, only to have them all look awful. That’s when I know fetch (read: the photo of me looking suave leaning against a building when my heels are actually sinking into the ground and my dress is getting dirty from contact with the wall) isn’t gonna happen, and that I should stop trying to force a specific vision so hard.
In software engineering, the specs for what software should be able to do is broken down into tiny, implementable pieces called tickets (ex: an app that edits photos is broken down into individual features such as adjusting saturation, adjusting exposure, etc., and each one of those features are broken down further, until you’re literally left with tickets that say “put labels on the user interface”). Since tickets are created before the actual coding begins, you may dig in and find that the specific thing is a lot harder to implement than you thought. If I try every hacky workaround I can think of and the code still doesn’t run properly, I know it’s time to stop trying to make fetch happen and talk to my team to find a better solution.
I’m focused on making a good end product rather than being overly attached to my work
I try to feature a variety of poses and angles per photo set, but sometimes I finish picking photos and realize that all seven that I chose pretty much look the same — same location, same pose, same angle. Oops. This means deleting some of the pictures I was so proud of, no matter how much I like them, and going back to re-select different ones.
When it comes to software engineering, it’s possible that you can take long periods of time researching and implementing something that ultimately gets thrown out because it doesn’t make sense to include it in the final product. I once spent three days reading articles, taking notes, and prototyping a feature, only to realize that the feature wasn’t actually necessary. I saved it to GitHub for future reference and moved on. My work isn’t my baby, and being able to be ruthless with throwing “precious” stuff away keeps me from falling prey to the sunk cost fallacy.
I solicit and use constructive feedback whenever I can
Constructive feedback/criticism should not only be welcomed, but should also be actively solicited. This is something I avoided as a newbie coder — I had a good amount of impostor syndrome starting out, and was terrified that if I showed my work to anyone, they’d call me out and label me a “bad programmer”.
Modeling made me realize how horseshit that fear was. Having a few photos turn out badly doesn’t mean that I’m a bad model. Likewise, having some of my code turn out badly doesn’t mean that I’m a bad programmer. Coding is a process that can always be done better, no matter how much experience I get. Instead of shying away from feedback or code reviews, I try and go out of my way to seek feedback whenever possible. Once I get it, I reflect on the constructive criticism and think — is it valid? Within the confines of what I’m trying to do, does it make sense to take this person’s suggestions? If so, I make a change. If not, I disregard it and move on. It’s nothing personal.
Complex user interfaces take less time to get used to
My friend once described looking at an IDE, or integrated development environment (basically, a code editor that has the ability to run your code, spot errors, and do a bunch of other cool shit that makes your life as a programmer easier) without knowing how it works as “seeing the inside of a cockpit for the first time.” That feeling of overwhelm and oh-God-better-not-touch-this-lest-it-breaks-something is overpowering. What the fuck are all of those little icons? What do those green lines mean? What’s the difference between a project and a workspace?
I’ve experimented with a lot of different of different photo editing programs over the years (I use three apps to edit a single photo, so imagine how many it took to arrive at those three), which meant that I had to roll up my sleeves, get dirty, and familiarize myself quickly with their user interfaces, some of which could get quite complex. This doesn’t make a new virtual environment any easier to navigate, but I’m more comfortable feeling things out, and once you’ve looked at enough UIs, you start to realize that they all functioning in similar ways. 
How software engineering has made me a better model
I have no shame in hacking solutions
A valuable lesson I learned from working at a startup is that doing things the “right” way is great, but when deadlines are looming, the important part is to get the damn thing working. 
The modeling equivalent of “getting the damn thing working” is “getting that pretty shot, no matter what awkward and ugly methods you have to jury-rig in order to do it.” I’ve used chairs, bags, and random trees to keep Christopher from falling over, squeezed myself into nooks and crannies and alleyways for those colorful walls, pinned and tied too-big garments, left zippers open for too-small ones, and taped sunglasses to my face when they broke in the middle of a shoot.
It’s okay if the process is messy — really! (-reminds self to breathe-) Hacky solutions still bother me, but I’ve learned to use what works.
I’m able to communicate efficiently with companies
In software engineering, it’s important to agree with whoever is designing the product on a general vision of what that product is going to look like and do. Most of the companies I work with as a model have no idea how I get my shots (hint: it’s usually squeezing myself in to a tiny space with a pretty backdrop and jury-rigging the shit out of everything until I get what I want — see above section in having no shame about hacking solutions), but they do know exactly what to expect from me.
The following is an example conversation that I would have about the set of photos featured in this particular post. The dress is actually my own and I did it for fun, but this is how it’d go down if a company asked me to shoot it:
We want you to shoot this striped dress.
Sounds good. It’s a basic print that can be accessorized with anything, so I’m thinking of pairing it with a red statement necklace and black heels. I’ll shoot it against a colorful background with straight hair, dark sunglasses, and red lipstick. What do you think?
Awesome. (Usually they don’t give a shit and trust me with my vision, which I’m endlessly grateful for!)
Sweet! You’ll have it the edited set by 3 PM tomorrow in a .zip file.
There’s no beating around the bush and no uncertainty here — they know exactly what to expect and when to expect it. If there are objections, they will let me know, and I’ll fix it accordingly. Efficiency and effectiveness are key!
I make accurate estimates about how long a task will take
In my experience, a day on the job as a software engineer consists of obligations previously made (one-on-one discussions, meetings, code reviews, et cetera), lunch, and using the rest of the time to code. There’s a good amount of autonomy involved. This lack of structure means that it’s up to you to let people know when they can expect results. When you’re assigned a ticket, you have to give accurate time estimates, or you’ll piss a lot of people off by taking way longer to implement something than you said you would. I learned that the hard way. 😛
Since then, I’ve gotten used to timing myself for almost everything, including taking photos. I know that shooting a single outfit takes around 30 minutes (45-60 if I’m doing multiple locations), and am able to block out specific times in my schedule for shooting and communicate to companies as necessary.
I break down overwhelming tasks into small problems
I used to get overwhelmed at all the variables that went into a shoot — which location should I go to? What outfit should I wear? Should my hair be straightened, curled, or natural? What accessories would I use? What about makeup, shoes, and sunglasses? It’s a miracle that I wasn’t a neurotic mess all of the time.
If there’s one thing that programming has taught me, it’s how to break things down into digestible chunks and to streamline every possible process. Now, when I’m heading out to a shoot, I start with a location I feel like going to, then run through a mental checklist to determine the other variables. I’ve really internalized it so it’s kind of hard to describe, but it goes something like this.
Conclusion: the idea sex is mind-blowing (and idea babies are the only type of babies I’ll be having, thank you very much)
Choose one thing and become a master of it. Choose a second thing and become a master of that. When you become a master of two worlds (say, engineering and business), you can bring them together in a way that will a) introduce hot ideas to each other, so they can have idea sex and make idea babies that no one has seen before and b) create a competitive advantage because you can move between worlds, speak both languages, connect the tribes, mash the elements to spark fresh creative insight until you wake up with the epiphany that changes your life.
– Justine Musk
Justine Musk sums it up perfectly. Pursuing programming and modeling careers at the same time has introduced me to ways of thinking and ideas that I would never have gotten otherwise.
Plus, not gonna lie, I always like to see the looks on people’s faces when I tell them that I’m both. 😏
 This is actually on purpose, and many strict UI guidelines exist — check out Apple’s Human Interface Guidelines and Google’s Material Design to see what I’m talking about. The argument goes that since people are already used to certain user interface elements being used in certain ways, it’s better to give them what they want. Imagine if you got an app where buttons were actually text fields, and vice versa. I don’t know about you, but that would certainly make me throw my phone across the room … and, more importantly, it would make me delete the app, which is the exact opposite of what its creators want me to do.
 This doesn’t mean everything is hacked together, though. My favorite part of the coding process is actually refactoring, or going back and cleaning up the messes that you made while getting the damn thing to work. It’s really calming seeing your once messy code become clean.