My story of how I grasped intentional learning
When you read a job description, you likely see a list of technologies that the employer would like you to know: HTML, CSS, JavaScript, Node, AWS EC2, AWS S3, DynamoDB, PostgreSQL, and on and on. Then, you’ll see some stuff in there like “must be a great communicator” and “passionate about great code” (which usually translates to “doesn’t mutter” and “will work evenings and weekends”). Then, there’s almost always one like this:
3+ years of experience
Those four words translate into something like “We want to know that you’ve spent some amount of time working on software products such that you have gained tacit knowledge from your environment.”
In case you’re unfamiliar with the idea of tacit knowledge, it’s the type of knowledge that’s not explicit; knowledge that is difficult to transfer to another person by means of writing it down or verbalizing it. Listing technologies like JavaScript and DynamoDB are ways to ensure that you have explicit knowledge about a technology.
For most job descriptions for higher than junior-level positions, you will likely read more abstract concepts in the requirements section (you may recognize some of such concepts as the subjects of our professional development courses). Maybe you would read something like “Must know object-oriented principles and design patterns” or “Understands enterprise messaging patterns”. Those appear to be appeals to explicit knowledge; however, they really aren’t. Behind those types of requests are the opinions of the interviewers, opinions they have formed during their own careers from practicing their craft. They’ve spent time learning tacit knowledge from their peers and mentors. They’ve spent time building their own tacit knowledge from the hours and hours of practice they’ve performed as programmers. When they ask you a question based on tacit knowledge, they’re asking you to provide an answer that somehow resonates with their own experience and beliefs.
I didn’t understand this when I started my career as a programmer. I thought that knowing a language or a framework or an application server was the way to career success. I threw myself into understanding the nuances of my development stack. I could answer any question about anything in the stack, from the best ways to optimize the database to handling all of the quirks of the major Web browsers. For a while, that worked for me. I got really good jobs using the new-job-as-a-promotion strategy of the software development industry. Then, I kind of hit a ceiling. My in-depth knowledge of specific application servers, frameworks, libraries, and languages wasn’t getting me anything more.
I was lucky enough to have a friend at the time that did technical recruiting. He was used to placing people from juniors through executive-level positions. I asked him about what I was doing wrong. His advice still rings true to me and is the title of this article.
Topics, not technologies, advance career growth.
I asked him what he meant by that. He went on to explain that the best software developers that he’d placed – the ones that he saw quickly move into positions of leadership – were the ones who understood two things: the underlying concepts that weave together software development, and the overarching concepts that guide the shape of software. All of the other stuff, he said, lives between those two things, are influenced by those two things, are created and destroyed by the pressures of those two things.
I started to study so-called “computer science” topics. I wrote in a daily journal for 45 minutes per day reflecting on what I had done that day and drawing connections from it to other work. I became thoughtful and contemplative about my craft. Instead of thinking about how to use the tools of computer programming, I started thinking about the merits of the tools themselves. I tried to integrate everything I learned into my daily programming practices, even if there was no direct connection. Even though I wrote object-oriented code at the time, I let the principles of functional programming help me write maintainable code. As I typed out my code, I thought about the design of the programming language and how it affected the way that I solved my problems. I read books like The Philosophical Programmer: Reflections on the Moth in the Machine to get answers to the “why” behind the “why”. I gathered with friends with whom I no longer worked to talk through the challenges at their jobs for a better perspective on what it was like to create software for different industries.
There’s nothing really Earth-shattering, here. I was learning how to think about my craft in addition to the product of the craft. But, I had never consciously considered that as an alternative. By making a choice to be aware of the actions that I took to write software, I became a far better computer programmer than I had ever been before.
Throughout my career, I’ve tried to encourage that this awareness should become a core tenet of programming culture. It is nice to see others doing this, as well, in their companies. Now, I have the opportunity to help craft mentored learning journeys for programmers at Galvanize by working with others to design the new Hack Reactor Professional Development courses. While the courses do talk about implementations of ideas, we spend a lot of time understanding the ideas. That way, you can take that new knowledge and use it to analyze, evaluate, and create software applications that delight you as a programmer.
We are currently enrolling for courses in Microservices + Orchestration and Algorithms + Data Structures.
More about Curtis Schlak, VP, Professional Development Curriculum
Curtis Schlak’s software development career spans more than two decades in software, energy, finance, legal, and education. He has worked as an individual contributor and has led teams of nearly 200 people. He has worked or consulted at Barclays Capital, Bank of America Merrill Lynch, British Petroleum, CITGO Petroleum, Ernst & Young, and Microsoft. He has led software teams at startups like KickFire and DataCert. His consulting firm leads the training and adoption of Feature-Driven Development in the US. He has created and delivered consumer and enterprise training for hundreds of people through The Iron Yard, Hack Reactor, App Academy, and Galvanize. He has a BS in Mathematics, BA in English, and MS in Computer Science. He is currently working on his PhD in Computer Science.
