6 typical developers challenges and how to solve them
As programmers we are dealing with various tasks on daily basis. Some are boring, some fascinating. Nevertheless there are a few general problems everyone encounters at some point. These challenges often appear when real-world domain meets the technology limitations. Let’s take a closer look at them and try to dissect the problem and identify solutions from both technical and soft-skills perspectives.
Time & Date
Storing timestamps and operations on dates is a source of a lot of issues. Imagine that your application gets a reading from an external device every second. Your task is just to calculate a daily sum. Simple? Yeah… However, once a year you get one hour less of the readings and once one hour more (DST). Additionally sometimes one minute may have 61 (!?) seconds (leap second).
It’s only the beginning of problems. Let’s say that you need to store dates with timezones. This means that you need to store two values-one for the timezone info. How to represent that? Maybe integer for offset? Nope, did you know that Australia is in UTC+08:45? What’s more countries change their DSTs and offsets. Often those are just political decisions, but take a look at list of Timezone Data Versions in various JRE releases. Those changes appear quite often, sometimes even every JRE update, it’s worth to be aware of that. Fortunately, in practice in most cases, it is enough to store Unix epochs.
After a longer project which handles a lot of dates you just start wondering, maybe the idea of Internationally Fixed Calendar is right.
To find more info about various strange facts around time and timezones, take a look at blogpost “Falsehoods programmers believe about time and time zones”.
Money
How to represent an amount of money in the code? It may sound simple at first, but actually it isn’t. Floats and doubles are generally not appropriate, since they may not be able to represent the exact amounts. Then, there is the decimal (in Java BigDecimal), however, it can’t be easily passed over the REST API. Some people choose to pass Strings instead and keep decimals in the code. Others decide to present amounts as integers, just as the amount of “cents”. However you have to be careful because not every currency is divided into 100 cents, e.g. Bahraini dinar is divided into 1000 fils.
Appropriate libraries may help you with money representation, e.g. in Java there is the JSR 354 Money and Currency which can be a great help.
Encoding
Both, my first name and last name have a polish diacritical marks in them — ł. Over the years I’ve learned that usually it is not worth to risk to put it in foreign websites form, but still every time I try to. The results are various. Most often the character is not displayed anywhere like it never existed. Sometimes some strange characters appear instead. On one conference the whole name just wasn’t printed. There was no id for me plus my talks were the only ones without the speaker's name. There are also more troublesome situations. A is able to take diacritical marks on input, but later, the mobile app throws an exception because it can’t render the profile page, due to invalid characters. I had more similar cases, so I can personally state that a lot of developers just ignore the encoding of non-English characters.
The most important lesson for programmers here is to leverage UTF-8 everywhere where it is possible. It will cover the majority of cases.
If you’d like to learn more about encoding, take a look at the following article: “What Every Programmer Absolutely, Positively Needs To Know About Encodings And Character Sets To Work With Text”.
Overengineering
People's tendency is to overcomplicate. We often think that a more complex solution is better. We design things we predict may be useful in the future for other not yet defined features. Have you ever heard about anybody who decided to start deploying a Java EE application to different application servers? Or about anybody who actually had altered Spring XML's, changing injections without rebuilding the whole project? Probably no. We find some of those things awesome because they are often technologically impressive, but at the same time complicated and purely understood.
When working with the code we often design complicated hierarchies or try to use new fancy libraries in the project just because they are trending. We invent complicated solutions to trivial problems, just to make our work more interesting.
How to limit that? Think twice before choosing any non-mature library. Also try TDD, which forces you to think about designed code use cases. You may also try to use TDD as if you Meant It, which allows you to write production code only when logic would need to be duplicated to implement the test.
Estimations
The truth is harsh. Nobody is perfect in making estimations. Have you ever tried to finish the house? Estimates are not only the programmer's weak spot. Depending on luck, a “simple house” can get delayed by months. People always hope that they will manage to finish things faster, not expecting the unexpected.
How to cope with that? Planning poker, estimating story points instead of days. Later you can calculate the team velocity. Often it's worth just to double every estimate, just to mitigate future problems.
Meetings
Programmer’s work does not only concern code and machines, but also other people — team members, customers, managers. (Unfortunately ;) ) meetings are required. A lot of people just hate them because they make them stop coding. However, in many cases, they are required. The only thing we can do is to make them as useful and quick as it is possible. Doublethink who should participate, don’t invite people just in case and always put an agenda, mentioning what should be solved during the time-limited meeting.
Conclusions
During the career you’ll encounter a lot of challenges. Some of them will be pleasant, some tiring. Just remember that technical skills are not enough to solve all of the problems. You are working with people, so soft skills are also important.
