Google can’t help if you don’t know the words

Dear new developer,

If you don’t know what you don’t know, it’s hard to learn it. There are so many resources for learning, but if you can’t find them, you’re going to have a hard time taking advantage of them. Sometimes you need to spend time learning what you need to spend time learning. That is to say, you need to learn the broad outlines of a segment of knowledge before diving in.

This time spent prepping your understanding of swathes of a domain will be useful because it will accelerate your learning in the future, letting you grasp concepts and find resources more quickly.

Let’s say I got hired by a company to write a compiler, which would be a new area of software for me. Here are some things I would do if I were trying to learn this new domain.

Glossaries

I’d look for some glossaries about compiler design. Here’s the first result from Google when I search for “compiler design glossary”. Reading this would help me understand the meaning of words I might know from other contexts, such as “array” and “value”, but would encounter when reading more about compilers. Knowing the jargon of a domain is extremely helpful when you are searching to see whose shoulders you can stand on, as well as communicating with your team members.

Pattern match

Matching patterns is something I’ve done many times. I take something I understand fairly well and see whether it matches up to a new concept, domain, or technology. In this case, I might read about a compiler for parsing regular expressions. I understand how regular expressions work as an end user, so it won’t be as much of a leap as if I were to try to study a compiler for C. Here’s a search result that I might work through.

Books and videos

If I have time, books and videos can be very helpful at getting a wider view of a domain. Sometimes it’s hard to know which book or video to invest your time in. By looking at reviews on sites like Amazon and Youtube, you can leverage the wisdom of many people. I’d probably start with one of the top books here, were I to need to jump into compiler design. When I do this, I don’t feel the need to read the entire book or watch every minute of the video.

Twitter

You can use Twitter to “get smart quick” too. Basically, you can follow folks who are highly regarded by other folks in the same domain. Wesley did a great job of explaining it, so I’ll just point you to this video. You want to watch between 15:53 and 20:00, where he talks about getting smart around “quantum computing”. Once you know who to follow on Twitter because they are respected by the community, you can start figuring out the words and concepts they use.

Follow some rabbits down holes

I’m a big fan of timeboxing investigations, and I always tell team members I am mentoring that they shouldn’t spin their wheels too long; far better to ask a team member. But sometimes, when you are exploring a new domain, you should spin your wheels a bit. Follow some paths and see if they end up where you thought, or if they were dead ends. In this stage of knowledge gathering, there are no wasted efforts. Any time you “waste” investigating or following some threads of discussion will compound and save you time in the future. Do take some notes, either mental or written (I like a blog post, as I did here). Don’t feel like you need to come up with any firm answers. And feel free to timebox it, just make the time limit higher than it would be if you were actually trying to solve a problem.

Take a class

One time I was working on a project at a real estate brokerage where we wanted to do statistical analysis on property data. I didn’t have much background on it, so I ended up taking a free class from Coursera. This is a substantial time investment, but for foundational knowledge that you can leverage across other parts of your life (I’m a lot more suspicious of stats I see now), the additional time can be worth it.

Pick the technique that resonates with you next time you have to get smart quickly about a topic or technology. Spend some time investing in your upfront knowledge and I promise it will pay dividends as you dig deeper.

Sincerely,

Dan

It is never too late to start learning how to code

This is a guest post from Jenna Quindica. Enjoy.

Dear New Developer,

I didn’t learn how to program until I was 18; in fact, I didn’t know about computer science the concept until I was 18. It is never too late to start learning how to code.

In the beginning I struggled the most with navigating acronyms, words, and phrases I’d never heard of. I vaguely knew what a server was, but I didn’t know what a command line was, let alone what you do with one. File extensions that weren’t Microsoft Word, Excel, or PowerPoint confused me. The closest I got to computer science as a kid was clearing my Chrome browser history. My Neopets password was five alpha characters, and I was devastated when my account got hacked.

I didn’t start to enjoy programming until I knew how my piece fit into the rest of the picture. Find a friend who can teach you the vocabulary so that you can better understand the ecosystem.

Warmly,
Jenna

Jenna Quindica is a software engineer at First Round, a seed-stage venture capital firm. She dropped out of her computer science major at Cornell University to work at four early-stage startups. She lives in the San Francisco Bay Area.

Learn To Explain Concepts To Non-Technical Users

Dear new developer,

I taught technology courses for about a year and a half, but have been teaching folks almost my entire career in one way or another (everyone has something to teach), primarily through my blog.

One thing I’ve learned over time is that if you can’t explain a technology choice in a way that a non technical user can understand, you don’t understand it. It can be very easy to get caught up in jargon. Jargon in and of itself is not a bad thing. It’s a shortcut. If I say RDBMS to another developer, they know that this is a third party piece of software which provides safe, durable, transactional data storage. (See how jargon builds on itself? “transactional” is jargon as well.) But just like if you take one shortcut after another you’re likely to get lost, too much jargon can blind you. (Or at least put you in a fog.) AWS In Plain English is a great example of how the names of AWS services are confusing and could be improved.

So, learn how to think about technical topics in a non technical way. Then you can bundle it up in jargon later, when you have a clear understanding of it.

One great way to do this is to learn to explain things to non technical users. You can do this via writing (a blog), speaking (at a meetup), or just talking to someone in your life (parents, friends) about what you do for a living. Lots of people are mystified by software and are happy to learn more about it. You can start as small as you like (“what’s a directory?”). Go slowly and try to explain exactly what you do. An example for a site I worked on is “we pull information from a couple of different sources and publish it.” (I confess, I had to write slowly and rewrite that sentence because I used jargon.)

Other benefit of learning to do this is that as you continue your career as a developer, you’ll typically spend more and more time around non technical people. These folks make decisions that affect business and software, but they won’t always understand the latter. If you are well versed in explaining technical concepts, you’ll be valued and be able to be at the table when decisions are made.

So, if you can explain something non technical, you gain:

  • clarity for yourself
  • the ability to teach others
  • influence in your organization

What’s not to like?

Sincerely,

Dan