14
.
11
.
2023
21
.
04
.
2017
Ruby on Rails
Backend
Frontend
Business

Clean code for the win

Michał Piórkowski
Founder

Few days ago Tobias Pfeiffer came to Visuality and gave a really great talk about clean code. While listening to him I realised, how important it is to us and how it influences our clients. Code quality has always been a big thing in Visuality so its always nice to hear somebody else confirm what we do everyday here:)

Before I write anything more let me give you a small background information about myself - first of all, I'm not a programmer. I do have some experience in programming, but I would never call myself a professional. So when I listened to the talk I was more involved as a business person rather than programmer.

So what did I learn that was so darn interesting to me? Let's see:

1. Programmers read code way more often than write it

So this is kind-of a game changer to me, as a business person. When you think of it - that is so true. Very often code is written in a way as if it will not be read by anyone. Just to make a product, without ever considering that at some point somebody will have to dig in to the code and change/upgrade it

WTF/minute as code quality description

2. Good code base is way more important than you think

Very often I see this attitude: "please just make it work, I need it for my investors and I need it ASAP". I respect and get that but we all (as startup/product owners) should know that it will not get us far. Writing bad quality code just for speed will cost you twice as much. Because first you will pay for the bad "just working code" and then, after a year or so you will pay for revamping it. And its not only about money - believe me, good programmers that you would like to work for you will probably not be excited about revamping a frankenstein/spaghetti code:( As a result writing bad code will not speed anything up and will make your future way more difficult.

3. Good base is not enough, you need to nurture it

Even if you have good code base it does not mean it's over. You still need to spent some time nurturing it, upgrading libraries and making sure its meeting your quality standards all the time (tools like Coditsu or CodeClimate definitely help in that matter). Without nurturing it, there is no sense in making it good in the first place, as the result may be similar.

4. Write simple, readable code

I know I'm kinda repeating point one but this is actually the most important thing. Tobias was stressing that programmers should write code that does not need unnecessary comments and that is understandable just by reading it. That means good naming and well-thought structure that conveys all the necessary info (including business logic).

5. Refactor whenever you have a chance.

This point I liked particularly. Naturally nobody can spend indefinite amount of time on refactoring so the idea is to refactor any code that we touch (if there is an actual need for it). This way we spend just 5-10% time more and at the same time the code gets better every time we look at it:)

So how does it change/influence your product you might ask?

So at Visuality clean code and its highest quality is one of our main goals. Every time we approach a project we think of a solid implementation plan. We never try to rush too much, as we know that taking some time to think about what we'll write will eventually save our clients time and money. Also we never have problems whenever we need to change something big or add another person to the team. A well build code-base allows us to expand the project in a way that we want, without thinking about rewriting anything. Another thing that is extremely helpful and is somehow connected to good code quality is test coverage. The better the test coverage, the less time we need to spend on testing the product anytime we change something. Most of the people tend to omit this part because at the beginning their project is simple and they know they can test it within minutes. But then when it grows, and client base is larger it is purely impossible to test the product thoroughly every time we add a new feature. So the little time spend at the beginning will save a lot of effort in the future - that seems like a smart kind of investment to us:)

Summary

To sum up - the main idea I would like you to remember after reading this article is following: If you want your product to grow without problems and you would like to attract good talent to work on its development you definitely need to pay attention to all those little details. Otherwise you will get a mediocre product that will be impossible to develop within a year - and nobody wants that:)

And if you'd like to see Tobias presentation it is available here: https://speakerdeck.com/pragtob/optimizing-for-readability

At this point i'd also like to thank him for taking the time and showing us that we're not alone in the pursuit of best quality code:)

Michał Piórkowski
Founder

Check my Twitter

Check my Linkedin

Did you like it? 

Sign up To VIsuality newsletter

READ ALSO

LLM Embeddings in Ruby - Paweł Strzałkowski

LLM Embeddings in Ruby

