DEV Community: Piotr Horzycki

How to handle money without losing it?

Piotr Horzycki — Tue, 28 Apr 2020 12:52:25 +0000

Throughout my career, a majority of software I've developed had something to do with money. From complex web shops to payment gateways, money processing is everywhere. It seems to be a very responsible job, yet I can't remember any college courses, bootcamps, webinars, conference talks specifically discussing money-related issues. Is money handling so easy that it's not worth mentioning at all?

You can do a lot of things with monetary amounts:

sum them up in a shopping cart,
place an order,
pass it to a payment gateway,
issue an invoice,
print a PDF file,
send an e-mail receipt,
prepare reports for the management,
prepare tax documents,
and many more.

There are so many use cases, however it looks like everyone assumes that it's all about just adding and printing some numbers. Easy peasy?

What can go wrong?

I've heard a story about a big e-commerce platform that integrates different parcel delivery APIs. While requesting a delivery, the shop had to declare the value of the goods for insurance. Some APIs expected an amount of dollars (like $12.34) while other APIs used cents (like 1234). The e-commerce developer made a mistake which costed the company hundreds of thousands of dollars because the values sent were too big.

Throughout my career, I've witnessed numerous issues related to processing money in all the projects I've been involved in.

For example, my fellow e-commerce admin complained that she couldn't set a product price to $4.10 - the system set it at $4.09. However, $4.20 worked fine.

Where do these errors come from?

How computers handle fractions

Most currencies in the world have subunits. For example, one dollar equals 100 cents. This is why we're used to represent monetary amounts as decimal numbers. So, $12.34 equals twelve dollars and thirty four cents.

This piece of JavaScript code seems reasonable:

const price = 0.1 + 0.2;

We expect the result to be 0.3, but in fact we see 0.30000000000000004. What happened?

A standard for storing and processing fractions that is supported natively by modern CPUs is IEEE 754. It was established in the early 80s and back then it defined only binary arithmetics, not decimal. Until now, when you see the word float or double in your favorite programming language, they most likely represent a binary floating-point number. Converting that number to a decimal counterpart will be subject to error.

float and double are good types for scientific calculations. They were designed to store a very wide range of real numbers by using a scientific notation. Obviously if you try to squeeze that range in only 32 bits, your calculations won't be precise, but how many developers are aware of it?

// Detect dark theme var iframe = document.getElementById('tweet-347561901460447232-195'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=347561901460447232&theme=dark" }

There are many libraries designed specifically to process decimal numbers. Java has BigDecimal, PHP has bcmath, JavaScript has big.js. They have dedicated arithmetic engines inside to ensure precision.

This problem is also important when you try to store monetary amounts in a SQL database. You have to be careful when picking a type for a column. In most dialects, FLOAT is a binary type and DECIMAL or NUMBER are decimal types. Remember to use a proper type!

Money around the world

There are almost 200 countries in the world and around 170 currencies - at least in the ISO 4217 standard. Currencies have different values, so for example 10 USD is not equal to 10 EUR. This is why we should care not only about processing amounts, but also joining them with respective currencies. It's just like in physics where you can't add 1 kilogram and 1 pound without a conversion.

Most currencies have a minor unit of 1/100, so 1 USD equals 100 cents, 1 GBP equals 100 pennies, and so on. But there are exceptions. Japanese yen do not have a subunit (it had in the past). Most varieties of dinar use 1/1000, while Mauritanian ouguiya has 1/5.

I've seen a code which integrated with an external payment API. The code was supposed to convert a decimal amount (let's say, 123.45) and submit it to the API which expected an integer amount of a smallest unit (12345). The if below really bothers me:

if (!"JPY".equals(currency)) {
  amount = amount * 100;
}

Now imagine having such conditions everywhere in your code. How error-prone can it be?

Money in different languages

If you want your application to work internationally, you might need to adjust it to different languages and regions. This process is called internationalization, or i18n. Besides message translations, it also involves number and currency formatting.

Language	Region	Example
English	United States	USD12,345.67
Polish	Poland	12 345,67 USD
Spanish	Spain	12.345,67 USD
Spanish	Mexico	12,345.67 USD

As you see in the table above, even a single language can differ across regions. This is why operating systems introduced locales. These are sets of predefined rules which release us from implementing all the formatting by hand.

