This article explores some of the different paths and endless breadth and depth of a software development career or a computer science degree. Its target audience is mostly students and early-in-career folks.
This is what we call a graph in computer science.
A graph is a collection of nodes and edges. We often represent the nodes with circles and edges with lines. Edges represent a relationship, connection, or association between nodes.
Graphs are used to represent a lot of things…
Like the London Subway:
Or social networks of Game of Thrones characters:
But let’s use nodes to represent careers and knowledge.
As a high schooler deciding what to do with your life, your graph representation of different career paths might be quite shallow, and these vague representations may not give you a lot of confidence about which life path to go on, which career or major to pursue.
Perhaps these vague representations lead you to a life down this path of being a “programmer” — whatever that means.
At first, this Programming node is a huge abstract bubble, and you may only know a few details about what’s inside. You know that there’s a lot to know about programming, but you don’t know concretely what that entails.
You may do some googling and write your first program in Java and now you have some idea of what programming is:
Perhaps you major in computer science and start taking some intro classes and start building out more nodes…
(Let’s swap to bullets instead of visual graphs — they still represent the same concept!)
Computer Science
- Programming
- Languages
- Java, HTML, C
- Control flows
- If-then, else
- Switch
- For, while loops
- Errors
- NullPointers
- Run time errors vs. compile time errors
- Tooling
- IDEs
- Compilers
Over time, your graph of knowledge of CS grows.
And you start to assess your knowledge about these nodes.
- Red = I know a little bit about this and don’t feel confident in this at all.
- Yellow = I know a decent amount about this, but don’t feel super confident about it.
- Green = I know a lot about this and feel fairly confident about it!
Your knowledge graph in the middle of your degree may look like this:
Computer Science
- Programming
- Languages
- Java, HTML, CSS, JavaScript, C, Assembly
- Control flows
- System design
- Databases
- SQL, NoSQL
- Data Structures & Algorithms
- Trees, Lists, HashMaps, Graphs
- Traversal, Sorting
- Software Development
- Version Control
- Git, SVN
You wrap up your degree and start job searching. You might start to put “Advanced” in JavaScript on your resume like your peers do, confident in your knowledge after a few projects.
In any job, you can construct an implicit mapping between that job and the relevant nodes of knowledge. There are many jobs and so many options…
Web Developer → front-end, HTML, CSS, React?, WordPress?, …
Product Engineer → product intuition, design, software development, …
Infrastructure Engineer → infra trade-offs, system design, databases, scaling, …
QA Developer → automated testing, edge cases, Selenium, …
Security Architect → security vulnerabilities, SQL injection, crawling, …
Professor → research, teaching, paper writing, mentoring, grant applications, …
You start your first software job as a Web Developer and realize the delta between your knowledge and the knowledge required for the job. You start to build these knowledge nodes, and learn about new nodes you’d never really paid attention to, including soft skills that aren’t necessarily related to computer science.
Web Development
- Programming
- HTML
- CSS
- CSS Grid
- Flexbox
- JS
- React
- Typescript
- Jest
- Debugging
- Profiling
- …
- Software Engineering
- Software Planning
- Software Testing
- Writing Clean Code
- Refactoring
- …
- Communication
- Technical Docs
- Teamwork
- …
You realize that your knowledge graph of JavaScript is under-explored, as you start to uncover more and more nodes nested within other nodes (e.g. React → Functional Components → Hooks → useEffect → Dependency arrays) and realize how much more there is to know. You may start to think using terms like “Advanced” or “Proficient” to describe your expertise is often imprecise and not that useful anyways, and is mostly a marketing gimmick for resumes.
You realize there’s a difference between knowledge and awareness, and recognize there’s many nodes that you are aware that you don’t know anything about, and there are many nodes that you don’t even know exist.
ㅤ | knowledge: yes | knowledge: no |
awareness: yes | Things you know that you know
[You may have practiced lots of HTML & CSS.] | Things you know that you don’t know
[You may have no experience Leading a Software Project.] |
awareness: no | Things you don’t know that you know, tacit or hidden knowledge.
[You might have some Product Intuition from just being a user of products!] | Things you don’t know that you don’t know
[You may not know Webpack Bundle Optimization is a thing that web devs do or what it is!] |
You notice some of your colleagues may have breadth and depth in different graphs. You recognize which concepts your colleagues have developed far better than you, and lean on asking them for help about to help you develop these skills.
Bob
- Very good at: Debugging, TypeScript, Software Testing
Xiao
- Very good at: Product Thinking, Design, Technical Communication
You find out what nodes you are better at, and which nodes you find more interesting. You start to build strong expertise in some nodes, so behaviors become automatic and it’s easy to get into flow states.
Before, you had to look up documentation about these topics every time. Now, it’s automatic — your expertise gives you the answers immediately for things that used to be unknown. Similar to how you’ve probably become an expert at the Walking and Talking nodes, now day-to-day Programming becomes automatic.
You realize more senior engineers are generally those who’ve built lots of expertise across many or specific nodes, many that you don’t even conceptualize.
Some engineers are especially good at leadership and direction: telling people what to build and how to build it. Their specialized nodes might look like this:
Team Lead
- Direction
- Product Intuition
- Data Reasoning
- Roadmap Planning
- Trade-off Evaluation
- Software Engineering
- Tech Debt
- Project Management
- Communication
- Leadership
- Culture Building
- Relationship Building
The above knowledge graph models skills from more of a Team Lead archetype, but there are many other archetypes too, and you decide on further areas to specialize in.
Infrastructure Engineer
- Systems Design
- Databases
- Networking
- API Design
- Availability
- Caching
- Scaling
- Load Balancing
- Build Tools
- Automated Testing
- Release Processes
Product Engineer
- Design
- Product & Design Intuition
- UI/UX
- Product Management
- Software Engineering
- Mobile Responsiveness
- Performance & Reliability
- Data Science
- Experimental Methodology
- Metric Reasoning
Sometimes, you explore this graph via breadth (horizontally) first — and you’re implicitly exploring interdisciplinary skills like Product Design or Data Science. Other times, you explore this graph via depth (vertically) first — maybe you’re learning complex Systems Design or Machine Learning models.
Over time, you start to see connections between different role functions and cross-functional concepts. After all, many nodes play a role in the day-to-day production and impact of software. A product may fail if relevant nodes (e.g. Performance, Availability, Design, Content) are not executed successfully. Perhaps the app is too slow and unreliable due to poor System Design and Scaling, and this leads to poor user reception. Or internally, there’s issues hidden within the company culture and processes (e.g. Product Development, Experimentation Methodology) or codebase (e.g. Tech Debt, Readability).
To build a successful product, a company needs to hire folks with diverse expertise, breadth & depth across many knowledge nodes. UX Research, Design, Product, Data Science, Operations, Marketing, Sales, etc., all cover different gaps.
At some point, you realize that the graph of knowledge has endless breadth and depth, and it’s fruitless to try to master it all, but maybe it’s fun to explore and learn!
To me, the above exercise illustrates the excitement of a career like computer science. You have significant optionality in your knowledge graph and career choices and an endless graph to explore. As you explore further nodes, you unlock more opportunities. If you’re intentional about how you navigate your career, you can carve out a path that’s most relevant to your interests and skills! Perhaps that path involves a pursuit of a less common combination of nodes, like Product Development + Music Production, or Game Design + Physics. Personally, I mostly fit the Product Engineer archetype described above.
Being a lifelong learner, and approaching each new node with curiosity helps you build expertise more easily. The democratization of computer science knowledge makes the field often appear either intimidating (”oh god, there’s so much content and stuff to learn. I feel so stupid.”) or approachable (”wow, look at all this free content and stuff to learn. I’m excited to learn.”), depending on your mindset. I hope if you’re early in this field, you adopt the latter mindset — and continue to explore and develop your personal knowledge graph.
I hope this article helped you imagine some of the possibilities of jobs, careers, or topics in computer science or other fields! Thinking about the concept of knowledge graphs has helped me explore this graph better over the years. 🙂
