(Or, In Which Maria Reveals She Has No Sense Of Time)
Upon receiving today’s Outreachy email, in which participants were advised that for their week 3 blog post, they’d be writing on the topic of “everybody struggles,” my first thought was: why are they sending these out so early?
And then I actually, ya know, checked the date, and I realized, holy cow, it’s already been two weeks! Two weeks … out of … twelve?
This internship is already a sixth over?
I’ll be honest. I wasn’t entirely certain how to feel in that moment–but then I had to laugh, because today was the first day in the entire two weeks where I’d felt truly frustrated. At one point, I ran python manage.py runserver and thought, woo hoo! It’s there, I added in this new feature and fixed that bug!–and then clicked on a link, only to discover I’d somehow invented an entirely new problem, one that was making things happen I could not have implemented if I’d wanted to. I literally yelled, “What? Why?!” at my computer, before leaving to pace circles around my house.
It had taken me 2+ hours to get to that point. And when I decided to go back to the last commit and try to do the thing I wanted again, I typed everything in once–and everything was suddenly working perfectly and testing good. It took literally two minutes. (Typo? Forgot to save? Whim of the Django gods? WSL2 not playing nicely with VSCode? Who knows?)
So of course the very next thing to land in my inbox was a scheduled blog topic called, “Everybody Struggles.”
Although we were given some prompts for this particular post, I’m going to expand out from them a bit, because this experience (and the last two days in particular) have really taught me some things that I’ve actually been wanting to write about, and I think they relate pretty well.
Things I have Messed Up Opportunities For Growth:
TLDR: Just because you can do it, doesn’t mean you should (or, Django is smarter than you, and that’s okay.)
One of the hardest things for me to reckon with as a new programmer is that I’m a perfectionist. This sounds good, but can be really annoying: when my partner and I were trying to build a deck and a nail went in crooked, I spent ten minutes googling “proper hammer techniques” and learning said techniques before coming back with a primer on correct hammering. (Did the nails go in straight? Yes. Has my partner forgiven me? This is less conclusive.)
If I’m doing something new–from cooking a dish to driving to a new location to making a major purchase–I want to know the most-efficient/most-common/best-practice way to do things. It makes me feel safe and gives me a warm, fuzzy glow.
And if you’re a software developer or programmer or, honestly, have ever used a computer, or are over the age of … ten? … you’re laughing your buns off right now, because a lot of times, there isn’t a right way. There’s a right way for right now, which comes down to things like project goals and your abilities as a programmer and team composition and project architecture and if making a change is going to break everything.
And this is especially something to keep in mind when you’re early in your learning journey. So, for example, I had just started learning about and implementing class-based-views (CBV’s) in Django right before my internship started, mostly so that I could bake out my portfolio using Django-Bakery as static flat files (and whoa, this package works amazingly well, and I am in love.) And, if you’ve ever used CBV’s versus function-based-views (FBV’s) in Django, you know that they’re … hella-cool. What’s this, two lines of code, and you’re gonna just render my site/posts/blogs/database-objects-as-pages/whatever? Neat. How elegant! How pretty! OOP for the win!
When I started getting into the nitty gritty of my internship project (an anonymous GitLab ticket interface for Tor), of course I wanted to use CBV’s. They’re better, right? And I know how to use them, right?
Except that one major difference between FBV’s and CBV’s is that in a CBV, the “under-the-hood” logic is all happening off-screen–vs a function-based view, where you’re defining your functions and spelling everything out explicitly. There are also places where you’re just better off with a FBV–like when you’re developing a new project and not sure what direction this particular view is going to go in, and you’re constantly implementing and pulling out new features–or when the page you’re creating requires some special logic that doesn’t natively come pre-packaged in a CBV, and you wind up having to redefine a bunch of kwargs and how the view gets context and now you’re kind of panicking because you did all these things and something way, way later in the view needs to be changed to make this new User Identifier validation method thing work but you don’t understand how all these pieces interact and–
And if I don’t know what’s really happening in my code, it also makes it hard to ask for help, because the first thing any smart mentor/friend/stack-oveflow/random-stranger-in-a-bar is going to do is try to help you rubber-duck the issue, which doesn’t work if you don’t even know what’s happening. (Just kidding on the bar–there’s a pandemic, people. I haven’t left the house in months.)
Which is how I wound up having an epiphany: hey, Maria, maybe you should just … do this as a function-based view right now? You can always make it a CBV later if you want.
So, that’s what I did. I redefined the view, writing out my own functions–and then I wrote the tests, which I now understood, because I now actually knew what the functions were doing–and the tests helped me understand the functions even better. And when I hit a snag that I just could not figure out myself and I contacted my mentor, we solved it quickly and easily, because I knew what my code was actually doing and when it was doing those things.
(And then I promptly broke everything four minutes later again.)
The point is … wait … where was I?–oh yeah–when I was googling frantically for an embarrassing amount of time, I learned a number of lessons.
The first is that Django is a mature framework–as in, it’s been around since 2012–and in that time, it’s grown and expanded to the point where there are a lot of ways to accomplish any given goal. It’s almost impossible to know them all. I know people who have been working with Django full-time for years that tell me all the time they figured out a new feature/package/problem-solution, so it’s a massive amount of ego on my part to think that it was even possible to just “do things the best way.”
The second is that most of the time, the way that works and that you also understand is the best way. You know it, I know it, we all scream for Talenti Mango Sorbetto–but it’s still hard to put into practice sometimes, because, again, it involves checking your ego at the door.
But part of being a good programmer is saying, hey, what are my capabilities right now? What is something I should leave as a stretch goal for the moment? When should I just be trying to solve this problem, versus refactoring? (In other words, don’t get ahead of yourself, Maria.)
The third, final, and most important (probably–I mean, these are all real valuable lessons here) is that I need to stop being so reluctant to ask for help. If I had even tried to reach out somewhere before the two-hour mark, I would’ve immediately realized that problem numero uno is that I didn’t know what my code was doing, but I didn’t ask my mentor, because I was embarrassed and there is always a little voice squawking in the back of my head with some version of you’re not a real developer–you tricked them into picking you for this internship–if they knew how dumb you were they would be horrified.
(None of this is my mentor’s fault, by the way. Alexander Færøy is literally one of the nicest people I have ever talked to.)
Wait, I lied:
I know I said that last lesson was the final one, but there’s one more lesson in there, one that only occurred to me during the writing of this post:
I need to push back against the imposter-syndrome voice more often. Especially in light of its probable origins.
I’m sure it’s partially due to things better discussed with a therapist–but given that almost daily, we have to read about some tech-bro that hires women based on their hotness rating–or research from Github that shows that women have their PR contributions accepted more often than men, but only when they’re not identifiable as women, I’m sure a significant chunk of it is internalized bias about being a woman in tech in the first place.
Although I’m fairly new to Python/Django and programming in general, I’ve always hovered somewhere STEM adjacent. I got into a magnet school for math and science when I young–only to drop out, despite doing pretty well academically, because I didn’t feel like I belonged. I was constantly being told how unsexy geeky women were (I am oldish; I hear this is changing) while simultaneously hearing about everybody’s family yachts and Aspen trips and Ivy League aspirations. I didn’t feel like something “hard” could be right for me, despite the fact that I was a huge biology nerd that was also already building computers and making websites in freaking notepad.
(Side note: My career in healthcare? Yeah, no better there. Despite the fact that over 90 percent of the professionals in my graduate-level specialty are women, I found that sometimes, having a male receptionist repeat what I was saying to patients/other providers magically made them agree with my original points.)
Truth be told, I still wouldn’t be working with Python or Django if I didn’t have a friend that is actually a DjangoGirls organizer who has been encouraging me down this road from day one. And when I started seriously considering that hey, this might be a good fit for me, I looked at other languages and frameworks, but decided that I wanted to stick with Python/Django because the community is just so freaking positive and helpful and inclusive. It just felt safer than some of the other communities, because there were organizations like DjangoGirls.
Whoa – You actually made it this far? Okay, a final gift!
If you, perhaps, are also a perfectionist that needs to know everything and happens to be moving into a better understanding of CBV’s, you, too, will squeal with joy at Classy-Class-Based-Views. Although the Django docs are amazing and complete and beautiful, tracking all the implicit methods in each of the generic CBV’s and its ancestors, etc., can be a real chore. This site lays it all out, like one of those giant anatomy wall-charts of every muscle in the arm. I seriously love it, and if you’re like me, you probably will, too.