Yet still I've seen many cases where people did not use localization properly. They took shortcuts by manually replacing dots with commas. Imagine copying the same replace function a hundred times across the whole application!

The Money Pattern

Martin Fowler suggested that amount and currency can be coupled in a data structure called Money. Moreover, a class like this should provide basic arithmetics. In his book from 2002, Martin wrote:

A large proportion of the computers in this world manipulate money, so it's always puzzled me that money isn't actually a first class data type in any mainstream programming language.

There are implementations of the Money Pattern for most popular languages, but I have an impression that they are little known. Most developers assume that an integer or BigDecimal type is enough to handle money properly.

Let's see how a dedicated library benefits us, as shown in this Java example:

Money net = Money.of(100, "EUR");  // 100 euro
Money gross = net.multiply(1.23);  // 123 euro

Java has a JSR-354 standard for handling monetary amounts and a reference implementation called Moneta. For PHP, there is a similar library called MoneyPHP. For JavaScript, try dinero.js, currency.js or js-money.

Apart from simple arithmetics, most "money" libraries provide a way to easily convert between currencies. Sometimes the only thing we need to do is to feed an object called exchange rate repository with recent data pulled from an API. Sometimes a library does it for us:

ExchangeRateProvider rateProvider = MonetaryConversions
    .getExchangeRateProvider();
CurrencyConversion conversion = rateProvider
    .getCurrencyConversion("CHF");
Money amountUsd = Money.of(10, "USD");
Money amountChf = amountUsd.with(conversion);

Last but not least, money libraries help us adjust the printed output to a specific locale:

MonetaryAmountFormat formatter = MonetaryFormats.getAmountFormat(Locale.ENGLISH);
System.out.println(formatter.format(gross));  // EUR123.00

Conclusion

Handling financial calculations is easy if you follow a few simple rules:

Use proper data types for decimal arithmetics. Avoid float.
Pair an amount with a currency. Even if your software operates only on a single currency, you never know when your client would like to enter foreign markets.
Be careful while exchanging data with external APIs. Pay attention to what is being sent - is it dollars or cents?

If you don't know what you're doing, you can make silly mistakes that might cost your clients a fortune. Why don't you become a professional that other business professionals can rely on? Surprise your coworkers and your clients with knowledge and experience! Good luck!

Improving communication between office and remote employees

Piotr Horzycki — Thu, 11 Apr 2019 20:03:45 +0000

Remote work is challenging. People working remotely need perfect communication skills and discipline because no one is watching over their shoulder. However, the real struggle starts when we try to combine office and remote employees. What problems are we going to face and how can we improve the situation?

I was tired of working in a crowded and noisy open space, so switching to a remote job was a big relief to me. However, I still had to cooperate with people sitting in an office and it turned out to be quite a challenge for all of us. Luckily, with some understanding from everyone in the team, things improved quickly.

Let others know where and who you are

Your coworkers should know if you’re available or not. Set a status which says “In the office” or “Working remotely 9-5”. Use “Away” when you have a break and “Do not disturb” when you need some peace.

At some point, my employer forced everyone to set their photos as profile pictures on Slack. All the funny cats as avatars are now gone. Having real pictures is a good way to integrate people, especially when remote guys visit the office from time to time.

Improve conference calls

We often have calls where one group of people is sitting at the office and another group is remote. The biggest challenge is to create equal participation opportunities for everyone in the team.

Both office and remote people must have a good connection and a good microphone, so everyone can understand what other people are saying. Remote folks usually have headsets; please check their sound quality upfront! If your mic sounds like an old telephone, buy something better.

The best table setup for a call with remote people. Every person maintains the same distance from a microphone. A webcam captures everyone at the table, so that remote participants see exactly what’s happening.

The office group can have a shared microphone on the table. You can find some good products with an omnidirectional mic and an integrated speaker for around $100. Quality matters even more because people are going to sit in a distance from the microphone, thus remote guys will hear more room reflections. Maintain an equal distance from the microphone, so that everyone can be heard equally loud.

When the office team joins a meeting, they share one user account. Remote people do not know who exactly is present in the room. The solution is simple: turn the camera on! The best way is to have an external camera with an overall view of the conference room. If you don’t have it, just rotate a laptop whenever someone else is starting to speak.

