DEV Community: Diana

Bugfixing my career

Diana — Thu, 31 Dec 2020 09:31:33 +0000

This may be a different kind of year in review post than the ones you've read before.
I'm sharing my story of this year, hoping that you'll learn something from it, so that won't happen to you.

This year, I lost my love for coding.

Can you imagine I had a job where I didn't had the desire to start side projects? I was doing what I love (mainly Laravel Development with a huge bit of software and database architecture as well as caring about good UI and UX) on a daily basis, 40+ hours a week. I thrived, I learned, and damn, I was good at my job (haters coming in 3, 2, 1 ...).
Of course there were bad days, difficult customers and situations, but overall - all was good. The team, the work, the company.

Then I was assigned to a project of a new customer. Taking care of a huge software monolith, grown over two decades, together with an internal team of theirs. It was bad, you know. PHP, without any framework, with oldfashioned HTML and CSS and lots of jQuery. MVC? No. Composer or Autoloading? Nope. Consistent code style, clean code? One hell of a nope.

First, it was a challenge, so I throwed myself completely at it. I'm doing PHP for several years now and ironically it reminded me of my first projects, so I got into it quite fast (I started coding eleven years old, PHP 4 was still around, no theoretical knowledge at all, but it worked and it was so fun!).
I fixed bugs, added new features, everything that had to be done. Still, the codebase was horrible. It screamed »please rewrite me!« painfully, every day I opened up my IDE.
I always had a desire to improve software, so I introduced my knowledge and opinions of modern (web) development to the customer and the team. Small steps first. Consistent code style, add proper documentation, maybe put a Laravel under it to make it at least a bit more secure. Split it into microservices. Inevitable, rebuild it from scratch.
Summarized: The default suggestions you make for transfering a huge monolith that was virtually un-maintainable, breaking apart every hour and being incredible slow to something better, nicer to work with.
I know that this is a difficult, tedious task. But there wasn't even the intention to do this. »It works, so why change it?« Yeah, you've got clearly a different definition of »it works« than me.

So, if you can't change the circumstances, change yourself, right?
I requested to be withdrawed from that particular project, at least for some of my weekly work time. I'm totally fine with maintaining legacy systems, as I mentioned before, it's a challenge and a constant reminder of being grateful for something like Laravel. But if you're doing it every f*cking hour of every f*cking workday, no. Just no.

Well, to make it short: It didn't work out. That's the problem at being good in your job: You're getting so important for something that you can't be removed from the equation (yeaah hello haters). My bosses promised to appoint me to other projects the next month. The month after. Again the month after that... you get it.

I know that it's hard to make the split between making money and keeping your employees happy, not only for a software company, but in general. I don't blame anyone. But if you're postponing your commitments constantly, they wear of. They're not meaningful anymore.

As the time passed, showing up to work became a daily overcoming. I got up, had breakfast, commuted to work. I was in a bad mood at first, but after some time, not even this anymore. I got dull. I was resignated.
I didn't like coding anymore, I noticed that I got so used to that obscure legacy code that I lost my ability to write good, scalable systems.
This was the last warning sign for me.

But I was not ready to leave this company. Not because of financial manners, but out of emotions, simple loyalty. I was still attached to my team, I didn't want to let them down with that huge amount of work.

So I started side projects for compensation. I learned a whole new part of software development, did no web development, but rather mobile development (Flutter) to get as far away from my daily job as possible. I even purchased a $ 3,000 MacBook in a different color to cut off all connotations. Hell, I was desperate.

The joy came back. The delight of clean and structured code. I coded a few evenings during the week and often full weekends. It didn't feel like work, it felt like playing and having fun again.

But there was an implicit problem with this: The hurdle to get back to my day job after the weekends grow bigger. Good thing is, the atmosphere in the company changed, so my loyality faded as well.
I made one last attempt. One last stand up to try to get my daily job back to what it was once.

Nope, did not work again.

So I resigned - without having something new in sight. I didn't care.

I allowed myself to just exist for a few weeks and I know this is a privilige not everybody has. I really appreciated that because it gave me the chance to recalibrate. To ask myself, what should my life as a developer look like?
I released my app, got back to freelancing and found a few solid clients.
Do I earn more than before? Hell, no. But to be honest, I don't have the need for unnecessary luxury stuff and I never got into coding because of the money. I got into coding because it feels like my vocation, not like work.

But, oh dear, the contentment. The silence in my mind, the serenity. The feeling of doing meaningful work, of expressing myself, contributing to a bigger thing. That's... invaluable. Nothing you can express in a salary.

