We instinctively equate programming with writing code. Because of it, we focus primarily on code design and creation skills: mastering languages and frameworks, clean code, design patterns, TDD, architecture. But creating new code is only a fraction of what we do every day. We spend much more time navigating, searching, analyzing, reviewing, and debugging code than writing. Though these activities seem straightforward, they require as specialized skills and experience as coding. Mastering them is what separates true senior programmers from the crowd. And what makes you stand out and get noticed at a new job. In this post, I'll look at the key traits of professional software development, how they impact what you do every day, and explore what skills you need to become a complete programmer. The common misconception about programming People instinctively equate programming with writing code. And it doesn't apply only to lay people. Many experienced programmers also do have this bias. Not in a naive way, of course. We know that coding isn't just typing and that having crazy keyboard skills doesn't make you a great programmer. But even then, we focus mainly on code creation skills. Think for a moment what most books, blog posts, and talks are about. What sparks the most heated discussions in your team. What are the most common coding interview questions. Clean code. Deep, almost arcane knowledge of programming languages and frameworks. Design patterns. Architecture. Algorithms and data structures. Writing beautiful unit tests. Those are fundamental skills, yes. But they still focus mostly on code creation. I'm not saying these skills aren't important. They are critical for a senior developer. And there's so much depth there that they can be studied for years. But they cover only a small fraction of what we do every day. And focusing only on code creation skills while neglecting the rest will make you a very incomplete and ineffective programmer. To call yourself a true senior programmer, you need a well-rounded skill set. But to develop this skill set, you first need to acknowledge what actually defines how we work. What professional software development really looks like Professional software development has a few traits which have a profound impact on what we do every day as programmers: What this means in practice is that the majority of the code you'll work with was either written by someone else, modified by someone else ever since you wrote it, or written by you sufficiently long ago to forget it. It also means that most of the code you'll work with will be legacy. Software development is a team activity and most of the software is long-living. No matter how experienced you are, how rigorous your process is, and how clean and modular your codebase is, you'll still introduce errors. And a lot of them. They may not (hopefully) land on production if your Quality Assurance process is tight, but during local development, you'll have to constantly cope with bugs. Humans are prone to mistakes. The number of technologies, the surface area of all the APIs, and the pace of updates are simply too high. Even if you are a seasoned programmer, working for years with one stack, it's impossible to write code continuously without pausing to look stuff up. Modern software stacks are too complex to learn everything by heart. Unless it's your personal hobby project, you'll constantly be struggling to balance cutting corners (to generate business value faster) and keeping the codebase healthy (to not cannibalize your long-term performance). Commercial software is built under tight time and resource constraints. In a new job, the first impression you make sets up how you'll be seen for a long time (if not forever). And it depends on how fast and self-sufficiently you can find your way around the new codebase. If you are able to start meaningfully contributing right off the bat without much guidance, you'll be immediately perceived as a strong senior. Understanding a new codebase quickly is a critical career skill. When you look at the above five traits, you can clearly see that your most important skills are the ones related to reading, analyzing, and reviewing code, navigating unknown code bases, debugging, finding information, and being able to walk a thin line between under- and over-engineering. But let's explore these skills more in-depth. What a well-rounded developer be skilled at MUST 1. Exploring and understanding new codebases (a.k.a. code archaeology) "Reading" the overall layout of the codebase (directory structure, architectural layers, main business domains) and building a mental model of the flow of data and logic through the application. Knowing how to efficiently map, diagram, and visualize the code, data, and flow. Mapping the lay of the land. Using the full power of your IDE to efficiently find your way around the codebase: navigate up and down component or inheritance hierarchy; navigate up and down function or method call chain; look up the definition of the function, class, component, or constant; look up the dependencies of a class, function, or component; find all the occurrences of a class, function, or variable; quickly switch between code and related tests; quickly find component, class, function, or constant by name. BONUS: knowing how to structure the codebase and name stuff to make it easily navigable. Navigating and searching the code. Effectively navigating through the commit and pull request history to understand the context and the decisions behind the current state of the code. Using tools like git blame to identify where to find the necessary information. BONUS: writing good commit and pull request descriptions that will make exploring Git history easier for other developers. Exploring the Git history. Using manual and automated end-to-end exploratory tests to see how the application works (which is often hard to understand from the source code alone). Stubbing API requests with fake data to get the application into the desired state to explore all the edge cases. Peeking into the application's inner workings by the means of characterization unit tests, debuggers, and inspection tools (web browser dev tools, interactive shells, request capturing tools like Postman, etc.). Exploratory testing and code inspection. 2. Debugging Top-down vs bottom-up debugging. Divide and conquer approach. Tradeoffs of using different approaches to pinpoint the problem (for example, debugger vs "print" statement). What input data to use to most efficiently replicate the bug, and at what level to insert this data: UI, web requests, or somewhere inside the code. Understanding the overall debugging principles and approaches. Deep knowledge of the whole range of debugging tools and approaches: integrated and external debuggers, "print" statement and equivalents like browser's console.log, in-code assertions, using unit tests to debug the code, using git bisect. Deep knowledge of the tools to inspect and interact with the running application: browser dev tools, your framework dev tools (for example, React or Redux dev tools), interactive shells, tools like Postman to capture and inspect API requests, and so on. Debugging and inspecting the code. Knowing the most common error messages of your language and framework. Understanding how they are formatted and what additional info they contain. Tracing error messages to the actual place in the source code (knowing how to interpret stack traces, use tools like source maps, and so on). Looking up less common error messages. Interpreting and following error messages. Using server and cloud platforms' logs to detect and triage errors. Using log management and visualization tools like Grafana, Kibana, or Splunk to pinpoint errors easier. Utilizing monitoring tools like Sentry, AppSignal, or NewRelic. Monitoring and logging. 3. Reviewing code Discerning what the original code does and what the change was intended to do. Building a mental map of what exactly was changed and how it impacts the workings of the app. Using tools like your IDE, Git command line, and Git UIs to effectively navigate code and diffs to understand the changes and their context. Understanding the context. Which changes are critical and which ones are cosmetic? Which will impact code security, architecture, readability, and long-term maintainability, and which ones are more a matter of personal taste (and should be left to the pull request author). What requires human analysis and what can be left for linters and code formatters. Understanding what to focus on. Efficiently navigating through the changes and the discussion (other reviewers' suggestions, pull request author's replies). Understanding how to most effectively review a PR depending on its size, complexity, and quality of individual commits (if it should be reviewed commit-by-commit or all the changes altogether, etc.). Utilizing more advanced features of your code hosting platform like GitHub's multi-line comments or suggested changes. Effectively re-reviewing fixes applied by the code author to your (and other reviewers') suggestions. Efficiently reviewing (and re-reviewing) the code. Writing constructive, non-aggressive, easy-to-understand suggestions, that are helpful to the pull request author and the rest of the team. Clearly distinguishing the "must-fix" suggestions from the "for-the-purpose-of-the-discussion" ones. Knowing when to press and when to step back - and when and how to gracefully end the discussion. Collaborating with the author and other reviewers. Writing great pull requests and commit descriptions. Knowing how to make a pull request easier to review: when to do one bigger commit vs multiple smaller ones, what should be the pull request boundaries, and so on. BONUS: Making your pull requests easy to review. 4. Finding information Having a good understanding of the documentation for your stack of choice (how is it organized and how to most efficiently find what you need). Getting good at looking up stuff on the internet (Google, StackOverflow, etc.). Using the full power of your IDE: inline documentation, parameter hints, go to definition, and so on. 5. Working with legacy code Understanding the tradeoffs between under- and over-engineering: which debt is worth paying off right now, later, and never; which should be paid off gradually and which as a one-off, bigger project. Setting boundaries of what should be paid off in the current batch. Understanding how to work during the transition period when paying tech debt gradually. Understanding technical debt. Identifying natural boundaries ("seams") to isolate areas of legacy code for controlled, limited changes. Covering the isolated area with the temporary characterization tests at the seams to provide a safety net against the regression during refactoring. Converting characterization tests to the proper focused unit tests after refactoring. Isolating legacy code and covering it with a safety net. Knowledge of refactoring patterns and techniques (especially extracting and modularizing the code to contain the scope of the refactoring). Using your IDE, codemods, linter auto-fix, and similar automated refactoring tools. Restructuring and refactoring the old code. Bottom line If you want to advance your career, you have to be a complete package. Code archaeology, debugging, reviewing code, finding information, and working with legacy code, are absolutely critical skills to have (especially as a complete bundle, as they interact and reinforce each other). Not only you'll spend more time on these activities than on the actual code creation - but they will also enhance your creation skills. And they are what screams "true senior" to your colleagues and managers. Also published . here

How to Become a 10x Dev: An Essential Guide

20 Instant Tips to Rapidly Level Up as a Developer — Get the Free PDF

Beyond Coding: The 5 Must-Have Skills to Have If You Want to Become a Senior Programmer

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

Are You a Code Monkey or a Real Professional Developer?

10 VSCode Extensions To Make Your Life Easier

10 Ways Stand Out as a Java Developer and Land that Dream Job

10 Tips For Junior Developers To Succeed in Code

10 Things Every Beginner Should Know When Learning Javascript And React

10 Reasons Why Front End Development Is a Great Career Choice

Are You a Code Monkey or a Real Professional Developer?

10 VSCode Extensions To Make Your Life Easier

10 Ways Stand Out as a Java Developer and Land that Dream Job

10 Tips For Junior Developers To Succeed in Code

10 Things Every Beginner Should Know When Learning Javascript And React

10 Reasons Why Front End Development Is a Great Career Choice

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps