Community bonding is an excellent way to introduce accepted students to the community, get them on the right mailing lists, get to know their mentors and team and work on their timeline for the summer. Though the most exciting part about the entire Community Bonding period at was getting to know the entire QTE & Release Engineering team, I got to learn a lot during this phase. This post is essentially a compilation of the various things that I’ve learnt during my first month as a student developer at Wikimedia Foundation.
Treat Code as cattle not pet
Code is like cattle: you use it when it's useful.— Željko Filipin
We all like to think code-reuse is important and while it is, it’s not meant to be about raising a child. Code doesn’t feel. Code doesn’t care. Code will turn on you like Ultron. Code is just bytes. Code is a liability. Code is just one of the many ways of expressing an idea and it’s you who controls the idea and not the idea that controls you. Code, by its nature, is not just inextricably glued to its language, platform, and the APIs it consumes, but written in the form of ephemeral static charges, orientations of magnetic particles, subject to the whims of the market, Moore’s Law, and your employer.
Konrad Lorenz, the author of , suggested that a scientist should begin each day by throwing out one of his pet theories in order to remain sharp.
The true mark of a good programmer lies in his/her willingness to throw away weeks or months of work in order to adopt other programmer’s superior code. Željko has inspired me in a lot of ways to become a better programmer but the one thing about him that I admire the most is his inherently humble nature. Željko is someone who, on being critiqued, puts finger to lips, furrows brow and says “hmm” when faults in our work are pointed out, while looking at the code and not the critic. He taught me to refer to code as “the code” and not “my code”, unless accepting blame.
Be eager to fix what isn’t broken
Programs are like infrastructure in that they are built to serve a specific need and will often undergo refactoring. It is important to realize as programmers that hard-coded values buried in the code are bad, that a destroyBaghdad() function is immoral and that it is a priority to eliminate code smells. Not for backslapping attaboys from your peers or the authors of methodology books. But because you will itch until it is fixed.
It’s okay to be in a destructive pursuit of perfection. The worst optimizations favor profit over beauty, and between the two it’s beauty that lasts longer. Perfection isn’t the same as obsession, but they’re damn close.
Often in open source, most coding is done in a collaborative fashion. While it’s okay to refactor code and make it more optimal, it becomes extremely important to not take the spec by it’s word but to find out who wrote it and what they were thinking.
Let the incomprehensible fascinate you and not fear you
Unless you try to do something beyond what you have already mastered, you will never grow.
I am only just beginning to understand what does, but I’ve been studying it because I have the damn persistent feeling that I could be using it somehow. I don’t know what I would use it for yet, but maybe I will someday. What I do know is that what I don’t know will cost me in useless labor. I am someone who will probably shove through a crowd at a party to get near someone who just used the word “Bayesian”. Being fascinated by the incomprehensible is something that tends to start in the childhood but it is not impossible to cultivate it in the adulthood if you can commit to exploring your horizons.
Friends are a major gateway: seek social occasions where you’ll bump into people you don’t know under circumstances where they’ll be unhurried and at ease. Don’t try to impress them, don’t compete with them, but display your ignorance willingly to see if they lean forward to correct and enlighten you. Then shut your fool trap and listen.
Computer programming has annexed all of the sciences and the feedback loop is so wide it stuns gods. From biology we took Genetic Algorithms. From climatology we took chaos theory. Biologists now use our work to fold proteins 🧬. Climatologists now use our simulations to predict armageddon ☄️. Everything informs us, and we inform everything. Either probe the unfathomable or retire on a “blub” programmer’s salary
Have knowledge? Let others light their candles in it.
Knowledge is something that grows when shared. If you’ve never taught anything before you will discover, to an embarrassing degree, just how many times you can say “um” and “er” per minute, how badly you’re prepared, and how easily you can forget that the student doesn’t know details you haven’t explained yet.
One of the tricks that worked for me like a miracle was to volunteer for an opportunity to teach a complex subject (GAN) to laymen. The first time I tried it I used a Post-It easel and a bunch of markers and tried to draw everything. I was all over the place. It was humiliating. But the audience, fortunately, was friendly.
The next month I gave it another shot, but this time I had a Mac and used Keynote to put together a presentation, which was a lot of fun in itself, but this time the lesson went overwhelmingly more smoothly. I used lots of pictures, very little text, almost no bullet points, a handful of jokes, and just relied on my memory to talk about slides I had designed to provoke my memory more than illustrate anything to the audience.
The awful first attempt informed my next attempt, and now that I’ve done it three or four more times I find I’m getting slightly better. Not only that, I now know ten times more about the subject because I studied like crazy to help temper my fear of being asked a difficult question. .
Let the instinct to experiment first rule you
The compiler and runtime can often answer a question faster than a human can. Rather than seeking out a senior programmer and ask them “will it work if I do this?”, just try it yourself and see if it works before bringing your problem to someone else.
Your actions and thoughts are essentially the result of a cocktail of brain chemicals-your brain has a small number of adrenergic receptors, so a little bit of adrenaline excites your fight-or-flight reflexes too much. Much of what makes people timid to experiment are these very brain chemicals. But consider why we grow tolerant to caffeine: the caffeine’s byproducts forces our brain to grow more adenosine receptors. In essence, if you can force your brain to grow more adrenaline receptors then the same amount of “fear juice” will trigger a lower percentage of them. Find some experience that scares the shit out of you, do it a few times, and you will lose your fear of venture on a physical level.
A programmer who "suggests wacky and unrealistic solutions" is not always a bad programmer. It can be a sign of creative thinking from someone who assumes confirmation or correction will come from somewhere else down the line.
Strive for an encyclopedic grasp of the platform
In the programming world, change comes swiftly. If change is the spice of life, in programming: change is the .
Most programmers realize the short lifespan of their tools and don’t waste much of their lives memorizing what’s doomed to be obsolete. But neither do most programmers appreciate how everything in this industry is a derivative of some earlier thing, sharing syntax and constraints that will live well past our own personal expiration dates. If you have done what Oxford used to insist on: learnt latin and mathematics then you can f**k all of that other modern nonsense, because you’ll have the tools you need to understand anything.
When in Rome, do as Romans do
I don’t think I live up to this because I like to use React to write web apps, despite being better at Angular than React. I do know Typescript and can write apps in it, but my heart belongs to Javascript. If I were to suppose an exception to this rule, it would be: “but when in the Roman accounting department, count as Romans do.” It is not always wrong to pick a language that fits the domain, even if there’s a performance or feature disadvantage from running in an interpreter or other layer. Yet great programmers will never insulate themselves from the hardware and will learn the native language anyway. These guys are as comfortable with platform diversity as they are with having multiple vegetables on the same dinner plate. While these programmers appreciate abstraction they don’t automatically appreciate generalization. If there was no advantage to be had in a new platform, then why was it ever created?
Conclusion
This is personal catharsis from an author who exhibited many of those problems himself. I didn’t want someone to get depressed when they recognized themselves, I wanted to be constructive.
Therefore if you think you’re missing any of the qualities above, don’t be offended. I haven’t picked all of these up yet myself, either. Many of them came from watching my mentors and other programmers or reading their code. It is always important to surround yourself in the company of extraordinary developers, even if you lack confidence or are overwhelmed with inferiority complex in their presence. This is what will potentially rocket your growth as a developer.