Learn | Build | Teach
“So, what do you do?”
Increasingly, I am asked, “What is your job exactly?” Factually, I am an independent software architect and developer. Practically, I have a dream job: I can work anywhere and anytime on projects of my choosing. After a bit of example-based explanation, the follow-on question is generally something like this: “How can I do that?”
I am that rare bird — a non-Silicon Valley based senior technical woman (yes, we do exist). Although tempting, I did NOT leave tech (yet anyway), despite the usual hellish series of unfortunate incidents throughout my 15+ year career here. Rather I’ve found a way to thrive in our tech world that works for me. Given the subtext, it seems only logical to attempt to share what I’ve learned.
The most succinct way to describe the cycle of my work is via three simple verbs: learn, build and teach. But, what does this mean when applied to my domains?
This trait may have killed the cat, but it’s a key to my work (and life). The combination of unusual (possibly unnatural?) confidence (i.e. “I will be able to understand topic x, y or z…”), tenacity and the lack of distractions (no TV) results in life-long learning. Associated is that I am a perpetual beginner in a large number of domains, so my lack of assumptions often allows for faster learning. I experiment with new technologies, programming languages, etc…constantly.
I am frequently asked to mentor people, it’s not uncommon to see several inquiries come my way each week. So, how do I select a person to work with? As an engineer, I optimized for answering the question (“will you mentor me?”), writing this post to address the question.
It’s been interesting to see the response to this approach — some candidates take it as a personal challenge, others aim for a MVP (minimum viable persona), while still others try to negotiate (“is this enough?”).
This idea of project-based (or JIT Mentoring) seems strangely uncommon. Sadly a fair number of potential mentees seem confused when I ask them to show me running code from a project that they contributed to rather than the standard questioning about their CV.
Mentoring flows directly into the next topic. The learning manifests in the making of working software.
The passion which drives the energy to turn ideas into working software is why we do this, right?
The challenge always is to build a MVP for my users. What seems to get missed is who is the actual user? Hint: It can be me, but is more often NOT ME. I have literally made thousands of dollars helping companies regain focus around this key question.
As I often pair program with university students, I am now (finally) understanding what it is we do and don’t teach our CS graduates. My experience learning to code was so different from theirs. 15 years ago, I began, self-taught via the tried-and-true copy-and-paste developer method (“it works!”).
Just Code It
Eventually, I added key software pattern-based books to my knowledge base. To get a peek into my reading habits, see my post on that topic. Unsurprisingly, I embraced public cloud technologies as they emerged. Lately I am working with cloud-based bioinformatics pipelines which sometimes include machine learning.
In contrast, I find it sad and possibly tragic, that our CS university courses seem to be stuck in the bowels of C or Lisp-type languages.
I finally understand why I’ve been told so many times “you are not technical”. This academic definition is laughably narrow. I wonder when we’ll evolve?
My company gets to value for my customers fast because I understand the true cost of code (tradeoffs around using no code, reusing code or writing code) better than most formally educated developers. This practicality manifests in iteration over these questions:
- Does it work?
- Does it matter?
- Can they use it?
- Are they using it?
A key aspect of this process is effective communication. My formal education is around linguistics. Focus on domain-specific communication, with close attention to taxonomies has been a cornerstone of my work. Do I understand what my customer wants/needs? Do they understand what I plan to build for them? Lately, I’ve been adding visual communication (diagrams, drawings, sketches) to my repertoire.
When my team’s code works for my customers, we are happy and satisfied — however, our work is not yet done. Then we move to the next phase of our work cycle: teach. In many ways this is the most interesting part of the cycle.
Considering technical teaching, several questions arise…
What is teaching these days anyway? With everything online all the time, do we even benefit from interacting with human teachers? Gone are the days of the 5-day eight-hour technical courses that I taught — what replaces them?
The answers to this question always illuminate:
“How do you learn?”
Listening closely to individual answers inevitably re-starts the work cycle for me. Something in this inquiry must be right. I am astounded to see that over 4 million students have watched part or all of my online courses.
Just Share It
“Put your code on GitHub!” is becoming a mantra. It’s fascinating to me to see what type of material that people do put on GitHub — code, lists, guides, even books.
In this collaborative technical learning world, I am looking around for ‘the next GitHub’. Given the rise of machine learning, my immediate focus is on Kaggle. Interesting that Microsoft owns GitHub, Google owns Kaggle. Musing on whether Amazon, or possibly Alibaba will enter this space soon…
Here is an example of a passion-driven project built by a developer I’ve had the pleasure to work with lately.
What is the future of technical work? I’ve been thinking quite a bit about this question lately. I took the time to write this short piece in the hopes of opening a conversation with a wider audience on this topic. Share your thoughts in the comment section.