Any new people should introduce themselves, like “Hi, I’m Mark, I’m resposible for X and I joined the meeting because …”

It’s good to know who’s joining us and why, and it’s nice to see people smiling. Remote people should launch their cameras too.

Share anything valuable hanging on the office walls

Sometimes people at the office find it convenient to draw things on the wall, or stick some cards here and there. Remote workers do not see these walls. You need to at least share a picture of any diagrams you made on that wall. Make sure remote folks are somehow able to contribute to those drawings.

The same goes with any printed announcements, like “Hey, we’re having a party tomorrow”. Of course if remote people can relate to them. You don’t have to share information about a broken coffee machine, for instance.

Meet in person from time to time

You should meet and have some fun together. The team spirit is much stronger when you can share memories from crazy trips and parties. An organization can facilitate this by organizing different events, like trainings, conferences, lightning talks, etc. Of course you can also have your own initiatives, even if it's just having pizza and beer.

Mixing office and remote workers can bring a lot of fun. It increases diversity because a company does not limit itself to hiring only the people available in a specific location. However, it takes some practice to do it right and get rid of any communication obstacles.

Offboarding: How to quit your job gracefully

Piotr Horzycki — Sat, 23 Feb 2019 22:06:23 +0000

I read many interesting articles about preparing an efficient onboarding process. It is crucial to make new developers contribute to the team as soon as possible. Unfortunately, sooner or later people quit. This is also something our team should prepare for.

Most of the time, employees and contractors have a notice period which lasts usually from two weeks to three months. This might seem like enough time to transfer knowledge and duties, but my experience shows that it’s never enough.

Prepare for the offboarding period

When an experienced person brings their resignation letter, often a panic mode starts within the team. Suddenly everyone wants something and the person who quits has a really busy time.

Sometimes, ambition strikes. Knowing that the days of our current job are counted, we can fall into a mania of fixing everything. This can bring too much chaos into the team and the resulting value is not worth it. If you suddenly decide to update all libraries in the system, you can break a lot of things and drag people away from their current tasks.

There is a simple way to avoid such an “offboarding rush”. Your team should perform regular documentation updates, automate manual tasks, write tests and don’t wait too long with refactoring bad code. This should be a routine, not an exception.

You should avoid the so-called knowledge silos. It’s inevitable that developers in your team will specialize in different parts of the system, and that’s ok. However, you should foster information exchange whenever feasible. This includes proper knowledge base, commit messages, branch names, issue descriptions, chat groups/channels etc.

If you create a hack or workaround somewhere, under time pressure, then at least describe it in a visible place. Other people will be aware of that hack’s existence when you’re not around. I’ve witnessed a lot of situations when experienced people left a lot of hacks even on production servers and then just quit. Such hacks break in the least appropriate time, like a peak of a sales season.

The same goes with every manual task done by a particular person, like manual deployment, setting up repositories and so on. These should be at least documented, so that someone can take over such duties. The best way is to automate as much as possible in a clean and descriptive manner.

Easy to say, huh? But developers often postpone maintenance tasks which are not a part of the client’s requirements. If stakeholders don’t yell at you when you don’t ship unit tests on time, then… you postpone them. They won’t complain about your internal documentation either. Stakeholders aren’t interested if your workplace is clean or dirty if they get a working product. But things can break soon if you don’t clean your mess!

Make a good use of the time that’s left

When the date of somebody’s departure is set, the whole team should decide how to spend the remaining time. You can organize knowledge sharing meetings or pair programming sessions. You can sit and discuss refactoring ideas that could be realized in the future. An experienced developer might share thoughts about further product development and possible problems.

Focus on the most important and valuable activites. As I said before, don’t try to fix everything at once. Also, a person that is about to quit should not do any more tasks on his or her own. The offboarding time should be spent on supporting the team.

Be honest but polite

Quitting a job is often preceded by months or even years of frustration. There can be a lot of reasons for that, and when you finally make the decision to leave, you probably think it’s the only solution left.

In the first years of my career I made a mistake of not being honest about my work expectations, like salary or duties. Employment is all about two parties getting along with each other. You shouldn’t be afraid to talk honestly to your boss.

