As teams grow, so does the surface area of code reviews—and the friction.
What starts as constructive collaboration often devolves into low-value comments, nitpicking, or opinionated back-and-forths that delay progress and breed frustration. And most of it stems from one issue:
Too many code reviews are about personal preferences, not shared standards.
Having seen code reviews in many variations – from small to massive teams, organisations with standards and companies with the wild-west code culture – below I write on what I think the code reviews should look like at any organisation with more then 2 developers.
✅ The Purpose of Code Review Isn’t Aesthetic Harmony
Let’s get this out of the way: your job in a code review is not to make the code look like you wrote it. When working with tens o r hundreds of engineers – this is not feasible. Your job is to:
Ensure correctness
Spot edge cases and security holes
Keep the code understandable and maintainable
Protect the team from tech debt or future surprises
Align with agreed-upon patterns and standards
Personal preferences—like single vs. double quotes, file order, variable naming conventions—should already be enforced by linters or conventions, not by humans on every PR.
If you find most of your comments on PRs are about style – it’s time to invest in a linter.
🧭 Preference vs. Principle: Know the Difference
Example:
❌ “I prefer to name this variable x instead of count.” ✅ “We usually name this count to stay consistent with our analytics events schema.”
The first is subjective. The second cites a shared standard. If it’s not grounded in an explicit team decision, it probably shouldn’t block the PR.
If it’s not yet a standard – but you think it should be – bring this up on your next sync.
🛠 Tools Handle the Mechanical, People Handle the Meaningful
If your code review feedback mostly covers formatting, rename suggestions, or how braces are aligned—it’s time to invest in automation:
Prettier / ESLint / Pint / Rector / Rubocop / Clippy (pick your stack) should eliminate 90% of bike-shedding.
Set up pre-commit hooks and CI checks to enforce this before code review even starts.
Code review time is expensive. Use it for architecture, logic, edge cases, and the stuff only humans catch.
🧱 Commenting Guidelines
Here’s a list of internal norms I’ve seen help reviews stay high-value and well-toned:
If it’s a preference, don’t block. Use “nit:” or “optional:” to indicate tone.
If it violates a standard, link to the standard.
If you’re not sure, ask a question instead of making a demand. e.g. “Curious if you considered X here—would that simplify things?”
Always encourage responding with reasons, not reactions:
Instead of “I disagree,” say “I’m worried this could make retries harder. What do you think about…?”
📚 Reviewers: You’re Not the Boss. You’re the Second Set of Eyes.
One of the biggest mindset shifts: you’re not managing the PR—you’re collaborating on it.
Engineers are expected to make decisions and defend them. That means:
If someone’s approach is valid but different from yours, that’s okay.
If it works, is safe, and aligns with company standards—ship it.
The best reviews respect ownership. Don’t rewrite their code—strengthen it.
🙌 Authors: Own the Quality, Don’t Outsource It
This isn’t one-sided. As a PR author, your job is to:
Write clear, well-scoped PRs with context (why this change matters)
Flag anything that’s fragile, temporary, or experimental
Review your own code before requesting review – Thank me later
Don’t use your reviewers as a safety net. Use them as a force multiplier.
🧩 One Team, One Voice
Every comment in a code review shapes culture. If your reviews are full of “I prefer…” or “we always do it this way…” without a shared baseline, the result is inconsistent, confusing, and political.
Instead:
Build a strong foundation of standards
Automate the boring stuff
Focus your human time on the things that actually matter
And leave your preferences at the door.
👴 Seniors: Be Humble, Stay Open
Code reviews aren’t just for junior engineers to learn or get checked—they’re an essential tool for everyone, no matter how senior you are.
Sometimes, senior devs fall into the trap of assuming their code is above critique or that reviews are just formalities. But:
Openness to feedback keeps your skills sharp and prevents blind spots.
It models humility and continuous learning for the whole team.
Fresh perspectives—even from juniors—can catch issues or suggest simpler solutions you might have missed.
It fosters psychological safety, showing the team that everyone’s code is on the table.
Remember, the goal isn’t to prove you’re right—it’s to build better software together.
✍️ Bonus: My Review Checklist
Business logic is correct and clearly readable
Introduces no unnecessary coupling or duplication
Follows naming and directory structure conventions
Leaves things better than it found them (if touched)
When driving for personal growth and working on ourselves, we often get tunnel vision on our hard skills – strictly related to our domain of knowledge – software engineers focus on design patterns, learning new languages and frameworks, designers spend time on staying up to date with latest trends, latest tools, color palletes – you get the idea.
All of the above is definitely important – there’s no professional success without having strong command of the core of your craft, however one thing we need to keep in mind is – most of the time designers and developers work as part of a team, and no matter how great you are at your craft – if you’re unable to communicate your ideas clearly – rarely will it lead to success.
Think of Bach – one of the greatest composers in history, let’s imagine he never learned how to write music – think how much of his brilliant work would be lost.
What is communication?
Though communication takes on many shapes and forms, in this article we’ll be focusing on the one that’s most used during work – verbal communication.
Words are powerful – how you choose them matters – they can make or break your projects, relationships, organisations – leading to great success or failure.
Think of words as compressed information – a single word can carry a deep meaning, a great idea, well beyond the sounds and characters used in it. Think of the word “home” – beyond just a physical space, it can carry emotional, psychological, and nostalgic weight. It can evoke feelings of safety, love, comfort, and belonging. In a literary or philosophical context, it can also represent the search for identity or a deeper sense of place in the world. All of this conveyed with 1 syllable.
A single word can also make a big difference in a sentence – think of the following sentences, that essentially mean the same thing, but carry different emotion:
“I don’t mind helping you” vs. “I don’t mind helping you out”
“I don’t mind helping you” is casual and indicates willingness, but it feels more like a neutral statement.
“I don’t mind helping you out” feels a bit more informal and friendly, adding a sense of support or camaraderie, as if the speaker is offering more than just assistance.
“You’re welcome” vs. “Anytime”
“You’re welcome” – a casual, neutral response – almost expected after you say “Thank you”
“Anytime” – Implies you do the favor not strictly out of necessity or obligation, but with personal care and motivation, showing readiness to do the same thing in future.
Given the above, we have to carefully think how we compress our thoughts and ideas into words – making sure we get our point across clearly. However, this is only half of communication.
What truly makes us great communicators though is listening. When listening or reading, we have to pay close attention to the subtleties of the sentences, the choice of words, to truly get the full context of the compressed information. We have to analyse it before reacting, as it’s often hard to grasp everything immediately. Delaying the reaction/response, reduces the chances of misinterpretation and potential misunderstanding.
Corruption / Interpretation – Finding the balance
If we think of verbal communication as compressing and decompressing information – we have to understand the goals and tradeoffs.
The idea behind compression and decompression, is to reduce the information to the minimal possible size during transfer, so it can be projected and received with a minimal effort. However, like in software, this comes with two challenges:
It takes significantly more effort (cognitive energy) to compress information to a compact size
Extensive compression results in information loss and/or corruption
Because of this we have to play a balancing act – it’s good to speak concisely, but we need to make sure we’re not leaving room for interpretation, as this will often results in misunderstanding (information corruption).
When we’re on the receiving end of highly compressed information, with interpretation possibilities – we have to make sure we exhaust all of them via follow up questions.
Especially in the work environment, when taking on or passing along important information/tasks, we have to make sure all of the communicated points are explicit, before we finalise the conversations. In practical settings, this is close to impossible – but we have to aim for the excellent, if we want good results.
Importance of communication in career growth & leadership
You can make communication what you choose on your career path – it can either be a major hurdle, holding you down or a big boost to accelerating you career growth.
This doesn’t only apply to leadership roles, this matters for individual contributors as well – you need to be able to build a network around you, in and outside of your work – you need to build trust and kinship to push you forward towards your goals. This is very hard to do with limited communication skills.
Imagine you’ve gathered loads of experience in your field and your employer now wants you to step in and share your experience with less experienced colleagues – if you have bad communication skills, you’ll have a hard time doing this – undermining your position as a senior professional.
Truth is – if you ever want to lead – be it in your personal or work life – you’ll need at the very least decent communication skills. If you are unable to project your competence, rarely will people come digging for it. And if people don’t recognize your competence – they will never follow you.
Written Communication Tips
In the era of remote work, written communication is becoming more and more frequent – thus important. No matter if you use, email, slack, teams, discord – there’s multiple things you should keep in mind.
Get to the point
written communication is slow, you throw in teammates in multiple timezones and you can be waiting for hours before your colleague wakes up.
Don’t start of your conversations with “Hey, how are you” and wait for a response. This doesn’t mean you shouldn’t say hi – this means you should send your intent with the initial message – “Hey, how are you? Can you please send over the invoices from last month?” – this way you can get your answer when you’re colleague is awake, and not risk another waiting cycle of your work hours overlapping.
Format it well
when sending messages with a big chunk of information, make sure you format it well – use paragraphs, lists, quotes, text styling bold/underline to draw attention to important details. In my experience, this speeds up the response times – which, I believe is expected – honestly, no one wants to read your 2000 word paragraph in all lowercase.
Whitespace & Headers
Give your messages some breathing room, don’t cram topics together – instead use headers and insert whitespace between them. We often have to go back to messages after reading them – don’t force the reader to read everything from scratch – make topics and key points easy to find with a glance.
Keep your sentences short
In an era of ever declining human attention span – keep your sentences short to make reading them simpler. Otherwise, you risk losing the attention of the reader or them having a hard time (mis)understanding your intent. This is something I struggle with often, but the tip below helps.
Read before you send
Making reading what you wrote before sending your routine. This forces you into the shoes of the person receiving this message and gives you a better picture of how well formed and readable it is. This can have multiple benefits:
Might show you that you’re not communicate one or the other point clearly
Might show that you left room for interpretation – needing to clarify it more
You might have missed a point you wanted to include
You might have typed Pubic instead of Public – don’t ask me how I know
Maybe you did it perfect from the first try – good on you – but better safe then sorry. Last thing you want to be doing is misinforming a stakeholder because your mind wandered when you were typing and now you have to reexplain everything, wasting everyones time.
When in need – get on a call
There are many things you can get across with a message, but it’s good to keep in mind that a call is an option.
If you find yourself struggling to explain or understand something in a 100 message long thread, it’s probably late – but better late then never – jump on a call.
I can already feel the “this could have been an email” club objecting to this, but it cuts both ways – there are 30 minute meetings that could have been an email and there are 200 message threads somewhere in your workspace, that could have been done in a 5 minute call.
Don’t choose a club – use whatever is best for the exact situation.
You remember that one student at your Uni, that was great at public speaking? I promise following the above tips will make you stand out in a similar way in written conversations.
How to improve your communication skills
Alright Irakli, we get it, we need to work on communication, but how?
I hear you.
First of – you need to start working on it pro-actively. Don’t sit and wait around for things to improve themselves. This is the biggest step you can take.
Once you decide that you take on this challenge, do a few or all of the things listed below:
Build your vocabulary
Simplicity is brilliant – though not always possible. As you grow, the complexity of the issues you have to face will only increase, so deconstructing and compressing these topics into simple words will become tougher.
To make sure this doesn’t hinder your progress, you have to be ready. Couple of things you can do to build your vocabulary:
Read – articles, essays, technical documentation – ideally related to your knowledge domain
Listen to podcasts – they are a great way to both engage intellectually and passively pickup new words
Watch – ideally documentaries or lectures
Remember, investing in tools is always a good idea – you better have them and never use them, rather then vice versa.
Analyse the greats
Have some favorite people you like to read or listen to? Have you ever thought what makes them your favorite?
Sit down and analyse how they communicate, how they structure their sentences, how they punctuate, how they approach difficult/sensitive topics. Try to understand what it is that makes them stand out.
Personally, I have two favorite categories – writers and standup comedians, whom I consider masterminds of communication – there’s a lot to be learned from the greats here.
Engage in discussions
Once you start picking up new words by reading and listening, you need to make sure you incorporate them in your vocabulary – usage translates into fluency – you’ll no longer have to look for words – with practice, it will come natural.
In and out of work – engage in more discussions, speak your mind and listen to what others have to say.
Write – Read – Write
Write for fun – start a journal, a blog, write a nice invitation card for your birthday party – just write.
Read what you wrote – analyse what you can improve and write again.
Looking back at your output, will let you notice the weak and strong points in your communication – which is hard to do during actual engagement, when you’re focusing on the outcome and not the means themselves.
Bonus: Cross Domain communication – talk in THEIR language
There’s another point to being a great communicator that I couldn’t fit anywhere above. It’s excelling in cross domain communication.
When communicating with a person, you always have to consider their knowledge domain and context and try to talk in their language.
Do your homework – get to know their “lingo” and try to understand what is important for them. This will allow you to communicate with them as an insider and remove the cross domain barrier.
Being a kid at the end of the millenium was a true gift, especially for a kid obsessed with math and machines. There was so much innovation happening and all of it was tangible – phones, cameras, players, gaming consoles, computers – so much stuff to explore, so much stuff to play with.
First obsession were phones as they were most common – I’d “confiscate” phones from all the family friends who’d come by and dig through them – do all the fun stuff: create and change ringtones, “wallpapers”, go through settings, see what I could break, finding games was the cherry on top – though not a lot of phones had them at the time – bummer.
This went on until I went to primary school and saw my first computer at my English class – absolutely stunning – you could play music, you could draw, you could even create cool looking words in a document (wordart) – an absolute banger! I was hooked. I wanted in. So my brother and I agreed we’d get one, no matter what it took.
For the best part of the the next year, we did our best to save up and at the end of summer, we got our first computer – a Pentium 4 with 32MB video card and 128MB of Ram – a true beast.
“Broke” it on the first day – it went really easy – started digging through all items in the “start” menu, switching wallpapers, playing minesweeper, going through program files, running and deleting things to see what would happen, including in the windows folder…… oops.
It wasn’t fun telling our parents – but end of the day – it was good. When you know how to break things, it makes you better at knowing how NOT to break them – so knowing the “disaster” I had caused was easily resolved with reinstalling windows – gave me confidence in trying other things.
I’d say I was a natural, but I feel with the number of hours I spent in front of the screen, you could turn a shy squirrel into the next Steve Jobs – so let’s say it was just practice.
I quickly became “the computer guy” at my school – teachers need help with excel? got your back. Need a new computer set up? no problem. Someone needs to setup a small stage for the visit of the US ambassador and a presentation? say no more [yes, I actually did that – trying to find pictures somewhere now].
Chapter 2 – The internet
There’s only so much you can learn and do on windows 98, without having no place to go for information. So my knowledge stagnated a little until I finally got access to the internet. This was already at Windows XP times.
It was mind blowing, there was so much information. At the time I really enjoyed gaming and wanted to know how the games were made. I always found myself enjoying the creative process in anything I did – more then the results, something that I hold true even today – I sternly believe the only true satisfaction comes from creation and not consumption.
First complex things I tried to create were maps in Counter Strike, it was fun but got boring quickly, as I couldn’t get anyone to play them.
Next up – I came across some tutorials on Java, so I built couple of cool calculators with a twist – they were in Georgian – which I considered a complete win as at the time almost no software was available in Georgian.
This was around the same time Piczo was getting popular – this is were I first meddled with “web development”. It was fun, easy and intuitive, I was hooked once again, though piczo was pretty limiting so got boring pretty quickly as well.
Piracy was big at this time and I’d read on forums that “warez” websites were making good money with ad placements – and it clicked – I was going to be a software piracy tycoon – spoiler alert – I’m not Kim Dotcom.
I briefed 3 of my best friends about the master plan – I’d build the website – they’d help me with content uploads – it was a no brainer – they were in.
Mekvle.com – was born [link goes to wayback machine] – and don’t ask me how and why we chose this absolutely hilarious name (in Georgian). We cheeped in couple dollars each, bought the domain, some shared hosting and we were ready to roll.
Long story short – we made 10 USD in about 6 months of working part time and when it was time to cash out – turned out the ad platform was a scam. Not funny, but lesson learned. So we ended up with colossal net loss of about 30 USD and hundreds of hours we could have spent playing football. Obviously, this couldn’t be further from truth – we learned a lot.
This was the first time I developed something with actual users and managed an actual team. By no means a technological marvel – using DataLifeEngine(CutePHP), deployed on some shared hosting. Nor was the team an exemplary institution. Regardless, we were serving up to 1000 users per day and getting cool guy points at school. I still hold pride for this project. I was 14 at the time.
Chapter 3 – Education & Freelancing
From that point on the life path seemed very straightforward – I loved computers, I was REALLY good at math (got a perfect 100% score at the Georgian equivalent of SATs) – so I had to study engineering – right? no.
Even though I really wanted to pursue computer science – there was only one good school in Georgia – and it was expensive. No way me/my family could afford it. So I had to choose something else – wasn’t happy about this but had no choice. I chose to study economics – I was the numbers guy – “you’ll enjoy economics” – right? no.
I got into the business and economics university as the top rated student in the whole country – met with the president of Georgia, did a newspaper interview – that kind of a thing.
Try to guess my GPA at the end of the first year – 4? 3.5? nope. 1.3 – turns out, just because you like math, doesn’t mean you’ll enjoy economics – I hated it, so decided early on, that I’d instead find work and do the bare minimum to pass the classes, so I wouldn’t “waste my time”. Looking back, after I’ve actually learned what I was “learning” during my bachelors – I realise, economics itself is very interesting – it was just the course that I was in was really outdated, and I honestly don’t regret not spending more time there.
End of day – I did go back to university after my bachelors and got an MBA, where I actually dedicated myself to studying well, as the professors and courses themselves were much more interesting.
During the studies, I worked multiple jobs and started a small business – https://kartvelitours.com – which I built with 0 capital. Used my tech skills to build a nice website with GREAT seo, which didn’t really have much competition at the time, so Kartveli Tours quickly became one of the most well known travel agencies in Georgia for the time. For couple years, we were in top 3 on TripAdvisor – proud of it still. It was at this point that I decided that this business had to be an actual business and work without my involvement, so I started stepping away and got a temporary digital marketing job – SMM/SMM/SEO in finance.
At the same time, I was taking on freelancing projects, mostly doing wordpress websites for small businesses in and out of Georgia.
Chapter 4 – Covid & After
Then covid hit, and most everything, my life got turned upside down – travel business died overnight. Which meant I had to come up with something to do full time. So I decided to find a job, I panicked a little, and started applying to any job that was remotely close to my skills – for couple months, I was working as a graphic designer, to keep things rolling, until I’d land a better job. I also started applying to development jobs – something I thought I’d never do, as I never considered myself a good developer, it went surprisingly fast and I landed my first full time job as a developer – it was chaotic.
I worked at a small company as the only developer – keeping multiple e-commerce websites alive, automating price changes, stocks, at the same time creating websites for new businesses the company was trying to pursue. Eventually hiring couple more developers, so I went from developer 1 to somewhat of a lead developer / product owner – deciding what to work on and when, as well as actually getting my hands dirty. This was a great opportunity as it forced me to work on across multiple frameworks, languages and business domains, forming a framework agnostic problem solving approach in me.
Next, I move to a big startup – the move was really unorthodox – having all this experience, I had still never worked at a big tech company – but I knew this was an opportunity to improve my growth trajectory, I had to get more foot in the door – I applied for a JUNIOR developer position, I thought I failed the interview – I couldn’t find the right words for anything, even though I solved all the challenges, I had a hard time communicating my solutions – as “I didn’t speak the lingo” of big tech. Turns out the interview was a success – I got the job, and an improved rating of IC2.
Didn’t last long though – in a month, as I settled in the team and gained my confidence, I was promoted to a team lead. Project was very interesting, working with a team of almost 100 people comes with unique set of challenges.
After spending a year at the startup, I was approached with an opportunity I couldn’t resist. A completely new business domain, an opportunity to build a product from ground up, as well as the opportunity to build the team.
Fast forward to now – still at the company – went from 0 to millions of users (in double digits 😉), multiple mobile apps, one of them in top 100 in US, millions of downloads, billions of requests, scale like I had never seen before now being the daily routine – has pushed me to learn and grow at an exponential rate.
Chapter 5 – 2025 & trying new things
It’s January 1st and the yearly reminder to do something new pops up on my phone, this time – I’m ready. 2025 is the year I start pursuing another one of my passions – writing & interacting with people. This marks the start line for ThinkScale – the blog you’re reading this on – starting here and now. It’s time to say “Hello World!” again – now in completely different context.
This is where I’ll share my mistakes, lessons learned, and thoughts on topics like:
Career advice for the newcomers in the industry
Designing systems that scale efficiently and reliably
Leading engineering teams through growth
Applying business strategy to technical decision-making
Making hard decisions, weighing dilemmas
I don’t promise frequent updates, but when I do put out something – I promise it will be worthwhile.