I don't claim that when you have side projects you need to leave your job. But sometimes you should pause for a moment. Ask yourself, why do you start your side projects? Pure joy, can't get enough of coding next to your day job? Go for it!
But if there is even a little doubt in this, dig deeper. Is it compensation for your employment like I described? Then maybe you should change your situation.

Finding meaning and joy in development again was the main storyline of my 2020, on top of all that pandemic and other weird stuff that happened.
It was an interesting year. I had a lot of lows, but I also have the feeling that I grown a lot in different parts of myself.

Have a nice day and an even nicer 2021.

What's your commit strategy in personal projects?

Diana — Sat, 05 Dec 2020 16:15:45 +0000

One commit for every feature, regardless how long you'll work on it? One commit a day, regardless which features or bugfixes you worked on?

Or do you go full git-style? Particular Branches for dev and release, a new branch for every feature, one commit for every little part of the feature?
Do you even have your own ticket systems or user stories?

What's your workflow with versioning in personal projects?
Looking forward to your comments and thoughts.

Localization of a Flutter App

Diana — Thu, 29 Oct 2020 09:25:50 +0000

In this article I share some facts, tips and magic about the Localization of a Flutter App.

A few weeks ago I spent nearly a whole day in localizing and translating my app, Nabit - Minimalist Habit Tracker App.

There are plenty tutorials and a good documentation considering the technical way, but here a few tips and tricks that I collected after this lengthy - but rewarding! - process.

Before I start, a few recommendations for the technical side:

Start with Localization as soon as you start with your App

This seems obvious - but I made this mistake. I started my app in English and didn't even think about supporting other languages too soon. But then a lot of my friends and family members wanted to use my app, and a few of them were not that good in the english language.

Speed things up!

Use capsule methods

Encapsulating logic is a good way for speeding up the localization process and provide easy-to-read code. I implemented multi-language support by following the tutorial above and the official Flutter documentation. With this, I would have to call Localizations.of<NabitLocalizations>(context, NabitLocalizations).$TRANSLATION_GETTER every time I needed a translation. To be honest, I am a big fan of short, expressive code, so inside my Localizations class, I created a wrapper method for this:

static NabitLocalizations of(BuildContext context) {
   return Localizations.of<NabitLocalizations>(context, NabitLocalizations);
}

So now I just have to call NabitLocalizations.of(context).$TRANSLATION_GETTER now, which is at least a bit shorter and easier to read.

Use user snippets / live templates

Especially if you do the translation after you started your App and you already have a lot of text strings, a bit of IDE automation can be helpful, because you will have to write a lot of getters and other repetitive stuff like this

String get habitsSaved {
   return _localizedValues[locale.languageCode]['habits']['saved'];
}

Automation to the rescue! It's called »User Snippets« in VS Code or »Live Templates« in different JetBrains-Products. I created e.g. this one for the types of getters above:

"NabitLocalizationGetter": {
  "prefix": [
    "nlg"
  ],
  "body": [
    "\nString get ${1} {\n\treturn _localizedValues[locale.languageCode]['${2}']['${3}'];\n}\n\n${4}"
  ]
}

I use the shortcut »nlg« and navigate by hitting tab through the placeholders: Name of the getter, first array key, second array key. The last placeholder ${4} is set two lines below the getter and allows me to start with another one right away.

Another user snippet I created is called by typing »nl« and hitting tab for a quick access to my translations inside the Flutter-Code:

"NabitLocalization": {
  "prefix": [
    "nl"
  ],
  "body": [
    "NabitLocalizations.of(context).${1}"
  ]
}

You can manage all of your snippets inside VS Code by hitting cmd + shift + P (ctrl + shift + P on Windows), type "User snippets" and hit enter. More information about this can be found in the documentation of VS Code itself or the respective documentation of your IDE.

You'll need the build context everywhere you call for an translation!

I like to abstract my Flutter methods as much as possible to make reusing them easy. But be careful: This is also kind of obvious, but you need a BuildContext everywhere you call for a translated text!

Consider other localization tasks

Don't forget about customizable date formatting, time formats (AM/PM, 24h) or even timezones - but this is a completely different topic!

Last but not least: Watch your mouth! ;)

I shouldn't have to mention that - but I have seen to many bad translated apps in my career to not point it out again: Pay attention to your translations. Write grammatically correct, eloquent and easy-to-understand sentences. There's not much worse than the Google Translator, if you need help with translations, consider asking a friend who is fluent in your targeted language - or even a professional interpreter. Deepl is at the moment one of the better online translation tools, but even if you use this, let someone check your final translations before you release your app.

With all of this - thanks for reading! Happy to hear your thoughts and experiences about Flutter Localization.

(Random Fact, don't take it too serious: You don't speak German in Bavaria. You speak Bavarian, in many varieties... and even I, born and raised here, do not understand all of them.)