However, don’t burn bridges. You never know what happens in the future. Maybe you’ll meet your boss again in another company? Maybe some day you’ll receive an interesting offer from your superior?

Also, be polite and do not spread your frustration everywhere. Your team might still contain new, enthusiastic people. Don’t take their motivation away.

Be responsible

The way people quit a job tells a lot about their social skills and emotional intelligence. Also, the way a team deals with people leaving the workplace speaks a lot about its practices. We all need to be responsible, mature and polite, so we can avoid sudden stress caused by someone quitting.

Do we still need recruitment agencies?

Piotr Horzycki — Sat, 14 Apr 2018 09:41:29 +0000

As a candidate looking for jobs, I've never cooperated with any recruitment agencies. But as a senior developer responsible for tech interviews, I was forced to work with some HR companies and I had some really weird situations because of that. Sometimes it's annoying, sometimes it just makes me laugh. Anyway, due to my bad experiences it's hard for me to find any reason to pay commission to an HR/talent agency. I've always disliked "men-in-the-middle". Yet, many companies seek talents through agencies in addition to their own headhunting struggles.

Let me briefly explain a standard recruitment process we developed in our company. We didn't have an HR department, so the whole process was led by me and CTO. First, I prepared a job offer which would reflect our current needs. Then, the CTO posted that offer on various platforms. We received different resumes and reviewed them. If you did not have a meaningful GitHub profile, we usually asked to do our simple recruitment task: write a PHP shopping cart implementation for existing unit tests; kind of TDD, most people solved it under 4 hours. We also sent some technical questions to see if we don't waste your (and our) time meeting you at the office. Especially if you lived several hundred miles away. If we liked your answers and the solution to our task, we would invite you to a personal meeting (around 1.5 hour) consisting of a soft interview and tech interview. Finally, you could receive an offer from us... and turn it down if you did not like it.

Simple, isn't it? Just two parties making business with each other. We are the client and we buy services that you provide. We negotiate the deal and if everyone's happy, just tell us when you can start. The description I mentioned is generic; we tried to approach every candidate individually according to the provided materials, proven experience and a lot of other factors. You didn't have to solve our coding task if you found another way to show off. Fun fact: we've never cared about your formal education.

Unfortunately the resumes we received from job board users were not enough and because the company did not want to invest its money in greater headhunting endeavors like going to conferences or recruiting a full-time HR guy, well... it decided to use some help from external HR agencies. We would present our needs to the agency and it was supposed to find right people for the job. We received a written recommendation for every candidate. After successfully hiring an employee, the company paid commission to the agency.

How recruiting with agencies went wrong

I wouldn't moan if those companies did their job well, but what I experienced instead was:

The recommendations were generic and useless. Every candidate was described as a positive, pro-active team player who aims for personal development. Blah, blah, blah. If you stripped that BS, you would find out that you're dealing with a mediocre coder with a boring portfolio. Both the company and the candidate wasted time talking to the agency because one way or another, we had to figure out most things for ourselves. The most interesting facts were those off the record.
One agency used to save these recommendations as DOCX files. I work on Ubuntu and LibreOffice did not properly render those files, throwing some contents away from the page. I had to switch to Windows, launch Microsoft Word, prepare myself a PDF file and switch back. Eventually, the HR guys learned how to create PDF themselves. What a relief.
The same agency stripped my recruitment task. It originally was a GitHub repo which consisted of some important files in the root directory (composer.json, docker-compose.yml, phpunit.xml.dist and - most important - README.md!) and a tests directory. You had to write a simple implementation which passed all of my tests. I surprisingly found out that all candidates sent by that agency rewrote composer.json on their own. I asked them: "Why would you do that? The whole autoloader was defined there!." It turned out that the agency sent the candidates only the tests directory. They did not send the full repo, of course - the candidate could find out what company made that task. The target company's name is top secret in the beginning - and I recklessly used it as a vendor part of PSR-4 namespaces.
The situation with missing composer.json involved also one candidate which was so tired of endless meetings with an agency that - after learning what company is he applying to - he declined to cooperate with the agency and sent his resume directly to us. I didn't know that story and I was surprised to see that he already solved our task.
Speaking of endless meetings - that's the thing I always hear if someone decides to share his or her experience with an HR agency. When you see a fancy job ad like "For our client, a market leader..." and you send your resume, you're invited to an entry interview in the agency HQ. Then you receive our task to do at home. Then they invite you to another meeting... but not with us! If that meeting succeeds, you eventually make your way to our facility. You go there and probably hear the same questions you've already answered in the previous meetings, because the incompetent agency did not properly sum up your answers and we don't have enough data about you.
Sometimes we don't receive a full resume, but only a solved task (kind of a blind recruitment). Sometimes we receive a resume with a surname washed out. Sometimes we receive only the recommendation and not the original resume.
Sometimes a candidate is forced to visit the target company together with a guy from HR, who ensures that we don't make a deal behind their back and we don't abuse you. To me it's like coming to an interview with your dad! He's a man-in-the-middle. It's not a deal between an employee and an employer. Fortunately, your "dad" stays only for a "soft interview" and he walks away during the tech interview (which I lead). He goes for a coffee and waits there until we're done. So basically he gets paid for drinking coffee in our office.
It's funny to see how an extravert, upbeat HR guy brings a terrified candidate to the meeting. At the first glance I would hire the HR guy, not a shy, scared dev.
My coworker received an offer for my position from an agency when I decided to leave the company.
My boss received an offer from an agency to hire a colleague who was just about to leave the company.
When you get hired and work for a while, the agency calls you from time to time to ask how is it going. That's what my coworkers told me. As an employee, I would find this annoying.

