DEV Community: Wojciech Zawistowski

ChatGPT as a Programming Mentor: A Test Drive

Wojciech Zawistowski — Tue, 13 Feb 2024 14:30:00 +0000

Nothing will accelerate your growth quite like an experienced mentor. However, finding one can be challenging, and their availability is often limited.

On the other hand, AI agents like ChatGPT are available 24/7 and seem to be quite knowledgeable as well. Could such an agent serve as a reasonable substitute for a real, human mentor?

What I'm particularly interested in is more "meta" advice - the small tips and tricks, acquired only through extensive experience, that will help you grow and mature as a developer - not merely generating or explaining code.

For example, something like my 20 Instant Tips to Rapidly Level Up as a Developer.

As someone with over 20 years of experience, who has mentored several junior developers, I'm curious how sound, comprehensive, and actionable for a beginner such ChatGPT's advice would be.

Let's take it for a quick test drive!

TL;DR.

If you're curious about the quality of ChatGPT's advice but don't want to go through the entire discussion and my detailed step-by-step commentary, feel free to jump straight to the last section.

A short legend.

💬 My prompts.

🤖 ChatGPT answers.

🤔 My thoughts/comments.

The setup.

💬 Act as a seasoned, professional software developer with over 10 years of experience. Imagine that you are mentoring a younger, junior colleague, with no more than 2-3 years of experience. I'll be asking you different questions related to programming and software development career. I'll be asking them as this younger dev. Answer them in a way that will be most helpful for me to become a better developer and grow professionally.

🤖 Sure, I'm here to help you! Feel free to ask any questions you have about programming or your software development career, and I'll do my best to guide you based on my experience.

🤔 So far, so good. Let's get started!

The "Million $" question: 10 lifehacks to become a better developer.

💬 Please share 10 lifehacks that are quick and easy to implement and will immediately help me become a better developer.

🤖 Of course! Here are 10 lifehacks that you can quickly implement to improve your skills as a developer:

Use keyboard shortcuts: Learn and use IDE or editor-specific keyboard shortcuts to navigate and manipulate code faster. It will save you time and increase your productivity.
Follow the Pomodoro Technique: Break your work into small, manageable intervals (usually 25 minutes) followed by a short break. This technique can help you stay focused and maintain a consistent work rhythm.
Master version control: Get comfortable with Git or another version control system. This will help you track changes in your code, collaborate with others, and revert to previous versions when needed.
Automate repetitive tasks: Use scripts or tools to automate mundane tasks like code formatting, file renaming, or project scaffolding. This will save you time and reduce the chances of human error.
Read and write clean code: Adopt a clean coding style that's easy to read and understand. Follow best practices for naming conventions, indentation, and code structure. This will make your code more maintainable and reduce the time spent on debugging.
Comment your code: Write meaningful comments to explain the purpose and functionality of your code. This will make it easier for others to understand your code and for you to recall your thought process when revisiting the code later.
Seek code reviews: Ask your colleagues or mentors to review your code regularly. This will help you identify areas for improvement and learn from their expertise.
Stay curious: Constantly explore new languages, frameworks, and tools. This will help you stay up-to-date with the latest industry trends and broaden your skillset.
Break problems into smaller pieces: When faced with a complex problem, break it down into smaller, more manageable tasks. This will help you maintain focus and prevent you from getting overwhelmed.
Take care of yourself: Prioritize your physical and mental well-being. Exercise regularly, get enough sleep, and take breaks when needed. A healthy mind and body will help you be more productive and focused in your work.

Remember, becoming a better developer is an ongoing process, and it takes time and dedication. But by implementing these lifehacks, you can accelerate your growth and continuously improve your skills.

🤔 The list seems mostly solid, though somewhat random and not particularly groundbreaking. However, I did ask ChatGPT for beginner advice, so the relatively obvious answers are understandable.

Some of these tips don't seem so quick and easy to implement (which was part of my prompt). A few others are a bit vague and require further explanation – but since ChatGPT is designed to be used iteratively, digging deeper and deeper with follow-up questions, I guess that's fine. There are a couple of points I don't fully agree with, but I view them more as a matter of opinion rather than being incorrect. Overall, not bad!

Let's dive a bit deeper into each suggestion:

Use keyboard shortcuts: Solid advice. Fast and easy to implement, and it will undoubtedly boost your productivity. One thing that surprises me is why only simple keyboard shortcuts? Utilizing more advanced features like code intelligence, snippets, autoformatters, code generators, and AI assistants like GitHub Copilot (or ChatGPT itself, duh) would be equally easy to start using and provide a much bigger boost.

Follow the Pomodoro Technique: Good advice. You should definitely try it. If you have never heard of Pomodoro before, you may have to google it or ask ChatGPT a follow-up question, but it's otherwise pretty straightforward and self-explanatory.

Master version control: Good advice, but definitely not a lifehack. Even the word "master" clearly shows that it's not a quick and easy fix. I'd also argue that version control is an integral part of your primary tech stack, similar to your programming language, main framework, or database, rather than a "hack" to improve your productivity. But otherwise, the advice is correct.

Automate repetitive tasks: Solid advice, but again, it needs further exploration. It's too high-level to implement immediately.

Read and write clean code: Reading a lot of clean code (or code in general) is fantastic advice – and easy to implement. The only tricky part is how to know, as a beginner, which code is clean and where to find it. This again requires deeper inquiry. Writing clean code, however, is a completely different matter. It's part of a lifelong mastery of your craft, and entire books are written on the topic. You should absolutely study it, but just like with mastering version control, it's very far from a lifehack.