17
.
03
.
2024
Paweł Strzałkowski
Ruby
LLM
Embeddings
ChatGPT
Ollama
Handling Errors in Concurrent Ruby, Michał Łęcicki

Handling Errors in Concurrent Ruby

14
.
11
.
2023
Michał Łęcicki
Ruby
Ruby on Rails
Tutorial
Recap of Friendly.rb 2024 conference

Insights and Inspiration from Friendly.rb: A Ruby Conference Recap

02
.
10
.
2024
Kaja Witek
Conferences
Ruby on Rails

Covering indexes - Postgres Stories

14
.
11
.
2023
Jarosław Kowalewski
Ruby on Rails
Postgresql
Backend
Ula Sołogub - SQL Injection in Ruby on Rails

The Deadly Sins in RoR security - SQL Injection

14
.
11
.
2023
Urszula Sołogub
Backend
Ruby on Rails
Software
Michal - Highlights from Ruby Unconf 2024

Highlights from Ruby Unconf 2024

14
.
11
.
2023
Michał Łęcicki
Conferences
Visuality
Cezary Kłos - Optimizing Cloud Infrastructure by $40 000 Annually

Optimizing Cloud Infrastructure by $40 000 Annually

14
.
11
.
2023
Cezary Kłos
Backend
Ruby on Rails

Smooth Concurrent Updates with Hotwire Stimulus

14
.
11
.
2023
Michał Łęcicki
Hotwire
Ruby on Rails
Software
Tutorial

Freelancers vs Software house

02
.
10
.
2024
Michał Krochecki
Visuality
Business

Table partitioning in Rails, part 2 - Postgres Stories

14
.
11
.
2023
Jarosław Kowalewski
Backend
Postgresql
Ruby on Rails

N+1 in Ruby on Rails

14
.
11
.
2023
Katarzyna Melon-Markowska
Ruby on Rails
Ruby
Backend

Turbo Streams and current user

29
.
11
.
2023
Mateusz Bilski
Hotwire
Ruby on Rails
Backend
Frontend

Showing progress of background jobs with Turbo

14
.
11
.
2023
Michał Łęcicki
Ruby on Rails
Ruby
Hotwire
Frontend
Backend

Table partitioning in Rails, part 1 - Postgres Stories

14
.
11
.
2023
Jarosław Kowalewski
Postgresql
Backend
Ruby on Rails

Table partitioning types - Postgres Stories

14
.
11
.
2023
Jarosław Kowalewski
Postgresql
Backend

Indexing partitioned table - Postgres Stories

14
.
11
.
2023
Jarosław Kowalewski
Backend
Postgresql
SQL Views in Ruby on Rails

SQL views in Ruby on Rails

14
.
11
.
2023
Jan Grela
Backend
Ruby
Ruby on Rails
Postgresql
Design your bathroom in React

Design your bathroom in React

14
.
11
.
2023
Bartosz Bazański
Frontend
React
Lazy Attributes in Ruby - Krzysztof Wawer

Lazy attributes in Ruby

14
.
11
.
2023
Krzysztof Wawer
Ruby
Software

Exporting CSV files using COPY - Postgres Stories

14
.
11
.
2023
Jarosław Kowalewski
Postgresql
Ruby
Ruby on Rails
Michał Łęcicki - From Celluloid to Concurrent Ruby

From Celluloid to Concurrent Ruby: Practical Examples Of Multithreading Calls

14
.
11
.
2023
Michał Łęcicki
Backend
Ruby
Ruby on Rails
Software

Super Slide Me - Game Written in React

14
.
11
.
2023
Antoni Smoliński
Frontend
React
Jarek Kowalewski - ILIKE vs LIKE/LOWER - Postgres Stories

ILIKE vs LIKE/LOWER - Postgres Stories

14
.
11
.
2023
Jarosław Kowalewski
Ruby
Ruby on Rails
Postgresql