I have no way to convince my soon-to-be-ex employer to stop wasting money with HR agencies (or invest in the right one). But I still wonder why good devs in Poland respond to the job ads posted by agencies where you don't have a target company's name disclosed. The salary range is not specified either. If I invest my time talking to the HR guy, I would like to know in advance who am I going to work for and what salary I can expect!

Carving my own path

Like I said in the beginning, I have never looked for a job through an agency. I have some basic googling skills, but let me show you a brief story of my career which provides some more tips:

I met my first employer during high school. It was a local news company. My friend had already worked for them and he asked if I could make some photos at local events. Still being a student, I started my humble photography career in my spare time. After my high school exams (Polish matura) and before going to university, I got a permanent job offer. They discovered I can code PHP for food, so they hired me to work on their new website during the day AND make photos in the evenings. Weird setup, but this job gave me a lot of life experience.
After five years, I met my future girlfriend. I decided to relocate to Gdańsk which is ~300 km away from my hometown. I started browsing pracuj.pl, a Polish job board and soon I found an offer from an education company. I sent my resume, did a recruitment task and after three weeks I got an offer! I've been working there for over four years. During that time, my salary has doubled and I went from a mid developer to a team leader.
Me and my girlfriend decided to change our lifestyles and travel more. I needed a full remote job. I remember meeting a nice software house at a PHPers conference in Poznań. I sent my resume. Unfortunately they just stopped their recruitment process at a time. But after a month I received an e-mail inviting me to a new process, which I passed successfully. I had three interviews via phone and Skype: entry, tech and soft skills. I really liked all those interviews. One of my interviewers said he saw my PHPers presentation about database optimization and he already knew my name. I got the offer with a salary which allows me to live decently, buy more music equipment (oh yeah!) and even save money for retirement.

As you can see, my ~10 years career as a developer did not include any deals with any recruitment agencies. It is important to say that I'm not an easy-going, upbeat and extravert person. I'm not good at getting my foot in the door, but at least I've learned how to create my resume properly, find a possible employer and make him interested in my offer. I've spent a lot of time browsing Polish nofluffjobs board where all the offers are plain and simple, with salary specified upfront.

What's more to do? I guess I should visit more conferences and give more talks, so that people will know my name. I should write more blog posts and possibly contribute to Open Source. That way I'm going to develop my personal brand and hopefully do my business stuff without the HR agencies.

If you work in an HR/talent agency, please improve your skills. I know that IT headhunting is very hard and it might be really frustrating to abuse LinkedIn for the whole day just to receive a bunch of rude replies (or no replies at all). But if you want to do a good job as a headhunter, you need to understand how candidates and companies behave and what they really need. We're all here to make business happen, right?

I gained all of the above experiences living in Poland. I would love to hear from you guys how the job market looks like in other countries. Feel free to comment!