Comment your code: This is the first tip that I find debatable (though, as I said earlier, not because it's obviously wrong but because of personal preferences). There are two stances regarding comments: commenting heavily vs making code so self-explanatory that you don't need comments (unless you need to explain the business purpose behind your code). I'm strongly in the second camp, so ChatGPT's very authoritative "write comments" doesn't resonate with me. On the other hand, it also says to write meaningful comments and to explain the purpose of your code, which I very much agree with. But it also says to explain the functionality of your code, which I consider a bad practice and a waste of time. So, I have mixed feelings on this one.

Seek code reviews: This advice is as solid and easily applicable as it can get. You should absolutely seek code reviews as much as possible, especially as a beginner.

Stay curious: This is the second piece of advice that I find somewhat arguable. Exploring new languages, frameworks, and tools is overall good advice (though I'd argue about "constantly" - it smells like buzzword-driven development), but it may not be the best strategy for a beginner with only a year or two of experience. As a junior, you should focus more on building a solid foundation of best practices and principles and learning them in-depth, which is easier when you focus on mastering a single stack for a while. But, frankly, I'm nitpicking here, and I wouldn't call this piece of advice wrong.

Break problems into smaller pieces: Solid advice, but again, it's too high-level. Breaking down problems effectively is not trivial. To actually implement this in practice, some further drill-down would be required.

Take care of yourself: Very good and applicable advice. It's actually nice that ChatGPT included advice like this, which isn't directly related to hard tech skills.

Alright, we went through all the tips. Not bad, not bad at all. However, not all of them are immediately applicable. Let's drill down into a few to see how close we can get to the core

Keyboard shortcuts - digging deeper.

💬 Let's dig deeper into the "Use keyboard shortcuts" tip. Can you elaborate a bit if I should learn all possible shortcuts, or if there are any particular categories of shortcuts I should focus on?

🤖 Certainly! When it comes to keyboard shortcuts, the key is to focus on learning the ones that will have the most significant impact on your productivity and efficiency. You don't need to learn every single shortcut available, but rather prioritize the ones that will save you the most time and help streamline your workflow.

Here are some categories of keyboard shortcuts to focus on:

Navigation shortcuts: These shortcuts help you quickly navigate through your code, jump between files or tabs, and find specific symbols or instances of a keyword. Examples include "Go to Definition," "Go to Line," and "Find All References."
Editing shortcuts: These shortcuts assist you in manipulating code by cutting, copying, pasting, and formatting text. Examples include "Duplicate Line," "Move Line Up/Down," and "Toggle Comment."
Refactoring shortcuts: Refactoring is an essential part of maintaining clean and efficient code. Shortcuts that help you refactor code quickly can save you a lot of time. Examples include "Rename Symbol," "Extract Method," and "Change Signature."
Debugging shortcuts: Debugging is a crucial part of the development process. Shortcuts that help you manage breakpoints, step through code, and inspect variables can streamline your debugging sessions. Examples include "Toggle Breakpoint," "Step Over," and "Step Into."
IDE-specific shortcuts: Your IDE or code editor might have unique features or tools that can be accessed through shortcuts. Familiarize yourself with these shortcuts to make the most of your chosen development environment.

Keep in mind that the actual key combinations for these shortcuts may vary depending on the IDE or code editor you're using. Refer to your editor's documentation or settings to discover and customize these shortcuts to your preference.

When learning shortcuts, start by focusing on a few at a time. As you become more comfortable with them, gradually incorporate more shortcuts into your daily workflow. Over time, using these shortcuts will become second nature, and you'll notice a significant improvement in your productivity and efficiency.

🤔 That's a great categorization! I'm impressed. I also like the concrete examples for each category. This level of advice is already actionable – you can easily look for "Navigation shortcuts" or "Go to Definition" in your IDE's documentation. Moreover, the categories are well-chosen. They are truly the ones that will give your productivity a significant boost.

There's just one thing I'm still missing: the more substantial productivity boosters, like auto-completion or code snippets. I don't want to ask about them explicitly, as I'm pretending not to know they exist. However, let's bend the rules a bit:

💬 You said that I should learn shortcuts "to navigate and manipulate code faster", that "the key is to focus on learning the ones that will have the most significant impact on your productivity and efficiency", and to "prioritize the ones that will save you the most time and help streamline your workflow". Are there any other tools or IDE features, apart from keyboard shortcuts, that could help me achieve these goals?

🤖 Absolutely! Apart from keyboard shortcuts, there are many other tools and IDE features that can help boost your productivity and efficiency. Here are some of them:

Code snippets and templates: Many IDEs and editors support code snippets or templates that can generate commonly used code structures or boilerplate code with just a few keystrokes. These can save you time and help maintain consistency in your code.
Auto-completion and IntelliSense: Modern IDEs and code editors often provide intelligent code completion, which suggests completions for variables, methods, or keywords based on the current context. This can speed up your coding process and reduce the chance of typos or syntax errors.
Integrated debugging: Debugging tools integrated into your IDE allow you to set breakpoints, step through your code, and inspect variables without leaving your development environment. This seamless debugging experience can help you find and fix issues more efficiently.
Version control integration: Many IDEs offer built-in support for version control systems like Git. This integration can simplify common version control tasks, like committing changes, creating branches, and resolving conflicts, all within your IDE.
Code analysis and linting: Real-time code analysis and linting tools can help you identify potential issues, such as syntax errors, unused variables, or code style violations, as you write your code. This can save you time on debugging and ensure your code adheres to best practices.
Refactoring tools: Some IDEs have built-in tools that can automatically refactor your code, such as extracting methods, renaming variables, or changing method signatures. These tools can help you maintain clean and efficient code without manual effort.
Task and project management: Many IDEs and editors have features that allow you to manage tasks, create to-do lists, and track progress within your projects. This can help you stay organized and prioritize your work more effectively.
Customization: Most IDEs and editors offer a high level of customization, including themes, plugins, and configuration options. Tailoring your development environment to your preferences can help you work more comfortably and efficiently.
Integrated terminal: Having an integrated terminal within your IDE can save you time by allowing you to run commands, build your project, or interact with version control without switching between windows.

These tools and features can significantly improve your coding experience, making you more efficient and productive. Take the time to explore your IDE or code editor's capabilities, and don't hesitate to try new tools or plugins that can enhance your workflow.

🤔 Now we're talking! The list is not entirely exhaustive (for example, it misses code auto-formatters, and it surprisingly still misses AI assistants – isn't ChatGPT aware of its own capabilities? Or is it just too humble?) but it's solid and broad enough to be genuinely useful for a beginner dev. Plus, now that you're aware of the richness of modern developer tools, you can gradually dig even deeper.

Version control - getting down to more actionable, bite-sized tips.

💬 One of the tips you gave me was "Master version control". But is it really a quick and easy lifehack? It seems to me like a long process to fully master version control. Are there any version control-related quick tips, that could be implemented right away?

🤖 You're correct that mastering version control can be a longer process, but there are some quick tips and best practices you can implement right away to make more effective use of version control systems like Git. Here are a few:

Commit frequently and in small units: Make small, focused commits that contain a single, logical change. This makes it easier to understand the history of the project, locate issues, and revert changes if necessary.
Write descriptive commit messages: When you commit changes, write clear and concise commit messages that describe the changes and their purpose. This helps you and your team understand the project history and makes it easier to find specific changes later.
Use branches: Create branches for new features, bug fixes, or experiments. This keeps your main branch stable and allows you to work on multiple tasks in parallel without affecting the main codebase.
Merge regularly: Merge changes from the main branch into your feature branches regularly to keep them up-to-date and minimize merge conflicts when it's time to integrate your changes.
Pull before you push: Before pushing your changes to the remote repository, always pull the latest changes from the remote to ensure your local repository is up-to-date. This can help prevent conflicts and ensure a smoother collaboration experience.
Embrace .gitignore: Use a .gitignore file to exclude files that don't need to be tracked, like temporary files, build artifacts, or IDE-specific files. This keeps your repository clean and focused on the essential code.

These quick tips can help you make more effective use of version control systems and streamline your workflow. While they may not make you a version control master overnight, they can serve as a solid foundation for you to build upon as you continue to learn and refine your skills.

🤔 Pretty slick. Although these tips won't lead you to full version control mastery, they are now more actionable – and overall, they're pretty decent, considering it's advice for beginners.

Some points remain a bit vague, for example, "Use branches". Version control branching strategies is a broad, complex topic, and this particular point isn't very actionable without further exploration. However, it's a single outlier and at least provides a clear starting point for more in-depth research.

Overall, not bad!

Reading clean code - cutting through ambiguity.

💬 You gave me a tip to "Read clean code". But how will I know, as a beginner, which code is clean? How to recognize it? And where to find such code to read?

🤖 As a beginner, it might be challenging to recognize clean code at first glance. However, with practice and exposure to well-written code, you'll start to develop an understanding of what constitutes clean code. Here are some general guidelines and characteristics of clean code:

Readability: Clean code is easy to read and understand. It has a clear structure, meaningful variable and function names, and proper indentation. It also follows consistent naming conventions and style guidelines.
Modularity: Clean code is organized into small, focused functions or methods that perform a single task. Each module should have a single responsibility, and the code should be divided into logical components.
Maintainability: Clean code is easy to modify, extend, and refactor. It avoids duplicating code (DRY principle) and follows best practices to minimize the chances of introducing bugs when changes are made.
Documentation and comments: Clean code is well-documented with comments that explain the purpose and functionality of the code. Comments should be concise and only provide information that is not immediately apparent from reading the code itself.
Efficiency: Clean code is efficient in terms of performance and resource usage. It avoids unnecessary complexity, and the algorithms and data structures used are well-suited for the problem at hand.

To find clean code to read and learn from, consider the following sources:

Popular open-source projects: Many popular open-source projects on platforms like GitHub have high-quality code that has been reviewed and refined by multiple contributors. Explore projects in the language or framework you're working with to find examples of clean code.
Coding best practices: Look for articles, books, or courses on coding best practices for the programming language you're working with. These resources often provide examples of clean code and guidelines on how to write it.
Code reviews: Participate in code reviews within your team or seek feedback from experienced developers or mentors. Observing their feedback and suggestions can help you learn to recognize clean code and improve your own coding style.
Coding challenges: Websites like LeetCode, HackerRank, or Codewars offer coding challenges along with solutions submitted by other users. Reviewing these solutions can help you learn different approaches to problem-solving and expose you to clean code examples.

Remember, recognizing and writing clean code is a skill that develops over time. As you read and write more code, you'll become more adept at identifying clean code and adopting best practices in your own work.

🤔 This time, the result is meh at best.

The first part of the answer essentially states that you can recognize clean code by the fact that it adheres to very high-level and vague principles of being clean code (some of which, like comments and efficiency, are even debatable – for instance, does code really need to be efficient to be clean and readable?).

The second part is also hit-or-miss. Participating in code reviews is good advice (although it could be more emphasized that you should not only have your code reviewed but also do as many reviews as you can yourself, to learn from the code of more senior developers). Reading books and articles on coding best practices is sound advice but rather obvious, not adding much value. Learning from open-source projects and coding challenge websites is potentially fantastic advice, but these sources often contain bad code as well, and it still doesn't solve the conundrum of how a beginner can recognize which is which.

Let's try to dig a bit deeper:

💬 You said that to find clean code to read and learn from I can look at popular open-source projects, as many of them have high-quality code. But many of open-source projects have low-quality code as well. How can I recognize which open-source project is high-quality and which is not?

🤖 You're right that not all open-source projects have high-quality code. To identify high-quality open-source projects, you can consider the following factors:

Popularity: Projects with a large number of stars, forks, or watchers on platforms like GitHub usually indicate that the project is well-regarded by the community. While popularity isn't a guarantee of code quality, it can be a helpful indicator.
Active maintainers and contributors: High-quality projects tend to have active maintainers and a diverse group of contributors. Look for projects with a history of regular commits, updates, and bug fixes. A healthy number of contributors and an active community can be a sign that the codebase is continuously improved and refined.
Clear documentation: Well-documented projects are often a sign of a well-maintained and high-quality codebase. Look for projects with comprehensive README files, API documentation, and usage guides.
Code reviews and discussions: Check the project's pull requests and issue discussions. A healthy project will have thorough code reviews, constructive feedback, and active discussions around improvements and bug fixes.
Adherence to coding standards: High-quality projects usually follow coding standards and best practices for the programming language or framework they use. Look for consistent formatting, naming conventions, and code organization.
Automated testing: Projects with a robust suite of automated tests indicate that the maintainers care about code quality and ensuring the software works as expected. Look for projects with a high test coverage and a continuous integration (CI) pipeline that runs tests on every commit or pull request.
Dependencies and licensing: High-quality projects should have a clear list of dependencies, along with their corresponding licenses. This shows that the maintainers pay attention to the project's legal and operational aspects.

To begin your search for high-quality open-source projects, you can explore curated lists or collections, like Awesome Lists on GitHub, which aggregate popular and well-regarded projects in various domains. You can also check out projects maintained by reputable organizations or developers who are well-known in the industry.

Remember that even high-quality projects may have areas that could be improved. As you gain more experience, you'll develop a better understanding of clean code and be better equipped to assess the quality of various open-source projects.

🤔 This answer is decent once again. While factors like project popularity or good documentation don't necessarily guarantee clean code, all of them combined are a decent proxy – probably as good as you can get, since there are never hard guarantees. And the advice to look at curated lists, although they're more of an indicator of popularity rather than necessarily quality, provides a reasonable starting point. It's not exhaustive, as GitHub search, for example, is also a great way to find popular and active open-source projects. But considering that recognizing clean code is a very subjective and difficult topic, this answer is quite ok. We could try to dig even deeper - but I need to keep the length of this post under control...

Commenting your code - clarifying the questionable aspects.

💬 One of the lifehacks you gave me was to write meaningful comments to explain the purpose and functionality of my code. Can you elaborate on this? What comments do you consider meaningful? Should I always write comments for all of my code? Is there any good heuristic on when and how to write comments?

🤖 Writing meaningful comments is an important aspect of writing clean and maintainable code. Meaningful comments should provide additional insight and context that's not immediately apparent from reading the code itself. Here are some guidelines on when and how to write comments:

Explain complex or non-obvious code: If a piece of code is complex or might be difficult to understand for someone unfamiliar with the project, a comment can help explain the reasoning behind the implementation or provide a high-level overview of the algorithm.
Document assumptions and limitations: If your code relies on specific assumptions or has limitations, it's important to document them in comments. This helps prevent future issues or misunderstandings when someone else (or even you) modifies the code later.
Clarify the purpose of functions and classes: While function and class names should be descriptive, a brief comment can provide additional context on the purpose and expected behavior of a function or class.
Explain workarounds or hacks: If you had to implement a workaround or hack to address a specific issue or limitation, document the reasoning and any potential side effects in a comment. This helps future maintainers understand the purpose of the workaround and consider potential improvements.
Reference external resources: If your code is based on a specific resource, like a research paper, algorithm, or third-party library, include a comment with a reference to that resource. This helps provide context and background information for others working on the project.

Here are some tips on how to write effective comments:

Be concise: Comments should be short and to the point. Avoid writing long paragraphs or repeating information that's already clear from the code.
Keep comments up-to-date: Ensure that your comments stay relevant as your code evolves. Update comments when you modify the code, so they accurately reflect the current state of the code.
Avoid stating the obvious: Refrain from writing comments that simply restate what the code does. Focus on providing context, rationale, or explanations that aren't immediately obvious from the code itself.

You don't need to write comments for every single line or block of code. Instead, focus on commenting where it adds value and helps improve the understanding of the code. Keep in mind that well-written code should be mostly self-explanatory, so prioritize writing clear and expressive code, using comments to supplement when necessary.

🤔 This is a really good answer. While the initial tip was ambiguous and left room for interpretation that could potentially lead to over-commenting, this elaboration clarifies it well and is 100% on point. That's exactly how I'd advise approaching writing comments.

Conclusion.

There were a few small missteps here and there, but overall the results are surprisingly good.

Some answers were too obvious, some were a matter of opinion, but none of them were plainly wrong and many of them were really good and actionable. I also liked the breadth and variety of advice - it even included a point about taking care of your health!

The initial answers are shallow - they don't bring much value without going at least a few levels deeper through follow-up questions. But if you get used to this flow, it goes quite smoothly. You don't get overwhelmed with loads of information upfront but instead can explore gradually, diving deeper into only the topics you are interested in or don't understand. I'd even say that it resembles working with a real, human mentor more than, for example, reading a book or watching a course.

There's a bit more burden on you when working with ChatGPT compared to a real human mentor. A human can pick up on more cues from your tone of voice, facial expressions, and body language, and can steer the discussion more proactively in response to your behavior. When working with ChatGPT, however, the only cues it can pick up are your direct questions – so the quality of the experience depends solely on your ability to formulate clear questions, not on your mentor's experience or emotional intelligence. That being said, learning how to ask proper questions isn't too difficult, and if you do, you can still get plenty of value from your interaction.

For a beginner, the trickier part may be figuring out what exactly to ask about in order to move from shallow to deeper answers. If you don't have in-depth expertise in a given area, it's often far from obvious. However, this can be mitigated by learning to ask more general "drill-down" questions, like "Why have you chosen this answer?", "Can you elaborate further?", "Is this answer really the best one?", "Is this the only good answer?", "What are the pros and cons?", "What would be the alternatives?", "Are there more similar techniques?", and so on. Getting good at asking questions like these will also benefit you in your day-to-day job: when clarifying requirements, brainstorming with your teammates, or even when working with a real human mentor – so it's a worthwhile training in itself.

To sum it up, from what I can observe from such a limited test, I'd certainly recommend it.

It's not a complete substitute for a real human mentor, but if you don't have access to one, you should definitely try ChatGPT. And even if you do have a mentor, it's still worth leveraging both, as ChatGPT is much more readily available. You can start with ChatGPT (and use it more frequently) and then ask your real mentor to evaluate its answers, expand on them, or delve deeper into trickier areas while sticking to ChatGPT for the more straightforward cases.

It may also be beneficial to start with a high-level overview of what there is to learn in a given area, to understand the overall lay of the land - and then use ChatGPT to dig deeper into selected topics. There are many good resources that provide such an overview, like roadmap.sh or my "Definitive Guide to Succeeding as a Professional Dev".

To immediately improve your game, check out also my free PDF: 📖 20 Instant Tips to Rapidly Level Up as a Developer

Are You Just a Code Monkey? Or a Professional Developer?

Wojciech Zawistowski — Wed, 26 Apr 2023 20:30:13 +0000

In a nutshell

Software is the main engine of revenue and growth for most companies. It is also done at a scale that makes it impossible to micromanage everything top-down.

Thus, being just a code monkey won't cut it. Professional developers are expected to contribute to the company's overall success: provide a competitive advantage, fuel sustainable growth, ensure adaptability to changing market conditions.

In this article, I'll take a deeper look at what makes companies successful and what skills you need as a developer to help achieve this success.

The evolution of software development (too critical to neglect, too complex to micromanage)

As Marc Andreessen famously said in 2011, software is eating the world.

Modern companies depend on software as never before. Even if they don't sell it directly as a product, software is still fundamental to driving their operations and growth. It's critical for their customers, employees, suppliers, and partners. It's the engine that runs the business - and the network that connects it with other businesses. It's the cornerstone of the company's success.

At the same time, the software got bigger. Much bigger. And the software development process got incomparably more complex: Huge teams. The whole portfolios of products. A vast network of interconnected APIs. Complex distributed architectures. Tens or even hundreds of external vendors. Constant progress at a crazy pace. Cutthroat competition and continuously changing user tastes. No manager, analyst, or architect is able to micromanage it all. The responsibility has to be distributed.

And this completely changes the game for us, developers.

Raising the bar for software developers (the new definition of a "code monkey")

A "code monkey" isn't a new term. Developers who just churn out code without looking at a broader context were frowned upon from the early days of programming. However, for a long time, this "broader context" just meant more conceptual work like code design or architecture. But it doesn't cut it anymore.

Nowadays, I'd define a code monkey differently: A code monkey is a developer who contributes only to building software, not to the holistic company's success.

Yes, this is why we, developers, are hired. To generate business value. To make companies grow and thrive. And this requires a different mindset and a different, broader set of skills.

But, first of all, you need to understand what makes companies successful - and where you fit into this puzzle.

The 4 key elements of the company's success (and how you can influence them as a dev)

The recipe for a company's success, while insanely hard to achieve, is, at its core, very simple.

First of all, a company needs to have a competitive advantage. It needs to be better than the competition (or at least differentiate itself enough) in one or more of these aspects: have a better product, be more innovative technologically, build new products faster, or be cheaper.

Then, when the company becomes successful, it naturally starts to grow. Rapid growth is hard to manage and - if the company is not skillful at it - can destroy its competitive advantage.

Next, to be truly successful, a company needs to sustain its competitive advantage over time. It needs to cut enough corners to win now - but not as many as to die the "death of a thousand cuts" later.

Finally, the world never stands still. To not lose its edge, a company needs to continuously evolve to adapt to the ever-changing user tastes, competition, and market.

Let's now take a look at these 4 ingredients in more detail.

Competitive advantage: Product

Building a better product is the most obvious competitive advantage. If users like and buy your product more than the other ones - you win. But what convinces them to do so?

It all boils down to two things: addressing users' needs and providing a great user experience.

So how you, as a developer, can influence these two areas?

Improve your communication skills to collaborate effectively across functions, with designers, product managers, business stakeholders, and users. Especially, learn how to talk to non-programmers (explain technical concepts simply, abstain from jargon, be patient with less tech-savvy people, etc.).
Learn the principles of experimentally discovering what users want: Agile, empiricism, iterative development, Lean Startup, product discovery.
Get good at working in short iterations, building small MVPs (Minimal Viable Products), and rapid prototyping, to help product managers validate ideas faster.
Understand how to rapidly test ideas without coding (fake door, Wizard of Oz, concierge, and similar techniques).
Learn the fundamentals of the product metrics and get a good overview of various analytics approaches (page views tracking, event tracking, backend API requests tracking, heatmaps, etc.) and the analytics tooling ecosystem (Google Analytics, Pendo, Segment, HotJar, and so on).
Don't push to always solve everything by writing new code. Get comfortable with solving problems through 3rd party integrations and no-code solutions.
Learn the basics of usability and user experience (UX).

Competitive advantage: Technology

Developing more advanced technology is another competitive edge. This is a bit different from just creating a better product. Of course, you still need to solve real user problems, but your winning strategy is not making the product more fine-tuned and polished but making it capable of things no one else is capable of.

Imagine invoicing software. Making re-typing the content of paper invoices into the system by hand smoother, faster, and done in fewer steps is one thing but being able to import them automatically, without typing anything, through advanced text recognition and extraction would be at a completely different level, even if the interface is not that polished.

It doesn't have to happen at such a dramatic scale, though. Even small technical advancements can provide a competitive edge: make processes faster for the user, reduce their costs, make the product more capable.

But how a regular developer can help their company gain a technological advantage?

Get a good overview of the existing ecosystem, both open source and commercial: languages, frameworks, libraries, cloud and SaaS platforms, APIs, tooling, and so on. Often the advanced capability you need is already out there, available as a 3rd party library or service - you just need to know it exists and understand how it can be used.
Stay up to date with the newest trends and technological advancements (especially the upcoming, not yet widely adopted ones) to be able to notice and exploit opportunities to gain a technical advantage.
Learn about your company's business domain, its product, and its competition, so you can propose the most innovative technical solutions to the business problem at hand.
Stay up to date with what's happening also outside your company's domain. Track what other popular apps are doing - what's the current state of the art in the broader industry - and "steal" and adapt the best ideas to your company's needs.
Experiment with new stuff regularly (just enough to get a good grasp of what it is about and be able to quickly learn more about it when needed).
Get good at researching, quickly learning new tech when needed, and doing small prototypes and proofs-of-concept.

Competitive advantage: Process

The next way of gaining a competitive advantage is through better processes. In other words, the ability to build stuff faster than the competition without sacrificing quality. In the short term, it will give your company the first-to-market advantage. In the long term, it will allow you to experiment more rapidly, which will impact also the first two advantages: better product and technical innovation.

An important part of a good process is also the ability to continuously refine the process itself, to stay ahead of the competition in the long run.

Processes - especially related to efficient delivery - are something developers have a lot of influence over.

Become a fast, efficient coder. Learn your IDE in-depth. Get good at debugging. Use tools that speed you up: auto-formatters, code generators, code intelligence, hot reloading, etc. Understand how to organize the codebase to navigate around faster.
Learn how application architecture impacts not only scalability and performance but also efficient teamwork, code navigation, and debugging.
Build a robust toolbox of techniques to minimize the number of bugs (and to fix them more efficiently): unit testing, error handling, application monitoring and logging.
Understand technical debt and how to strike the right balance between cutting too many corners and over-engineering. Become good at making the right compromises between delivering business value and maintaining necessary non-functional features (reliability, performance, security, scalability, maintainability, quality).
Understand modern delivery processes: CI/CD, Git branching strategies, feature flag-based development, and so on.
Learn at least the basics of the most popular software development processes (Scrum, Kanban).
Get accustomed to process improvement techniques (retrospectives, project post-mortems, root-cause analysis, etc.).
Be open to experimenting, to trying new processes and techniques. Be proactive in proposing and championing improvement ideas. But also know how to balance implementing improvements with generating business value.

Competitive advantage: Operations

The last type of competitive advantage is more efficient operations. Depending on your company's profile you may have different teams involved in acquiring, onboarding, and supporting users: sales, call center, customer success, customer support, implementation, operations, invoicing, and so on. Making these teams faster, cheaper, and more user-friendly is another way to win over over the competition.

How can you help with this as a developer?

Learn how your various "operations" teams work: what they do day-to-day, what metrics they use to measure their success, what makes them efficient and what slows them down, how they interact with customers.
Get a good overview of the tools to rapidly build internal tools faster: automatic admin panel generators, CMS frameworks, UI component libraries, and so on.
Understand the trade-offs of buying vs building vs integrating internal tools (admin panels, invoicing systems, CRM platforms, inventory management and order tracking systems, etc.).
Know how to most efficiently keep your customer-facing teams updated about the status and expected completion time of your work (for example, bug fixes) so they can easily obtain and pass this information to customers.
Understand personal data privacy and security issues: how to make your "operations" teams more efficient by providing them tools like user-impersonation or giving them access to user data for tech support purposes without compromising user privacy.

Growth

To become successful, companies need to constantly grow their revenue. It almost always means also growing the team. This, in turn, means more recruitment effort (including onboarding and mentoring), a bigger codebase, more complicated architecture, and increased complexity of organizational structure. It also makes communication, teamwork, and management more challenging - usually to the point where top-down micro-management doesn't cut it anymore.

This sounds like a management problem. But even as a "regular" developer, you can help much more than you think.

Learn how to modularize the codebase and architecture so multiple teams can collaborate without collisions. Familiarize yourself with Domain Driven Design, micro-services, micro-frontends, API design principles, git repository topologies, and similar. Understand how to evolve the architecture over time, to accommodate the growing size of the platform and the growing number of teams, without over-engineering it early on.
Learn how to make code easy to read, understand, debug, navigate, and modify for other people. Understand the concept of cognitive load. Get a good grasp of clean code principles.
Understand what makes the whole engineering organization go faster (design systems, component libraries, coding conventions, UI guidelines, and so on). Understand compromises between what to standardize and what can be different per team.
Learn how to communicate well (clearly, understandably, concisely, and on-point), both verbally and in writing. Learn how to effectively brainstorm, make decisions together, and navigate disagreement or conflict. Understand how to effectively sync and collaborate with the other teams.
Find opportunities to help with recruitment. If not by directly participating in the interviews, then by reviewing CVs, preparing and evaluating coding and system design challenges, and promoting your company (through blogging, social media, conferences, or by directly recommending your colleagues).
Make onboarding easier. Understand and use industry-wide standards to lower the entry point for new hires. Know how to document and explain architecture and logic. Be responsive, non-condescending, and open to answering all questions.
Help with mentoring. Understand what tasks to assign to someone new or more junior and how frequently to sync with them to not overwhelm them but also not leave them hanging. Be supportive and patient.
Take ownership of various projects, initiatives, and modules to reduce the burden on management - so they don't have to micro-manage everything.

Sustainability

Companies are long-living entities. Gaining a competitive advantage and achieving initial success is only the start of the game. A company needs to sustain its success over decades.

But when a company is under constant pressure, fighting off new challengers and chasing ever-changing market conditions, it's often necessary to cut corners. Which may put the company at risk further down the road.

To thrive over a long time, a company needs to strike a fine balance between aggressive and sustainable. How can you help maintain this balance?

Get a good understanding of the concept of technical debt and the ways of managing it. Develop a keen eye for both under and over-engineering. Learn the patterns and principles of code maintainability and evolving complex legacy codebases over time.
Be aware of the short- and long-term trade-offs between the development speed and the concerns like reliability, performance, scalability, security, privacy, usability, or maintainability.
Understand short- and long-term implications of various architectural decisions (monolith vs microservices, native vs hybrid mobile, REST vs GraphQL, single-page app vs server-side rendering, monorepo vs multiple repos, and so on).
Know how to evaluate new technologies not only by the "cool" factor but also by the learning curve, maintenance cost, ease of recruitment, vendor lock-in, long-term support, and similar. Be aware of the build vs buy vs use open source trade-offs.
Understand how technology choices impact business and UX capabilities and how they broaden or narrow down what the company will be able to solve for its users.
Don't just passively follow business requests. Participate in setting technical vision and direction and provide guidance and counsel to the rest of the organization.
Learn how to maintain a healthy lifestyle and avoid burnout.

Adaptability

To stay successful for a long time, sustainability alone is not enough. Companies also have to continuously adapt (or even reinvent themselves).

A company has to adapt to the macro-scale events (changing market conditions, changing customer tastes, new technologies, economic situation, fashion, and social trends) and to the micro-scale events (finishing and starting projects, people leaving and joining, reorganizing teams or departments, adopting new methodologies and processes).

It may, again, seem like something out of the scope of a software developer. But with the right attitude, you can help much more than you think.

Understand the core principles of empiricism, experimentation, and Agile.
Be able to quickly pivot and adapt to new trends, tech, and methodologies. Become an eager learner. Know how to learn fast, how to research, and how to efficiently find information.
Understand how to architect systems to make it easy to gradually migrate parts of them to new tech in the future. Learn how to effectively carry out such migrations.
Most people dislike and avoid change. Make yourself open to it and comfortable with it. Train yourself to thrive in such an environment. Become good at adapting to new projects, teams, and roles.
Learn how to quickly build rapport with new people.
Be open to new points of view, and for updating yours in face of sound evidence.

Bottom line

A purpose of a developer is to make the product and company successful. That's why we're hired. That's why we exist. And modern software is so complex that this process can't be micromanaged. We must proactively contribute to the company's success. Become the experts on the topic.

If you understand the holistic view - what makes companies successful, how the software fits into this puzzle, and how you can influence it as a developer - you'll be invaluable. (And it also opens the door to a future leadership career.)

Plus, it's much more satisfying to understand the whole picture than to just blindly follow what you're told.

Don't want to be just a code monkey? Read my "Definitive Guide to Becoming a TRUE Senior Dev" (FREE on GitHub).

10 Traits That Separate the Best Devs From the Crowd

Wojciech Zawistowski — Fri, 24 Mar 2023 16:00:00 +0000

We work hard to improve our tech and soft skills. But our character traits, our mindset - we take it for granted. An innate, fixed part of who we are. And thus we let it run on autopilot.

This way of thinking is harmful. Not only is your mindset critical for a successful software development career (maybe even more than your skills) but it's also under your control.

True senior devs acknowledge that character traits are malleable, are self-aware of their mindset, and deliberately work on it. This is the superpower that makes them stand out from the crowd and accelerates their career.

In this post, I'll discuss the 10 most critical traits of a successful developer, why are they important, and share a few tips on how you can shape them.

3 things you need to succeed as a software developer

Professional software development is a complex discipline, which requires a diverse set of abilities to succeed. We can group them into three main categories:

Technical skills

This is the most obvious group. To be a successful developer, you need to be good at your trade: programming languages and frameworks, clean code principles, architecture, testing, debugging, and so on. You also need to be skillful with your tools: version control, command line, IDE.

However, technical skills alone won't get you far in a professional, team-based setup. That's why you need also soft skills.

Soft skills

To be able to work on big, commercial projects you need a solid set of soft skills: teamwork, communication, project management and planning, remote work, self-organization, learning, personal productivity, and similar.

Many of us find these skills less fun than the technical ones, and thus we often neglect them - so they can already separate solid, professional developers from the crowd. But at least we acknowledge them.

There's also a third category, though, which is equally important but flies under the radar of almost all, even the otherwise good, developers.

Mindset

Mindset is kinda similar to soft skills, but the "skills" it's comprised of are more fundamental, core traits: curiosity, patience, empathy, grit, adaptability, and so on.

On some level, we know these traits are important for a successful software development career. But because they seem an innate, fixed part of our personality, we do not attempt to deliberately learn them in the same way we learn project management or personal productivity techniques.

This makes us blind to a huge and important part of our skillset and can badly hurt our progression.

Why being blind to your mindset can jeopardize your career

Software development is a complex, sometimes frustrating, and insanely fast-moving field. Learning, growing, and staying relevant as a developer (and not burning out in the process) requires a specific mix of character traits.

At the same time, it's a 100% team game. Lone-wolf hackers have no place in professional software development, no matter how good they are technically. And functioning well in a team requires another, seemingly opposite, set of traits.

Mindset is something different than skills. Understanding Agile development principles is not the same as being adaptable and open to frequent change. And knowing the debugging techniques is not the same as having the curiosity and persistence to actually enjoy chasing the problem for several hours without getting burned out or discouraged. But while these traits may seem fixed, innate to our personality, they are equally learnable as skills.

Without understanding what traits are critical for a programmer and deliberately honing them over time, you'll never reach your full potential. True senior developers know this, are self-aware of their mindset, and continuously work on improving it. This is the differentiator, the superpower that separates the best developers from the crowd.

Ok, but which traits are the most important? Let's dive a bit deeper into the details.

10 traits of a true senior developer

1. Curiosity

If I had to summarize in one sentence what software development is about, I'd say it's about learning. You need to stay up-to-date with constantly evolving technologies and software development processes. You need to learn the deep details of complex business domains (several ones throughout your career). Analyzing and clarifying requirements is learning. Research is learning. Performance optimization and debugging - in other words, poking deeply into the inner workings of code - is a kind of learning as well.

Software development is also about working with people (and for people). You'll be working on cross-functional teams, with a diverse set of people from different specializations and backgrounds (nowadays, in the age of remote, most probably from multiple countries and cultures). You'll have to understand "business". You'll have to understand and solve user pain points and problems.

Without a healthy dose of curiosity, you'll not only be less effective at all those things but you'll also burn out pretty quickly.

2. Affinity for problem-solving

Software development is a giant puzzle - an infinite stream of problems to solve. The reason you are hired as a developer is to solve your company's and customers' problems. To do this, you need to solve organizational problems (how to function as a team, how to organize your work, what processes to use) and technical problems (logic, architecture, performance, and so on). These problems consist of even smaller, nested problems, down to atomic problems like how to design and name a particular function or unit test.

If you don't enjoy solving such puzzles, if you don't have a knack for breaking down and untangling problems, your software development career will be a struggle.

3. Patience

Becoming a true senior developer requires years of deliberate practice. You'll also experience a lot of setbacks along the way. Developing your career is rewarding but also a slow and sometimes painful process. To achieve excellence and get to the top, you must be ready for lifelong dedication. And this requires a lot of patience.

Patience is also critical for a lot of things adjacent to our job: handling technical support, working with not-very-tech-savvy users, coping with organizational bureaucracy. Plus, it's a great problem-solving aid. And you won't sustain working in such a fast-moving, constantly changing industry as tech without patience.

4. Grit (in just the right amount)

Software development requires a lot of persistence. Hunting bugs. Deciphering poorly documented APIs and libraries. Untangling legacy code. Tracking down performance bottlenecks. Even simply sustaining a deep focus for extended periods of time.

You'll struggle, and fail, and get stuck, and get frustrated a lot - no matter how senior you are. And you'll need a lot of grit to plow through and not get burned out.

But you also need to understand what's the right amount of grit. What's the sweet spot between unproductively banging your head against the wall for hours and days vs constantly disrupting your team by requesting assistance immediately when you hit even the smallest bump in the road.

5. Emotional intelligence

Software development revolves around people and teams. You'll work very closely with your colleagues at an individual level: pair program, debug together, review their code. You'll also work with them in a team setup: brainstorm, plan, and make decisions as a group. And this collaboration is messy: your work will overlap or conflict, you'll have different opinions. You'll negotiate your roadmap with management. Finally, to build a great product, you'll have to put yourself in your users' shoes.

On top of that, all these people come from diverse backgrounds, both technical and non-technical. They are passionate. They have strong opinions. They may sometimes have difficult characters. And your success as a developer depends on how well you can build rapport with them. Without high emotional intelligence, it'll simply be impossible.

6. Ability to keep your ego in check

Software development (and working in a team in general) is a balancing act. On one hand, you're hired for your expertise. You're expected to have strong opinions and to guide less tech-savvy or more junior people. On the other hand, you'll work with equally experienced and opinionated teammates, who will challenge your point of view and with whom you'll have to make group decisions.

Your ego will often get hurt in the process. You must be able to keep it in check - but without getting withdrawn and disengaged.

You must be opinionated but not zealot. Have a strong point of view but hold it weakly, be open to getting convinced otherwise. You must be ready to defend your opinion but also know when to let go, to not be a condescending, brilliant jerk. You need to respect the team, business, and customers. Be able to disagree but commit. And gracefully take constructive (and even purely negative) feedback. Otherwise, you won't be able to effectively work in a team.

7. Adaptability

Everything in software development is moving so fast. Technologies are constantly changing. New methodologies get popular. Companies pivot.

Throughout your career, you'll be also changing projects, teams, companies, and business domains. Even a single project is a constant act of inspecting and adapting (especially in agile approaches). And your team will constantly self-reorganize, too.

Most people are allergic to change. Change is hard. It's uncomfortable. It's stressful. Being adaptable and open to change will instantly set you apart. It will not only let you climb to the top of the seniority ladder but it will also let you stay there for a long time.

8. Reliability

I'm repeating it ad nauseam, but software development is a team game. Your colleagues, manager, and company - they all count on you to do your part. Nobody ever will consider you a true senior developer - no matter your tech expertise - if they can't rely on you to take care of your work and deliver on your promises without having to be micromanaged.

It doesn't mean you can never make any mistakes. Failures happen. And the best companies see them as valuable learning opportunities. But to enable this, you need to be able to pick up a dropped ball, gracefully recover, and be trusted to learn from your failure and not repeat it in the future.

9. Pragmatism

Professional software development is an art of tradeoffs. You constantly need to compromise between development speed and quality. Balance new and promising with proven and stable. Walk a thin line between under- and over-engineering.

To succeed in professional software development you need to be very pragmatic. You need to understand that nothing is black and white, that no principle or pattern holds true in every situation. You must have great intuition for making tradeoffs between different approaches, technologies, and solutions; feel comfortable cutting corners but have a good sense of how much.

10. Positive outlook

Your life as a programmer is not all sunshine and rainbows. You'll meet annoying customers. Face tight deadlines. Your project may get canceled. You may disagree with your team or management but still have to commit and execute. You'll also work with ugly code. (Yes, every codebase has good and bad parts, even at the top companies like Google.)

You'll get tired, frustrated, upset.

If you let negativity take over, if you start criticizing and complaining, you'll not only demotivate yourself but you'll also kill the morale of your team - which won't take your career very far.

You need to be biased toward the positive. Be optimistic and cheerful. Always look for a silver lining. Be the person who rallies their team, kills the bad mood, and restores morale. It'll not only get you noticed and promoted, it'll also make your career more pleasant and sustainable.

BONUS: A few tips on how to deliberately shape your mindset

Skills, obviously, can be trained - both soft and technical ones. You can get better at debugging as well as at communication. But what about such seemingly innate traits like curiosity or a positive outlook? Can you really train yourself to be more optimistic or curious?

Yes, you can! This is a vast topic, worth several books ("Mindset" by Carol S. Dweck is a great starting point). But let me quickly share a couple of tips:

Acknowledge that your mindset is not fixed, that your traits are malleable.
Build self-awareness. Observe how you react in different situations. Try to understand what makes you feel in a particular way (curious vs bored, positive vs grumpy, eager vs defensive).
Retrospect on your behavior from a perspective of a day or two. Was your opinion really pragmatic or was it your ego talking? How could you have acted differently?
Prepare in advance. Pre-plan up-front how you'll behave next time in a similar situation and identify the right trigger that will remind you about your plan when the time comes.
Expose yourself to situations that will let you exercise and strengthen desired traits. Actively look for such opportunities.
Focus on a single trait for some time. It will make it easier to find opportunities to exercise it and to increase your self-awareness of this trait.
Reframe. Be conscious and deliberate about how you talk to yourself. The idea isn't stupid, it's surprising. That shiver isn't anxiety, it's excitement. The problem isn't frustrating, it's interesting.
Enlist help. Don't shy from asking your colleague or manager for feedback - or even to become your "accountability partner" who will catch and point out your unwanted behavior.

I also encourage you to learn a bit about cognitive biases and habit forming. This is a well-developed discipline, with a huge body of knowledge, and pretty fun to explore.

Bottom line

If you want to be a true senior developer, you have to be a complete one. You must have the right mix of tech skills, soft skills, and character traits and you can't ignore any part of this trio.

Character traits are the most tricky part. Most developers neglect them because they are either not self-aware of them, don't know which ones are important, or don't believe they are malleable.

But if you can overcome this flawed way of thinking - if you can change your mindset - you can turn it into a superpower that will elevate your career and make you truly stand out.

😎 Are you a TRUE senior dev? 😎 Are you on the right track to becoming one? ➡️ CHECK MY ULTIMATE GUIDE TO FIND OUT. ⬅️

The Ultimate Guide to Becoming a 10x Dev

Wojciech Zawistowski — Fri, 10 Mar 2023 19:36:41 +0000

Software development is a team sport. Your individual performance doesn't matter as much as the performance of your whole team and company.

By improving how you work, you only ADD to your team's performance. By improving how everyone works, you MULTIPLY your team's performance.

Multiplying the whole team's performance will put you on a much faster lane for being noticed and promoted than being a crazy efficient individual contributor.

Boosting other people's performance requires a different mindset and approach than boosting your individual performance. In this article, I'll show you 16 proven ways to multiply the performance of your team (or even the whole company).

The common misconception of 10x dev

If you google the term "10x developer", you'll get a lot of results related to individual performance.

Check out the quotes from a few of the topmost results that I've got:

"A ten times developer is the developer who is ten times more efficient than the average developer on a team."
"These are the people you want to solve your problems; they’ll do it in 1/10th of the time, with 1/10th of the number of lines of code."
"I am accustomed to being on teams where I am doing 60% of the work with 7-8 developers on the team."

Statements like these make me cringe.

This. Is. Not. How. We. Build. Modern. Software.

Software development is a team game. Or even a team of teams game. And the game is scored by business outcomes, not raw outputs. By being effective as a team and organization, not efficient as an individual.

As a VP of engineering, I'm not looking for competitive coders. I don't care how many lines of code you crank in what time. And a single developer doing 60% of the team's work is not something I'd brag about but a dysfunction I'd consider my priority to fix.

So who I am looking for, then? Let's consider the following math:

The simple math of working in a team

If you improve only your own output, you ADD to the output of your team.

But if you improve every team member's output, you MULTIPLY the output of your team.

And multiplication beats addition pretty quickly.

Even if you truly are a mythical 10x dev, you'll only increase your team's output by 10 "units", no matter the size of the team. But if you improve the whole team's output by just 2x, you'll increase it by 10 "units" for a team of only 10 people. And by 100 "units" for a team of 100 people.

And we're talking about an extreme situation when you are 10 times more efficient than EVERY other developer on the team. In reality, multiplication will beat addition for teams much smaller than 10 people.

Plus, we're talking only about the raw output: how hard do you push, but not in which direction do you push. And the direction the whole team pushes in is critical.

Your team's and your individual performance are connected

It doesn't matter if a motorboat has a 100 or 1000-horsepower engine if this engine pushes the boat sideways or backward, not forward. If you push in the wrong direction, you may not only waste your own output - you may undermine the work of your whole team. You can become a -10x developer.

And this relationship is two-sided.

Even if you push in the right direction, your god-mode 10x productivity can be negated if the rest of your team is pushing in the opposite direction.

You need to help them, so they can help you. Cancel the weaknesses of your team so they don't cancel your performance.

It may sound counter-intuitive, but focusing on making your whole team more effective is often a better way to boost also your individual performance than focusing only on your own output.

That's why I and other managers aren't looking for individual efficiency as much as for the capability to positively impact your team. And the broader impact you make - the more people you help go fast in the right direction - the more value you generate for your company.

But don't just take my word for it.

What gets you promoted at most software companies?

Let's take a look at engineering career ladders at a couple of well-known companies:

CircleCI

CircleCI uses a 6-level ladder (E1-E6): Associate Engineer, Engineer, Senior Engineer, Staff Engineer, Senior Staff Engineer, and Principal Engineer.

Levels E1-E3 focus on the execution of work. E1 within task, E2 within epic/project, E3 within team.

Levels E4-E6 utilize skills to scale and generate leverage. They facilitate, guide, and mentor others. E4 within team and with team's business stakeholders, E5 across several teams, E6 across organization.

SOURCE: https://docs.google.com/spreadsheets/d/131XZCEb8LoXqy79WWrhCX4sBnGhCM1nAIz4feFZJsEo/edit#gid=0

Carta

Carta uses a 7-level ladder (L2-L8). In their own words:

It’s easy to articulate the single most important thing for leveling: your impact on the company. We can sum up the entire system by describing the (rough) impact we expect employees to have as they progress: on tasks (L2), on features (L3), on problems (L4), on teams (L5), on the organization (L6), on the company (L7), and on the industry (L8).

SOURCE: https://medium.com/building-carta/engineering-levels-at-carta-d33db2a55a20

Spotify

Spotify doesn't care that much about external titles like senior, staff, or principal developer. They are very flexible about them and let employees choose what makes the most sense for them. But internally, they use a 4-level ladder organized by what they call "scopes of impact". And they describe these 4 levels ("steps") like this:

We have identified four Steps in your career path at Spotify. Each Step is marked not only by increased responsibility, but also by your increased impact within tech: Individual Step, Squad/Chapter Step, Tribe/Guild Step, Technology/Company Step.

SOURCE: https://engineering.atspotify.com/2016/02/spotify-technology-career-steps/

Dropbox

Dropbox uses a 7-level ladder (IC1-IC7): Software Engineer 1-4, Staff Software Engineer, Principal Software Engineer, and Senior Principal Software Engineer.

This is how they describe the "extent of influence" for each level:

IC1: I work within the scope of my team with specific guidance from my manager.
IC2: I work primarily within the scope of my team with high level guidance from my manager.
IC3: I work primarily with my direct team and cross-functional partners while driving cross-team collaboration for my project.
IC4: I am a strong leader for my team with my impact beginning to extend outside my team.
IC5: I am increasingly influencing the roadmaps of other Dropbox teams to achieve business impacting goals.
IC6: I typically influence the technical strategy of a group.
IC7: I typically influence the department and company-wide strategy to achieve business-impacting goals.

SOURCE: https://dropbox.github.io/dbx-career-framework/

I have chosen these 4 companies as they describe their ladders most succinctly and thus can be quoted almost directly. But a similar pattern repeats widely across the whole industry.

So what gets you promoted in all these companies? What do they value the most?

Again, the area of the impact that you make.

The bigger chunk of an organization (and the more people) you positively influence, the more valuable you'll be for the company - and the more recognition you'll get.

Operating at such a level may sound scary. But boosting your whole team's performance by 2 or 3x is often less daunting than it sounds. And easier than dialing up your individual performance to 10x.

Ok, so how can you do it?

How to impact the performance of the whole team or company?

It's hard to be completely exhaustive, as there are many ways you can positively impact other people's performance. But let's explore several of them so you can get a good gist and build the mindset that will let you come up with further ideas on your own.

1. Teach, mentor, and share your knowledge

Start small. Discuss stuff with your teammates. Spread your knowledge through code reviews, pair programming, and team meetings. Lead by example, through your work and behavior.

Spread your knowledge not only about coding but about anything that may impact your team's performance: processes, communication, time management.

Extend your impact to more people through brownbags, workshops, and blogging. Take opportunities to collaborate with other teams.

Finally, when you're widely recognized as an expert, take responsibility for managing company-wide learning programs or leading communities of practice.

2. Bring new knowledge into the company

Don't be a one-time sensation. Don't rely only on your previous experience.

Learn continuously. Talk to colleagues outside your company. Read. Go to conferences. Stay up to date with the industry's state-of-the-art. Research what other companies are doing. Experiment with new techniques and libraries.

Be the source of innovative knowledge that will help your team reach the next level.

3. Plan and coordinate projects

No matter what process you use, software development is, in the end, a stream of big and small projects. How well they are analyzed, broken down, planned, and executed has a tremendous impact on the performance of the teams running them.

Volunteering to prepare and lead projects is a great way to impact multiple people's performance.

Start by taking responsibility for one part of the process: requirements analysis, implementation plan, or task breakdown.

Dial it up by owning the process end-to-end, overseeing the whole project execution.

And for maximum impact, take responsibility for coordinating big, cross-team projects.

4. Take ownership of a part of the codebase or product

In complex software systems, there are many "moving parts" that need to be maintained over a long time: modules, libraries, subsystems, products, services, APIs, tools, documentation, pipelines, and so on. It's not easy to maintain them well without clear ownership. And how well they are maintained, has a huge impact on the performance of everyone using them - which, for some cornerstone modules, may even mean everyone in the whole company.

By taking ownership of a part of your company's codebase, product, or subsystem and keeping it in great shape, you can make an impact that will be hard to miss.

On a smaller scale, you can maintain something internal to your team, for example, a small code module or web service.

On a bigger scale, you can maintain something fundamental to the whole product and company, like a central design system or customer-facing API.

5. Improve tooling

Efficient tools make a tremendous difference in how fast a team can go. And there are so many things in our work that can be optimized, automated, or used in a more skillful way.

Solid CI/CD pipeline. Code formatting and linting. Fast test suite. Automated code and test data generation. More efficient code navigation. Utilizing the full power of your IDE. Better local, test, and staging environments. Well configured project management system. Robust tooling for debugging, monitoring, and logging. Better discoverability of components and shared libraries. Automating and connecting your workflows (Github, Slack, Trello, etc.). The list could go on and on.

By improving the tooling, automating repetitive tasks, or even just spreading the knowledge of how to use existing tools better, you can greatly impact the performance of your team and the whole company.

6. Improve codebase and architecture

Put yourself in the shoes of colleagues who will visit the project after you. Easy to understand code and architecture can make or break the whole team's performance. Make them cleaner, simpler, easier to navigate and debug, and less error-prone.

Even relatively small improvements, to one component or module, can considerably boost the performance of your team. And the more global improvements - for example, to product-wide code conventions - can impact even the whole company.

7. Help your team go in the right direction

Rallying people together to push towards a single, right direction is one of the most powerful ways to multiply the whole team's performance. And you can influence it much more than you think.

First of all, understand the right direction yourself. Put effort into understanding your company's goals, business, and customers. This will allow you to understand what problems need to be solved, and come up with better solutions to these problems.

Second, help your team go in the right direction. Share and document what you learned. Help your team track relevant metrics, gather feedback, and work in a more iterative, agile way. Become a trusted consultant for your product manager.

Third, help coordinate with the other teams and stakeholders, so the whole company goes in a single direction.

8. Support non-developers

Software isn't built only by software developers. It's a concerted effort of developers, designers, testers, product managers, analysts, data scientists, user researchers, and various business stakeholders (customer support, marketing, sales, finance).

Support them. Work closely together. Put effort into making their lives easier, into helping them go fast, into coordinating your efforts so the whole cross-functional group works smoothly together. This will allow you to impact your organization at an even broader scope than the engineering team alone.

9. Improve methodologies and processes

How your team and organization works has a fundamental impact on performance. And it's not reserved only for managers and scrum masters. As a developer, you can, too, influence company processes a lot.

First, educate yourself. Understand the principles of empiricism, iterative development, product discovery, and Agile. Get to know modern technical approaches like CI/CD or feature flag-based development. Learn how modern cross-functional teams function.

Second, observe with a critical eye, proactively look for opportunities for improvement, and take the initiative in shaping the process. Be active inside and outside of your team. Participate in process-related discussions. Champion implementing new ideas.

You'll be able to multiply the performance of many people and teams.

10. Lead technical initiatives

Many technical improvements require a concerted effort of the whole team over a longer time: successively replacing the old framework with a newer one; migrating to a new set of coding conventions; gradually refactoring a critical part of the codebase.

If they aren't consistently managed and pushed forward, such initiatives usually quickly fizzle out. And their outcomes are mediocre at best.

Volunteer to lead such initiatives. If you plan and manage them well, if you make it easier for other people to contribute, if you coordinate the efforts around them and see them through to completion, you can make a substantial impact on the future performance of your team and organization.

11. Improve communication and transparency

Clear, transparent communication is essential for effective teamwork. It determines how well people coordinate, how much they trust each other, how good decisions they make, and how well they understand their objectives. And this applies at all levels: inside a team, between teams, between different roles and departments, between employees and management. The quality of communication can hinder or unlock the whole organization's performance.

And you can do a lot to improve it.

Share your status with the other teams. Maintain your team's and company's documentation, roadmaps, and wikis in a good state. Help your team stay informed by proactively pulling information from the other teams. Ask management to clarify your team's goals and update them on your progress. Propose improvements to company-wide communication standards and channels (Slack, etc.). Initiate cross-team coordination meetings whenever necessary.

12. Exemplify and promote the culture

There's no single right culture. Different companies conduct themselves differently with a similar level of success. But if different people, teams, and departments in the same company culturally clash, it kills productivity.

Understand your company's culture. Exemplify and promote it. Be conscious of your behavior and communication patterns.

It impacts your company's performance more than you think.

13. Motivate others

Sometimes, reaching higher performance is just a matter of motivation. The willingness to push harder. Feeling more hungry for success. Having the right attitude.

You don't have to be a manager to influence your team's morale. Lead by example. Spread good vibes. Show enthusiasm, optimism, and grit. Make the work fun. Stay calm and composed in a crisis. Rally your team to push a little bit more every day.

Such behaviors are viral and frequently work better than attempts to "empower" people from the top. And they easily spread outside of your team, which will let you make a broad impact.

14. Help with recruitment and onboarding

Another way to boost an organization's performance is through recruitment.

If you can, get involved in the recruitment process. Participate in the interviews. Help prepare recruitment challenges. Review CVs.

And even if you can't participate in the recruitment process itself, there's still a lot you can do to help bring new talent on board. Refer your colleagues. Promote your company through blogging, discussion forums, speaking at conferences, and networking. Leave a positive review on Glassdoor. Take responsibility for onboarding and mentoring new hires.

15. Solve complex problems (and then spread the knowledge)

If you can solve a problem no one else is able to solve, such that will give your company a competitive advantage, you can generate a ton of value.

This may sound like a task for a lone, 10x genius, but it is still about the team. If you won't spread the knowledge about your brilliant solution, if you won't design it so it's easy for others to reuse, you'll become a bottleneck and a potential single point of failure instead of a multiplier. You'll put your company at risk, not bring value.

But if you can solve complex problems in such a way that everyone understands your solution and is able to build on top of it, you can become a game changer.

16. Provide technical direction and advice

Your company often needs to cope with decisions with a huge, long-lasting impact. Choosing a technology stack. Choosing a cloud vendor. Making build vs buy decisions.

Even more often, smaller questions pop up: What would be the rough size of the project? Is it technically feasible? What are the possible solutions to this problem?

Become a go-to advisor for your team and the whole business. Learn the industry's landscape in-depth. Stay up-to-date with the newest developments and trends. Get good at research. It'll let you bring a lot of value to your company.

"But can I really do all of this as a developer?"

Can you really own subsystems, lead projects, or make build vs buy decisions? Isn't it the responsibility of architects, managers, and tech leads?

Yes, you can! In any well-run company, your manager or tech lead will be glad to delegate as much as possible to you. This is actually their job. It helps you grow and your team perform better, which are the most important responsibilities of a manager.

Some of the higher-impact stuff may indeed require more experience - nobody will let a junior straight out of a coding bootcamp own a mission-critical subsystem used by all the teams in the company. But all the impacts we discussed have a gradual progression.

Start with smaller initiatives, in your team, and successively expand the scope of your impact. Work with your lead or manager to find more growth opportunities. Be on the constant lookout for such opportunities yourself, in your team and across the company. Get noticed and build a reputation.

This will set you on a fast track to making bigger and bigger splash. To become not only 10x but even a 100x developer. And - if this is your ambition - to eventually become a tech lead yourself.

Bottom line

Yes, you need to be a solid developer. It's hard to be a multiplier for others while doing crappy work yourself. But don't sweat it if you are really 10x, or 5x, or just a solid 1x. Shift your mindset from personal efficiency to the effectiveness of the whole team and company. And when you do, only the sky (and your company's size) is the limit. You can become not only 10x dev, but even 100x and more.

😎 Are you a TRUE senior dev? 😎 Are you on the right track to becoming one? ➡️ CHECK MY ULTIMATE GUIDE TO FIND OUT. ⬅️

Your Job Is NOT to Write Code. Five Other Tech Skills Every Developer Must Master.

Wojciech Zawistowski — Tue, 07 Mar 2023 20:35:53 +0000

In a nutshell

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:

Software development is a team activity and most of the software is long-living. 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 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.
Humans are prone to mistakes. No matter how experienced you are, how rigorous is your process, and how clean and modular is your codebase, 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.
Modern software stacks are too complex to learn everything by heart. 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 just continuously write code without pausing to look stuff up.
Commercial software is built under tight time and resource constraints. Unless it's your personal hobby project, you'll be constantly struggling to balance cutting corners (to generate business value faster) and keeping the codebase healthy (to not cannibalize your long-term performance).
Understanding a new codebase quickly is a critical career skill. 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.

When you look at the above 5 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 MUST be skilled at

Exploring and understanding new codebases (a.k.a. code archaeology)

Mapping the lay of the land. "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.

Navigating and searching the code. 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.

Exploring the Git history. 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.

Exploratory testing and code inspection. 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.).

Debugging

Understanding the overall debugging principles and approaches. 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.

Debugging and inspecting the code. 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.

Interpreting and following error messages. 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.

Monitoring and logging. 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.

Reviewing code

Understanding the context. 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 what to focus on. 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.

Efficiently reviewing (and re-reviewing) the code. 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.

Collaborating with the author and other reviewers. 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.

BONUS: Making your pull requests easy to review. Writing great pull request 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.

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.

Working with legacy code

Understanding technical debt. 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.

Isolating legacy code and covering it with a safety net. 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.

Restructuring and refactoring the old code. 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.

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 also enhance your creation skills. And they are what screams "true senior" to your colleagues and managers.

💯 Are you a COMPLETE senior dev? 💯 Do you have all the skills to catapult your career to the next level? ➡️ CHECK MY ULTIMATE GUIDE TO FIND OUT. ⬅️