How to become a 10x developer

This are the notes from the talk I gave back when I was working as Startup House

I would like to begin with a small apology for a "clickbaity" title. For those of you who didn't hear this term before, it is a mythic developer that is as productive as 10 other people combined. Of course, apart from the very rare occasions, there is no such thing and I chose this title mostly to pick your interest 🙂

That being said, I strongly believe that every developer can achieve even more by being really good in this aspects of everyday work

• Communication (both verbal and written)
• Software architecture and pragmatic approach to development
• Code reviews
• Mentoring and knowledge sharing
• Miscellaneous

What you need to always keep in mind, is that you are not working alone. Almost all of you have either a project team, work with others inside the company or work with someone from the customer side. Because of that, you should be aware that at least some of your actions affect others and their work.

There are of course multiple things that you should take into account, but the most important one is communication both verbal and written.

Communication

Some of you may have already seen this graphic, it shows how much more possible lines of interaction appear with each additional person in the team. For me, it was eye-opening information that clearly shows how much emphasis we should put on this aspect of our work. But what are those aspects?

Let's start with the easiest one: documentation. Of course all of you are aware that we should create a project README, API specs, etc. but thinking about having a decision log or keeping track of all the small changes to your tasks is not that common. Just to give you a few examples:

• You decide to use some non-standard approach to the app architecture. Decision is made by 2 devs that are currently working on a project and because they know each other, the thinking behind this decision stays only in their heads. It's obvious. But if by an accident both will leave a project this knowledge will disappear and someone new will have a hard time understanding what is happening in the code and why
• You are working on some story from Jira. During the development of it, you find out that something can be improved or simplified. You shouldn't make this decision on your own, so you ask your PM for permission to apply this change. After finishing development you move it to code review, but it gets rejected cause it's not working as intended, so you explain the change. Later you will most probably need to do same explanation after rejection from QA
• Maybe not as important as 2 previous, but let's assume that you usually work from 9 to 17. People get accustomed to it and expect that you will be available during this time. But for some reason, you have to leave for a few hours during the day, or need to focus on something else and won't be responding to messages. Some people may get frustrated with it, cause they expect you to be available, but your not, and they don't know what is happening

This of course doesn't exhaust all the possible problems that might arise, but you get the point. So how should we solve them? It is quite easy, you should document everything! Especially in the remote-first environment. The first issue could be handled by preparing Architecture Decision Record, the second one can be handled by adding information as comments to a story and the final one should be solved by proper Slack status + information on team channel.

But there is also another side of the coin, verbal communication. In my opinion, this should be a backup option, when having a written conversation is too tedious. Why? Simple, it doesn't leave any trace or history that you can go back to, and even maybe make proper docs from it.

Still, if you are going to have a call with someone you should remember these things:

• Respect other person's time. Don't make ad hoc calls without asking and always take into account someone's focus slot in the calendar
• Keep in mind that people come from different cultures and backgrounds and what you are saying might offend them or at least make you look stupid in their eyes
• If you are making some decision on this call, make a note from it and post it to your project docs

TL;DR

• Keep in mind that good communication is complicated and it gets exponentially harder with bigger team size
• Having everything written down, solves at least some of those complications and enable everyone (even people that are not part of the project yet) to be "on the same page"
• Always think about other people, what they would like (and should) know. Also think about how your actions and words might affect their feelings and opinion about you

Pragmatic approach to development and software architecture

Programming is just a byproduct of the real goal of our jobs which is delivering value to our customers. It doesn't matter if you work in a software house, a product company or write code for your side project. There is always someone's problem that you are solving or value that you are delivering. Everything that you do in your everyday work should be aligned with those assumptions. Which lead us to the next big area where everyone can be good at - the Pragmatic approach to development and software architecture

Let's begin with the first rule: Best code is the one that you have never shipped. When you write some code, that you intend to ship, you need to remember about testing it, maintaining it in the future and potentially fixing bugs that will be caused by it. Because of that it is best to always think about what you create, is it needed and can it be simplified? Another thing that is somehow related to it is the urge to write everything from scratch or as they say "reinvent the wheel". Unless there is a really good reason not to pick an existing 3rd party solution or you know you will have time and resources to maintain your in-house solution, don't try to solve something that is already solved by the community.

