Originally published at dmitryshvetsov.com on March 25, 2021.
Illustration by Anton Lapin
What is the route to becoming a strong programmer? Answers from programmers from Facebook, Amazon, Microsoft and more.
How would it change your programming if you could learn how other programmers have become strong, how they solve problems, and what tools they are using?
For me it all started with the idea of inheriting the experience of programmers within my circle. I asked my friends and former colleagues whom they consider to be strong programmers, then I made a list, prepared some questions and started asking!
I didn’t want to limit myself to this circle so I included the question “which programmers do you consider to be “strong?”, and then asked them to introduce me to these programmers. This approach worked brilliantly! I was lucky enough to get answers from and talk personally with people I had always dreamed of talking to.
Although the title includes companies with big names, I did not aim to ask programmers only from well-known “top” companies. I found that valuable advice came equally from people working in regional companies.
On this page, you will come across some rare nuggets of wisdom, as well as the mundane things that make a strong programmer strong.
How to read this article
In the text you will find [My Thoughts] in italics. These are the places where I share my thoughts in addition to the answers.
“Quotes are given in this style” - Dmitry Shvetsov
In square brackets [like these] I supplement the quotes with my own words so that the meaning is clear. Many quotes taken out of context are difficult to understand in the way that the author intended.
The rest of the text is the distilled answers and thoughts of the heroes of this article. In most cases I have used the original words and my job here is only to summarize and highlight the most important.
Therefore, I want to say a huge thank you to everyone who agreed to share their path in programming. A list of them is at the very end of this article. Some wished to remain anonymous.
What makes the difference between a mediocre programmer and a strong one?
Strong programmers started early in high school. Twenty years back, information was lacking, and it was necessary to program a lot to become proficient. This was the case for Denis Bazhenov, Dmitry Fedorenko and another developer who worked for FAANG companies.
The complexity of modern development is such that now the developer’s toolkit is huge and it continues to grow and become more complex. There is a lot to know.
“The volume of knowledge in the industry is growing, but people have the same time available, and this is not their fault” - Denis Bazhenov
Strong programmers love to dig deeper through the programming language into the platform and down into the hardware, disassembling the code piece by piece, going down and down the layers of abstraction, from the software layer to the hardware.
When the program does not work as expected (and this happens all the time) the ability to debug allows you to move at a steady speed, despite the constant tendency of systems to become more complex.
When a programmer needs to look at a program not from the point of view of the programmer, but from the point of view of the language, the ability to use a debugger on the one hand, and the operating system and diagnostic tools on the other hand, will be indispensable. It will allow you to see the big picture, like what files are open, what is happening in memory, what is going on in the CPU, and what packets are moving across the network. Knowledge of DevOps helps in this regard.
If you are a backend developer then learn the operating systems! Get to know C and C++ languages, in which most of the system applications are written. If you are a Java developer, learn the JVM and the standard library. If you write OOP, make sure you understand OOP. This forms a profound depth of knowledge and helps to write meaningful and high performant code. If you are using a database, go further than learning its query language; figure out how it works inside. This will aid in design, awareness of bottlenecks, and debugging.
Strong programmers don't take facts for granted. They ask the questions "why is this so?" It's great if there is a colleague who has an answer, but their absence does not stop a strong programmer, who is driven by curiosity.
Curiosity leads deeper. If something doesn’t work as you expect, or you’re just wondering how this or that function works, you look into its source code, then get deeper, even further from the application layer, descending to the level below. This knowledge gives an outlook to help solve complex problems.
It's important to be proficient in patterns. This is how Anton Kireev from Avito explains it.
“Programming is like playing chess. You cannot sit down and start playing chess by learning only how the pieces move. Of course, there will be people who can do this, but in most cases these are the people who can multiply huge numbers in their minds but cannot even put their pants on without help. The funny thing is, chess is patterns that your brain won't see at first. That is why it is recommended to start with small drills rather than the full game for the first year, so that the current state of a game seeps into your subconscious, and moves become reflexes. Then you can engage in strategy with ease. Without practice, neural connections will not develop in the brain, and you will not be able to freely see and apply patterns to the task that you are facing and to the code that you see."
Strong programmers prioritize business, not code, and this changes the way they approach problem-solving and technology choices.
Moving from an engineering mindset to a product one is a step to become more efficient. We must put business at the forefront, explains Ruslan Torobaev from ok.ru.
“Choose effective solutions. Even if they are not always the best, they are faster to make and easier to throw away” - Ruslan Torobaev
When developing large products, you often have to throw away your work. Development through experiments and small steps helps to negate this problem.
“Experiment more - go in small steps” - Ruslan Torobaev
A frequent piece of advice from strong programmers is not to get hooked on “hype” technologies if you are a product programmer. New technologies with exciting success stories are often the same: “they took top-end hardware, new technology, and got a dizzying result”.
The stories of failures are much more interesting, says Ruslan, as they allow you to find out where the technology cannot be applied, in which cases it does not solve the problem, and what bugs it has.
Strong programmers are pragmatic. You don't always need an elegant solution, written about in books or talked about at conferences.
From Ruslan's experience, it often happens that a prototype that gets to production will work unchanged for many months.
At the start of his career, Vlad Popov, an architect from Kinaxis, spent two years using a PHP script with one class of 25 lines as a backend for Flash projects.
Strong programmers are distinguished by the ability to solve situations that block progress on a task. They are not afraid to ask colleagues questions and ask for help.
Ruslan says that psychological moments play a big role.
Personal life problems immediately lead to a drawdown at work. Therefore, balance in life outside of work is as important to a career as the work itself.
[My thoughts] Health, relationships and financial security are the foundation for everything else.
Another point in psychology is that strong programmers are not afraid to change someone else's code. This is often the case when a programmer starts working on a new project.
"Don't be afraid to change someone else's code." - Ruslan Torobaev
You have to understand that the code was written before you, by programmers like you who were solving a local problem, and had local knowledge about the system and the product.
Self-confidence is another psychological trait of a strong programmer that has helped Vlad.
When you are sure that you are a strong programmer, regardless of experience, it helps in interviews, communication, writing code and commenting in code reviews.
[My thoughts] I have moments when I doubt whether I made the right decision. Such doubts use up a lot of "mental fuel", which we have in limited quantities for the day.
Write projects to gain confidence. Lots of projects. Build your portfolio and make it public. What was a few nights of programming for you will result in a "wow, did you write this?" response. This is the effect of public portfolios.
[My thoughts] I got into my first serious company thanks to a portfolio of one project.
Six out of eleven programmers who gave answers for this article have a noticeable modesty (in my opinion).
“I developed the habit of considering myself as not being smarter than the rest, so there were a lot of people who could correct me. It doesn't matter if it’s a junior developer or Linus Torvalds. Anyone can teach me something." - Anton Kireev
Despite being well paid, it is not programmers who bring money into the business. The fact that you get paid more than many of your colleagues can lead to arrogance. This could cause problems, Ruslan warns. Arrogance only gets in the way.
[My thoughts] We don't make money personally, but we could lose $460 million in 45 minutes. Here is the story of how the largest US stock trader went bankrupt due to a dead piece of code.
All of the above is brought together by a love for what you do and the desire to not work alone.
What is the path to becoming a strong programmer?
“Do what you love, love what you do” - common sense
[My thoughts] Below are many ways to grow into a strong programmer. Some advice will be contradictory, and that's okay. There is no single approach. Everyone has their own path. It’s important to choose the one that you will enjoy.
Work in the field of information technology (IT) is a constant race for knowledge. The systems that we as programmers most often work on tend to become more complex, with growing layers of abstraction over abstractions, and the integration of everything with everything else. Solving problems in such an industry always requires more knowledge than you have now. You are constantly learning something new.
Searching for imposter syndrome
“If you're the smartest person in the room, you're in the wrong room” – Confucius
Your goal is to get into a strong team. When you find yourself in a strong environment, it motivates you to rise to the level of the environment.
[My thoughts] Considering joining a company with a strong engineering team is a good way to find your next job.
“Seek to work with people who know more than you in any area, watch how they work and learn.” - Dmitry Fedorenko
Try to work at the best company you can find. If you can't do that, practice and get really strong with fundamental concepts. There are many resources these days such as online courses, YouTube and open -source projects. [More about self-development is included later.]
Avoid teams and companies with a toxic atmosphere. It is hard to learn and grow in such environments.
If you don’t feel that you are constantly learning, then it's time to think about changing your project or employer. If you do not grow, it hurts you and your colleagues.
“New environments equal new knowledge” - Ruslan Torobaev
Feedback is a requirement for personal growth. It's harder to grow without feedback. If you don't receive feedback, ask for it.
[My Thoughts] 1:1 is an indispensable tool for sharing feedback both from leadership roles to developers and from developers to leadership roles.
A lot of time will have to be spent on training and if you don’t enjoy the process it will feel like really hard work.
If you are interested in programming and you are ready to spend weekends and evenings on it, doing something for fun or coding for free, then most likely you will turn out to be a good programmer. And vice versa - rarely do those who sit at work from 9 to 5 and don’t practice outside of it as a hobby become top or even average specialists.
“It is difficult to be successful in IT if you come there for money and hype. It must be a calling." - Dmitry Fedorenko
A good place to start is a position of a web developer in a web studio. This is often а place where the juices are squeezed out of you, but they take junior developers with basic skills, teach them, give them a range of experience, and build in them a habit of finishing their tasks within estimated time. These are all important skills.
“Simple question - will you program if you won’t get paid for it? If not, then my path is not for you" - Dmitry Fedorenko
Choosing a company is difficult. Getting a job in a “top” company is a lottery. You can end up in the wrong project, or with the wrong leader, or a weak team.
[My thoughts] It's a little easier in smaller companies, especially with international ones. Through glassdoor.com and teamblind.com/company, you can read reviews from former and current employees. Let me emphasize again that this approach does not work for large companies. But if you can find contacts of current employees and communicate in an informal setting, you could find out if the company has what you are looking for.
Where there are challenging tasks, there are strong teammates
“No pressure, no diamonds.” – Thomas Carlyle
Start participating in large, technically complex (not to be confused with logically complex) projects and / or participate in internship programs for “top” tech companies as early as possible.
The path to strong programmers is through challenging tasks. This is often the complement to strong colleagues. Where difficult tasks exist, there are strong colleagues.
An ideal situation would be to get yourself into a strong team where you can be mentored and have help available in case of difficult problems.
[My Thoughts] I noticed how much my colleagues and I grew when we were working to tight deadlines on a challenging task. Those times when you have no choice but to learn how to solve a problem at hand here and now. At such moments, you really turn on to the fullest. And when the task is completed, you feel that you are head and shoulders above who you were yesterday.
Look for projects and challenges, and get out of your comfort zone if you feel like doing routine tasks all the time. If you cannot find challenging tasks - change your project or team. Changing jobs is another way to get out of your comfort zone and into a place of growth.
[My thoughts] Don't expect every task to be challenging and interesting. Routine will be necessary. It is within your power to make the task more interesting. For example you can hone your skills like an athlete to get your routines faster and better, or automate a routine task and learn something.
Follow your interests. Choose a company where working on the product will be super interesting for you and focus more on the industry or domain and less on the technologies.
[My Thoughts] In the long run, an interesting job may be more important than a pay rise now.
Self-development
“Without great teammates, it is difficult to engage in self-development” - Ruslan Torobaev
You can find smart people outside of the workplace.
Open-source is the most accessible source of the very best programmers who will “show” their code, their tricks and give feedback on your code. It is impossible not to use this opportunity in the absence of strong colleagues. Open-source is a source of knowledge and new acquaintances.
Read a lot of code. Open the library you are using and just read it through.
“Every solution is a pattern that I have been solving for eleven years, and which has been replenished with knowledge on questions like "how Google works", how this works, how that works." - Anton Kireev
Vlad Popov discusses a common threat, modern programmers writing non-idiomatic code that does not match the libraries used in the project. Take a look inside the libraries you are using, figure out how they are written and use this knowledge to write better code.
Vlad believes that he has been helped by the habit of trying all experimental technologies as soon as they appear. That way you can become an experienced specialist in successful technology.
[My thoughts] He was one of those who stoked up for Node.JS even before the first version, and used Vue.js in production seven years ago, when the framework was not yet so popular. Now he is an expert in both.
On the other hand Denis Bazhenov believes that it is necessary to keep the size of the stack small, not letting it grow. Don't chase every technology that is popular today. Use the time that frees up to study your stack in depth.
It’s often the case that “top” companies require deep knowledge of the language and platform, whereas novice programmers often study frameworks and libraries.
Anton Kireev laid out the idea of teaching programming by copying others in comparison with learning to play the guitar as follows.
“You can watch tabs [tablature - chord notation for guitarists] of other people's cool songs, like the code of cool programmers, and extract patterns by repeating them in your work. But by repeating "songs" of other performers you will not learn to play a Spanish piece. To play something like that, you need someone to teach you how to sit, the correct position of the hands, the correct clamp. Why is it important? Because with the right technique, you will get a better sound and fatigue less.”
Sources of self-development by Vadim Tsesko, developer from odnoklasniki.ru:
- reading academic articles
- tech books
- conference talks
- participation in regular meetups and user groups
- online courses
- open-source projects, bugs / features, code review
Do not rely on learning only through courses and books. They will not help you go beyond the scope of the studied stack to the OS and network, where problems most often arise.
George Hotz, the developer of iOS jailbreaks and founder of vehicle automation machine learning project comma.ai said “you never learn to program by watching a video called “learn programming”.
“Books that will reveal to you the "secret of the whole world" do not exist. All the books I've read give me a maximum of 60% of the information I have." - Anton Kireev
[My thoughts] The rest is derived from personal experience and the experience of colleagues.
Anton Kireev recommends the books of Andrew Tanenbaum for development deep into the technological stack.
Reading documentation is another source of knowledge. There you can find information about how things work.
leetcode.com is the most recommended resource to get better at the basics of computer science.
Ruslan agrees that self-development is possible, but believes that a university will be a better choice. Programming requires a good foundation: higher mathematics, combinatorics, algebra, operating systems, networks, and knowledge of hardware. Without formal education it is more difficult to get this knowledge. Although it won’t stop you creating websites, this lack of knowledge will be a limiting factor.
Popov advises looking at features of new programming languages, which take into account the problems faced by previous generations of programmers.
To learn something new, you need to choose a programming language that will unsettle you, shares Bazhenov. It should be completely different from what you use on a daily basis. This approach will expand your arsenal.
It is equally important for growth to be open to criticism, considers one of the Facebook programmers.
[My Thoughts] The hardest part of the previous tip is to really pay attention to how you feel when you receive criticism, and make sure that your wounded pride does not cause you to shut yourself off from criticism. At this moment, the brain does not work rationally and you are playing defense. Learning to catch such moments and take advice is another important soft skill. One of my tools for introspection is to write a “day review” in my diary just before bed. I’ve picked up this tool from Stoic, philosopher, and Roman statesman Lucius Seneca.
Denis Bazhenov sees a big plus when programmers know about system administration and advises reading the Linux Performance blog by Netflix Senior Performance Architect Brendan Gregg.
For Java developers, Ruslan Torobaev advises an excellent resource: shipilev.net.
Pet projects
Denis Bazhenov believes that he was greatly helped by building a chat project for a university on which he worked with Dmitry Fedorenko.
It was often noted that it is better to work with someone on pet projects rather than alone. It is difficult to work on long projects as a single person. You will inevitably get bored at some point, and your enthusiasm may fizzle out. This happens less often when working in a team.
Vlad Popov undertook any proposal he was offered to work on projects. He never said no to a work opportunity, and was involved in many projects for no money at all, just for experience, interest, references and acquaintances.
“I constantly had a bunch of projects at the same time. I was hungry for them.” - Vlad Popov
[My thoughts] Four years ago we worked together on a project and he was looking for a library to solve a problem. “Dima, look” he said, “well written… that is clever… it’s cool too… hmm here I would write differently, but fine… I wonder who the author is?” He opens the project's config file, scrolls down and sees that he is the author.
Working on various projects helped Vlad to master his tech stack. Start 25 projects from scratch and you will make this process seamless!
Vadim Tsesko advises that you write - just for fun - your own implementation of various layers of the technological stack: boot file, kernel, network, data structures, library and framework. This will give a better understanding of the entire stack that programmers rely on every day.
Mentorship
“When the student is ready the teacher will appear. When the student is truly ready... the teacher will disappear.” – Tao Te Ching
A mentor can turn years of self-study into weeks, or months into days.
Vlad Popov didn't get the knowledge he wanted at a university. Instead, he went to study with a person who knew the technology he was interested in better than anyone else in his country. Denis Muraviev conducted an intensive course "Advanced Flash Programming", where after a few days, designers were able to write ActionScript code [a relative of ECMAScript].
“When they explained to me what classes are, I didn’t understand why they were needed, when you can write procedures instead” - Vlad Popov
Follow the coolest developers on Github and Twitter, and the Core developers in your stack.
Their examples of how to write good code will inspire you to keep growing and find extra time for your hobbies, to keep you moving forward.
[My Thoughts] The mentor need not necessarily know that they are your mentor. By reading their blog, Twitter, listening to podcasts and watching screencasts and videos on YouTube, you can learn a lot from the programmer. Vova Popov and I took over the previously popular TextMate editor and learned how to develop on the Ruby on Rails framework. Choose two or three of the strongest in your field, and read everything that they publish.
Denis Bazhenov himself is a mentor for young teammates. He shared what to look for when choosing a mentor:
- Make a preference for highly specialized ones who have been digging into their topic for a long time
- Avoid people who are critical in their thinking
- Choose someone who can talk not just about the pros but also the cons of the technology you want to learn
How can you be a good student for a mentor:
- Don't be indifferent, you should display an interest
- Doing anything outside 9 to 5 job, like open source, a pet project, or writing a blog
- Work on being more open to other people’s ideas
What if you're just starting out?
Novice programmers should get hands-on programming as much as possible. They should be able to follow the leader.
The goal is to be as useful as possible without constant questions and be able to solve a well-posed problem on your own.
The next step is to broaden your horizons. Code review, git, debugging, DevOps, problem solving [read about problem solving below]. Developing these domains will allow you to become self-sufficient.
What can help beginner programmers to realize their potential?
- Internship in teams with challenging tasks and experienced colleagues
- Drive
- Having their own ideas
- Open to criticism
- Ability to be led
How to find time for all this?
Nobody cancels the hard work.
“The threshold for entering programming and IT in general is high. You need to work hard for five to ten years to become an average specialist. We must make sure we plan regular “sweatshops” for ourselves.”- Dmitry Fedorenko
“Direct all free time to self-development” - Vadim Tsesko
Many have families and children. How to find time for at least some of the above?
The main secret is a strong inner desire. Do what you love, love what you do. You will always find time for something that makes you happy.
“I don’t know - it just happens!” - Anton Kireev
The tools of strong programmers
Dmitry Fedorenko uses the “Getting Things Done” practice.
Invest time in learning how to use debuggers. Debuggers are very helpful in quickly understanding what's going wrong. This will help in resolving bugs and in development when the code stops working the way you want it to.
Analytical debugging [the term is not mine, but from developers at JetBrains] is a way to ditch debuggers and think about what went wrong. The advantage of this approach is that you are more likely to find the sources of the problem rather than its symptoms. You have a growing general understanding of the project, and you can find accompanying bugs. The disadvantage of analytical debugging is that it is many times slower than using debuggers.
OS debugging tools that Denis Bazhenov uses include:
- strace
- ltrace
- pidstat
- tcpdump
- linux sar
- lsof
- vmstat
The advantage of these diagnostic tools is that they allow you to understand what is happening with the application, regardless of what language the application is written in.
Solve problems like a PRO
“The problems are all different, but they all boil down to the same tasks” - a programmer from JetBrains
There are no secrets in solving problems. Use decision theory and standard problem-solving approaches.
Notice patterns. The faster you identify them, the faster you will be able to solve problems.
The best approach to problem-solving is treating it as an optimization problem with some pretty tricky boundary conditions. Therefore, the most difficult part of this process is to choose the best solution.
Do not blindly believe the description of the problem. Before solving it, you need to understand it well. Find out exactly who needs it and why. This requires asking questions. In a third of cases, the task may disappear altogether, and in another third it may change greatly.
- Dmitry, make a green button here.
- No, first describe what problem you have? Why do you want a button? What will happen if we don’t do this?
This approach saves a great deal of energy. Often, before starting work, it turns out that you do not need a button, but a link, or text on the page, or you do not need to do anything at all. Better to spend time on conversation first, and then programming.
“Lack of requirements is a constant problem that I face.” - Dmitry Fedorenko
Break down complex problems into small manageable chunks, the details of which can easily fit in your head, and which you can complete in four hours.
“Small libraries are more useful than one big one. An ideal library is a library that you can write in four hours and forget about." - Vlad Popov
Big tasks take hours to dive into every time you start working on them. Avoid context switching - small tasks help with this.
Try to use first principles and think of the best way to solve a problem apart from constraints. Consider trade-offs between different solutions and bias towards simplicity.
Aim to assemble a minimum working prototype. Do not worry about quality or using the best tools like databases, queues, etc. Do it in a short time frame to see how the feature works and get feedback on it from users.
Look for the shortest path to a solution.
“When I was inexperienced, I wanted to do everything in the best possible way, and I would start out wanting to "build a bridge” thoroughly from one end to the other [implement full functionality first time around] But over time, I realized that such bridges end up in the wrong place. Therefore, with experience, I first "tread the path", making at least a working prototype, then, when (and if) this stuff somehow works, I begin to put meat on the bones [iterate towards a fuller functionality]. ." - a programmer from ok.ru
[My thoughts] When you have a ready-made good-enough solution, the deadlines are no longer pressing on you. Here you can make a decision to improve something, get feedback on the code, or save time for another task. Trying to make it sleek right away, I often ended up missing a deadline.
Consider the requirements and resources that you have. Some tasks require immersion in the subject area, while others are a waste of time.
Using analytics is useful for business, monitoring, debugging.
When you don't know how to solve a problem, make the simplest solution possible. Up to if a = some_value then return expected_result. You just need to start, and once you’ve solved the simplest case, select the next requirement and repeat, then continue like this.
Often tasks that you do not know how to solve are obviously solvable. The solution for them comes from an intensive search on the internet. The downside of this approach is that it takes a lot of time, days and weeks.
Tasks that you can’t solve now can be postponed for a couple of hours or until tomorrow. Fall asleep with a difficult task in mind - often the idea comes in the morning!
[My thoughts] This is due to the fact that our brain works in two modes, focused and diffused. Focused mode allows us to keep more complex details in our head. It's more about depth of knowledge. Whereas the diffuse mode is a creative work mode using the full breadth of our knowledge. New ideas come in diffuse mode, in which the brain works in the background. This explains the belief that ideas come in the shower.
A detailed breakdown of the approach to problem solving was shared by Vadim Tsesko:
- Collection of all requirements, immersion in the domain
- Thorough documentation (design doc) for subsequent retrospection of maintenance and development of the system
- Search and communication with colleagues with relevant experience in order to collect an exhaustive set of alternatives
- Study of existing solutions in the market, read relevant academic articles
- Analysis of the advantages and disadvantages of each of the solution options, choice of solution
- Iterative design review and gathering opinions from more experienced colleagues
- Important: so as not to become isolated and get stuck, proactively collect opinions, be open and tolerant of criticism, honestly weigh the pros and cons, and make decisions in an evidenced-based manner.
Tips from Denis Bazhenov:
- Conceptualize the task in terms of technical and business constraints, and under what conditions a solution will not work
- If the task is not demanding of resources, then develop a prototype through automated testing. It is easier to form a design and any flaws can be spotted earlier.
- If the task is technically complex or related to distributed systems, it is important to analyze what can fail, what steps need to be taken to make the system diagnosable, what we will do if parts of the system start to fail, how to eliminate failures and how to be on the safe side, for example collect special logs.
- When everything fits together then it comes to the programming, and an understanding should be reached of what modules the system should be divided into, and how to organize work.
- Consider making a prototype (maybe even without programming)
Advice on how to implement the decisions from by Ruslan Torobaev:
- Write unit tests if the task is large and it is not possible to keep all of its parts in your head.
- Use specialized logs for integration code. It’s not possible to cover everything with tests in integrations.
- For small components, test-driven development is useful. It helps to find flaws in the interface. If the component cannot be tested, you immediately understand that you need to change the interface.
It is important to be able to solve blocks while working on a task. Here’s how to approach it:
- Use internal knowledge base or documentation or external product documentation
- Get help from colleagues
- StackOverflow, Slack community channels, Discord, user groups, issues in a library or product repository, product channels.
- Look into the source code. For third party products you can fetch a Docker image, start debugging with breakpoints and see how the product works from the inside. Do this simultaneously with the first three actions!
More to come…
“Art is never finished, only abandoned.” — Leonardo da Vinci
By the time I came to publish this article, I had even more programmers on my list to talk to than when I started this project.
This page will be updated over time.
Subscribe to my newsletter now to find out when there will be more nuggets of wisdom and easy-to-forget simple rules added.
Heroes of this article
Many thanks to these people for their answers and for the great chat!
- Anton Kireev, programmer at Avito
- Denis Bazhenov, tech lead at Farpost
- Dmitry Fedorenko, CTO at 100sp.ru
- Roman Dmitrienko, team lead at drom.ru
- Ruslan Torobaev, team lead, at ok.ru
- Vadim Tsesko, programmer at ok.ru and educator
- Vlad Popov, architect at Kinaxis
And those who asked to remain anonymous:
- a programmer from Facebook
- an ex. Amazon, ex. Microsoft programmer
- a programmer from JetBrains
- a programmer from ok.ru
Top comments (0)