Conclusion/Epilogue

After about one month into the job, I met Daniel at the TELUQ office in Montreal for the first time. He said to me (I paraphrase):

“After trimming the tests and benchmarks, you might look back and realize that you’d spend the whole summer just polishing 30 lines of code. We might also fail to beat the benchmarks we set for ourselves. That doesn’t mean failure on your part! It’s just the nature of doing research.”

Thankfully, I ended up writing more than 30 lines of code and not only did we beat benchmarks, but what turned out to be a summer gig evolved into a year-and-a-half-long adventure, with the code being used by literally millions of people.

I think it’s appropriate to dedicate the last part of this series of articles to things I couldn’t learn from books or that didn’t fit in elsewhere: namely, the importance of being social.

Technical and Social Lessons

There are benefits that lean more on the technical side. While a knowledge of assembly and at least a passing familiarity with how a compiler works are requirements, a lot of the small programming tricks I learned are simple, written nowhere easily accessible, but hard to come up with on one’s own.

During the onboarding for simdutf in particular, simple things like pointing out where the relevant files were or suggesting the most convenient tool for tasks like reading assembly didn’t take much effort on Daniel’s part but might have saved me hours on my end.

Beyond the Technical

But I believe the most valuable lessons are less technical in nature. One thing this experience taught me is that there is a lot of room for improvement in the software world. I always assumed that those who wrote common libraries were world-class experts with massive budgets. That may be true for some, but there are too many problems and not enough qualified personnel.

There’s not much incentive for maintaining software, and a surprising number of popular libraries are maintained by underpaid volunteers. With a little bit of luck and grace, an average person can certainly make their mark.

The thing is : finding such problems is not trivial. Without Daniel sharing his adventures on Twitter, this article wouldn't exist.This realization is a big part of why I decided to start writing publicly about my experiences.

The other big lesson is that it’s easier to make a beeline and learn on the job as the need arises.

Final Thoughts

I tried to maintain a fairly neutral tone befitting a technical subject, but I would like to conclude with these remarks:

Daniel was truthful when he said I would be challenged (massively), but I never felt it was so difficult that it became demoralizing. This type of programming is something that very few people get to do in their programming careers, and I feel privileged to have worked on it early on.

Anyways, I hope somebody finds value in this. This is my way of giving back to the invisible college.

So thanks, Dan. I owe you one. =)