What you should be always aware of is that probably every requirement and functionality will change sooner or later. This should have a big impact on your approach to the project architecture. What I mean by that is that you should always write a code that will be easy to change when needed. It can be achieved in 2 equally important ways

• Use correct design patterns when needed. This itself is a topic for another Software Craftsmanship Guild meeting, so for now I can point to 2 resources that I've found particularly interesting. Refactoring and Design Patterns and Patterns.dev
• Don't try to be too smart. I saw multiple times that at some point in dev career people tend to write fancy and smart code. It might be seen as a sort of "requirement" for more senior people to write it like that, but it's the other way around. Let's face it, the majority of issues that we solve don't require extreme performance optimizations or the usage of advanced algorithms. And when either you or someone less experienced will stumble upon this complicated fragment, it will require extra time and mental force to understand what is happening there instead of spending time on solving customer's need.

And lastly, don't try to create a perfect architecture and code. For some of you, it might sound counterintuitive. But let's summarize some facts. Most of our projects are for customers with either financial or time constraints or even both. They need to get the project to the first user, start validating it and earn the first money. End-user doesn't care how sophisticated your components or controllers are. What they care about is your applications solves their problem.

Of course, that doesn't mean that you should forget about all best practices, take huge tech debt and focus only on delivering new features! As with everything in life you should strike a balance here, between quality and speed. It requires some experience and trial and error to get a better feeling of this balance but it's doable.

TL;DR

• Our real job is solving customer problems and delivering value for the business
• Don't try to create a perfect architecture, especially for early stage customers
• Your code should be simple and easy to maintain

Education, mentoring and knowledge sharing

If you want to be good at your craft and keep it this way for a long time, you have to constantly educate yourself. The programming world is getting more broad and complicated each year. This is especially true for web development, where tools and best practices can change on a year to year basis.

At the beginning of a career people usually focus on stuff that is used every day, like frameworks, common tools and libraries. And this is fine when you are barely beginning and want to get started as fast as possible to gain some real-life experience. But with time you also need to get a very good understanding of the basics. As mentioned, things can change quite rapidly, but basic almost always stay the same. When you will have a good foundation and understanding of how all your tools work under the hood, you will have a lot easier time grasping new concepts and frameworks.

As they say: "You learn best by teaching", and I completely agree with this statement. If you need to explain some concept to someone else, you have to have a strong understanding of it. Otherwise, you will struggle to sound competent and knowledgeable. It doesn't matter if you write a blog post, confluence article or even prepare a whole workshop on the subject, each of these is fine depending on how much time you have. And not only you are going to improve your knowledge and teach someone, but you will also create lasting material that can be shared at any time!

Finally, try to become a mentor to someone less experienced. This also has multiple benefits, like:

• Helping others to grow in a structured and planned way
• Help spread the organizational culture
• You can learn something new from the other person
• You can find gaps in your own knowledge when trying to explain some concepts

TL;DR

• First of all, take care of your education and understanding of basic principles
• Try to prepare as many good-quality learning materials as your time allows to
• Be a mentor to someone less experienced

Miscellaneous

Finally, when you do your job, always remember that you are doing it on a team and you should treat others' time with the same respect as yours. What I mean is that you should be mindful of how your actions and decisions affect your colleagues' work and schedule. Just to give you a few examples

• When you finish some task, always test it as much as possible before moving it to the QA. If you won't do it, there will most probably be some bugs or inconstancies. You will waste QA time for things that you could find yourself and the entire process will take longer than needed. Task delivery might take a little longer on your side, but believe me, everyone will thank you for this attitude
• Always keep your PM in the loop. Doesn't matter if you need some additional time to finish a task, you won't change something, you will be absent for some time or you got a request from the customer. PM is the person responsible for delivering projects on time and budget so he or she should have access to as much information as possible to properly coordinate the work of an entire team.
• Be respectful to everyone's time schedule. If someone has "focus time" or "no appointment slot" in their calendar, don't force your meeting during that time. If some person works in a specific hours, don't call or expect slack answer after those hours. On the other hand, you should in one way or another inform others of your time for a deep work or when you won't be available for discussion