DEV Community: Alex Fedorov

When Is the Perfect Time to Move on as a Developer?

Alex Fedorov — Tue, 11 Feb 2020 16:48:04 +0000

If you want to have a simple, easy, comfy, safe and secure job, then stop reading this post right this moment!

Still here?

Good. Let’s do this then!

20yrs of experience or 1yr repeated 20 times?

If you’ve been a developer for a while, you probably have noticed that there are folks with double-digit experience in years.

But they are not as good as you wish they were.

They focus on wrong things, they are stuck in the past way of doing things, and use outdated technology, or want to spend as much as possible of their time in the meeting.

(so that they don’t have to do actual work).

There is a term in the industry for these developers: “1 year of experience repeated N times.”

Of course, it’s not so black and white, and you can have somebody who has legit 3-4 years of experience, but then they got stuck in a situation that didn’t really allow them to acquire new skills, and they were repeating these 3-4 years (or subset of them) for a while now.

So we have a whole range, from people who are plain harmful to the team, product, and the company, who just want a safe and secure job and do as least work as possible.

And somewhere in the middle, we have well-meaning folks who have lost their ability to learn new things, improve, and are terrified of stepping outside of their comfort zone. They may be a good worker or inadvertently block others from improving and delivering value quickly.

Finally, you have someone who had 20 years of experience, and this experience was always unique, challenging, and still extending their comfort zone further and further.

These are top performers who help each team member around them and deliver exceptional results. And if you ask them tomorrow what they learned yesterday—they’ll always have something interesting to say.

Unfortunately, it’s way to easy to fall into a trap and get stuck in the middle, or even worse.

It’s way too easy to become “1 year repeated 20 times.”

When you finish reading this article, you’ll be well-equipped to prevent that from happening and even become exceptional with real 20 years of experience.

But before we jump into solutions, why not dive deeper into the problem?

Problem: wasting experience years

This problem occurs when you are wasting entire years of your experience, just doing a secure, comfy job, where you don’t need to challenge yourself or learn anything (or much).

One thing is to waste years entirely (sure way to become an epitome of “1 year repeated 20 times”), and another thing is to have the quality of these years of experience reduced.

What do I mean by reduced?

That’s when you are still learning a bit, and it’s a bit challenging, but it is way below what you can really handle, and it is not really stretching your comfort zone enough.

Real experience is gained outside of your comfort zone.

How does this happen?

For example, you may be good enough with the technology at your job, and you can handle 98% of the work with your closed eyes.

Then the process—it’s just working for you, okay, even though there are definite improvements that can be done to get 50-80% efficiency gains, but no—why touch what works.

Why risk it?

Why step outside of your comfort zone, and pull your team with you?

That’s the line of thinking that gets the person, the team, and the organization into the reduced quality of experience mode.

Also, the reduced quality of performance as a long-term result of this all.

Another problem with such complacency is that the longer you don’t step out of your comfort zone, the harder it’ll be to do in the future. Eventually, it becomes a terrifying step and almost nigh impossible to do.

Don’t ever let it get to this point!

The right mindset is one of continuous improvement and growth.

In this mindset, you’re going to be improving yourself, your team, people around you, product, codebase, and the company you’re in (and maybe even the world) all the time, with small incremental, but definite steps.

Of course, you’re going to fail.

And that’s good. Failures are the signs of learning, and of you attempting to do something very likely to be worth it.

People who don’t fail—do not learn.

This mindset is how you maximize your own experience quality and get the most out of your time and how you become a top performer.

Hello, dear skeptic

I know what you might be thinking:

It’s a terrible idea only to do new things, and only learn, because you have to become good at something via repetition and practice, before you can perform at a decent level.

If that’s what you’re thinking, I cannot agree more with you!

I don’t advocate limiting yourself to doing new things only.

Instead, you should get your existing skills to an excellent level until things start to get more comfortable. And that is the right moment to add some more skills or responsibilities to your repertoire.

This way, you always maintain a constant cumulative level of challenge while delivering excellent quality work.

Alright, let’s get technical with how you can keep ever-increasing the quality of your experience years:

Practice and get better at what you’re already doing

If you are already doing something well, and it’s quite easy to deliver your work, then it’s time to start challenging yourself.

How?

You establish restrictions:

Try to do it faster while keeping the same level of quality;
Try to improve quality, while spending the same amount of time;
Help others to do this better—become multiplier.

In essence, practice, deliver, fail, get feedback, learn from it, and improve.

Every day.

If you do that, soon you’re going to reach a point where the amount of effort and time it takes to improve is just too much for the increase of effectiveness or quality.

This is where you can start handling some more responsibilities:

Get more responsibilities

For example, you’re getting really good at 2 out of the 3 necessary skills to do your job, and your boss is pleased with both of your current responsibilities.

Then it’s time to look around you and see what should be done, but it’s not getting done, or not consistently, and no one is responsible for.

But your gut really tells you these things have to get done consistently.

Get the ownership of that. Just start doing that. Learn in the process. Take that responsibility.

Of course, you’ll make mistakes. But you have your saving grace—you’re trying to make things better for everybody around you.

Once you get 10-20% of the mastery of that responsibility and see some good outcomes, go to your boss and “make it official.”

If it so happens that there are no responsibilities around you to take ownership of, then you should go with a new skill:

Get more skills

For example, you’re handling all responsibilities that suit you, and all of your three skills are at the level where improving them doesn’t make too much sense anymore. They’re that good.

Then it’s time to hunt some more skills for your belt.

First, look at what new skills you want to have (try to guess what you may need in the future), or what you think you’ll love to do.

Second, take a look at your environment, what skills are lacking in it? That’ll be beneficial to either the team, product, or company as a whole.

Now, intersect the two. What’s left is what you should be learning, practicing, and start applying at your job.

Again, practice, deliver, fail, get feedback, improve, and repeat.

Now, there is a dark side to all of that. Let’s chat about it:

What you SHOULD NOT do

If you realize that what you want to learn doesn’t fit your current company or role, then forcing it into your job will bring a lot of harm to the people around you, product, and your company.

An excellent example of that’d be a new fancy programming language or technology. But you have to come up with almost implausible excuses to use it at your job.

My personal work ethics tells me that this is a horrible idea then.

Therefore, this is not something you want to do.

Don’t be too selfish.

But what if you see this skill or that responsibility as a vital component of your future career?

Well, if you really think so, then there is a solution for you:

It’s time to move on

For instance, you are in the unfortunate situation where what you want to get better at, doesn’t benefit your employer or your team (or even harms them).

Then it’s time to start searching for a new job, and if your company is big enough, investigate what other roles/departments you can move in, where it’d work well.

Your goal is to start learning and practicing it on your own (and in 10% time if you have that benefit at your company), but not force it into your day-to-day work (to do no harm).

In parallel, talk to people.

A lot of them.

Learn what companies are out there, and who may need your current skillset plus what you’re trying to learn.

Reach out to them and try to get through the interview process. You probably will have to play a number game, because, while you’re expert in a few topics, you’re still learning this one.

Look for something that will fit your chosen direction as best as possible, and where you, learning this on the job, will be precious to the team and a company as well.

I cannot stress enough—it’s going to be challenging.

And it’s well worth it!

Also, since you are changing roles/companies, it’s an excellent opportunity to negotiate a higher paycheck. For example, with this website for developers you can share your salary info and find out how much people earn at the other company you are negotiating with.

Finally, depending on your aspirations and goals for the future, it may be a good idea to start your own thing:

Go independent

If your ambitions cannot be satisfied anymore by any organization around you (or even remotely, in a different country), then you’re likely to be ripe to go independent.

What do I mean by that?

Well, there are three options:

become a freelancer,
start your own product company,
start a service company or agency.

There is, of course, a whole lot to learn there. And a lot of potential failures to encounter.

And that’s good. As we established, this increases the quality of your years of experience!

There are trade-offs to these options, and probably more I haven’t thought about yet. I’m not going to cover these in this post—it’s already getting long! (sorry about that)

What I should tell you, is that there are few things you should do before going independent:

Make sure to save some money for N months—you need that runway because success won’t come on day one.
Line up a job or contractor opportunity in N months for the worst-case scenario where you have failed a lot of times and never succeeded getting anything off the ground.

Just remember, failing is not a bad thing. If you are failing and failing often—that’s great. (Just don’t forget to learn and improve between failures).

It’s much worse if you are not failing for a long while, only to run out of all your saved money and realize that the whole venture was one big failure, and you haven’t had an opportunity to learn from it. And now it’s too late.

Get a mentor. Almost every successful independent person had a mentor. That’s one of the primary ways you’re going to get feedback on what you do and improve.
Seek external feedback as often as you can. Sometimes, in business, what appears to be a failure to you, may actually be a bud of the enormous success that you can’t see because you lack a specific type of experience.

That’s the hardest path, and it’s well worth the effort. Good luck, and let’s summarize:

Conclusion

As you know, some folks have 20 years of experience, but actually, just one year repeated 20 times. Let’s call it “the left side” of the scale.

And then there are outstanding professionals, who have only, what 7 years, but all of these years are unique experiences that make them exponentially better than the former. These are probably top performers in their field. Let’s call it “the right side” of the scale.

(pun intended)

And then there is everything in between.

So how does one get closer to the right side?

Don’t chase only “new and unique” all the time—make sure you actually get good at skills and responsibilities before you add more things to your repertoire.
Challenge yourself every day. Be ready to answer the question “what did you learn yesterday” with something substantial. Perhaps add “how did you fail last week” to the list of these must-be-able-to-answer questions.

In fact, answer these questions every day, if you can help it.

Never become complacent and have an “easy job.”

Get more skills that’ll help your team/product/company to become more successful when your current skillset starts to near the “easy job” state.
Become responsible for more (and more important/challenging) things.
Make sure that what you’re adding to your “toolbelt” is actually valuable to people around you, your product, your company, or your customers.
If your path forward makes the above not true, then it’s time to switch a job. Don’t forget to negotiate a larger paycheck, as this is the easiest time to do that! Use this to find out what is the pay at the company you are negotiating with.
Finally, if such a company doesn’t exist (or is inaccessible to you)—then create one! Become independent.

Now it’s your turn!

Quality of the years of your experience is entirely in your hands. Don’t let weak excuses make you think that somebody else is responsible for your career.

You are the only one.

And you owe yourself to get as close as you can to “the right side” of this experience scale.

So get out there, and never ever stop learning!

Photo by Joshua Coleman from Unsplash

How have I ensured the privacy and anonymity of my website users? 🤔

Alex Fedorov — Tue, 17 Dec 2019 00:14:15 +0000

Over the course of the past month, I’ve built the first version of FelloWage—a website that allows users to share their salary information and view information shared by others.

Of course, I wanted to keep the information of my users private and anonymous. When somebody is looking at the wage entry, they shouldn’t be able to tell who this entry belongs to.

On the other hand, to keep the quality of the shared data high, users should be able to update their salary entries when they change over time. Thus the wage records need to be somehow connected to the respective user accounts.

This poses an issue: if I implement it in the most obvious way (a database foreign key relation), then the website operator (me), effectively, has access to this connection between the user account and a salary record. Also, legal authorities coming with a court order will be able to see this as well, and in the unfortunate case of a successful cyber attack, the hackers will get their hands on this data too.

This is not good enough! How can we do better?

We are looking for a solution where:

the wage entry is readable by all users of the system,
the connection between wage entry and the user account is readable ONLY by the user account owning that entry,
user accounts are readable to the system (at least partially) for the purposes of the login system.

In my scenario, since the user sign-up verification is a manual process, I needed the system to be able to write this connection without the presence of the user.

If we sum it up: only the user should be able to read a connection record, and the system should be able to write this record (but not read it).

Assymetric encryption

This sounds to me like asymmetric encryption, where the system knows the user’s public key, and the user knows their own private key. The system uses the public key to encrypt the information when it needs to write it, and the user can read that information using their private key.

Of course, the next challenge is UX. We can’t have the users use private keys every time they want to login.

That’d be too clunky.

Passphrase-encrypted private key

Then it has stricken me: what if I do the same thing SSH keys do when you set them up with a passphrase?

Now the system will store both types of keys:

the public key, and
the private key encrypted using the user’s password.

Now, even if I were to drop into the raw SQL in my database console, I wouldn’t be able to tell who owns which wage entries anymore! And the user can still see and manage their own entry.

As a bonus, I’ve found this method of securing the user’s data quite convenient, and I used it for other information as well, where I’m sure that only the user will need access to this data.

Of course, we still need to make sure that the users create strong passwords that are not vulnerable to dictionary attacks, and weren’t part of any breach. I’ve used zxcvn by Dropbox library and “Have I Been Pwned” API for that.

Thank you for reading!

I’m glad you’ve gotten to the end of this post! If you are interested in more behind-the-scenes posts like this, you should subscribe to our newsletter.

The next post that is in the making is a deeper dive into the implementation details and challenges of the solution from this article. Don’t miss it, grab our newsletter here! 🚀

Thank you for your support!

How Can Hierarchical Test Structure Absolutely Make a Mess?

Alex Fedorov — Sat, 02 Mar 2019 14:41:05 +0000

Have you ever written your unit tests using a simple xUnit style testing framework?

Then you probably know, as tests get more complex, the more boilerplate and duplication they collect, either spread among the test methods, or setup functions.

Now, hierarchical context frameworks are pretty robust to mitigate this boilerplate problem and remove this duplication. They allow you to have nested contexts each one having their own little bit of setup, and “inheriting” the setup of parent contexts.

This way, you can express lots of different scenarios without actually repeating yourself even once in the test setup code.

Great, isn’t it?

Now, what if I told you that hierarchical test structure can cause more subtle duplication (that it was supposed to prevent in the first place) that is hard to spot and refactor?

Let me give you an oversimplified example:

Two Fetchers, elusively alike

The other day, I was working on two “fetcher” classes that talk to the HTTP client for 3rd party API and contain business logic of what needs to be done, and also can handle both immediate “successful,” and asynchronous “accepted” responses.

Their code was pretty similar, and whole logic of handling the response, and re-scheduling the async task was duplicated, so we have refactored it in a separate collaborator object in the production code.

Then we thought: “Well, we refactored duplication in the production code. There bound to be a duplication in the test code. Let’s get it DRYed as well!”

Not so fast!

When we started reading two test suites side-by-side, it turned out that they don’t look too much alike. It was hard to spot and isolate the duplication.

They were written in a hierarchical style, and they were leveraging the full power of nested contexts.

Here is a reduced example for the first test (in Kotlin):

describe("FetcherOne") {
    lateinit var asyncQueue: AsyncQueue
    lateinit var fetcher: FetcherOne

    val client = Client()
        .withMockResponseStatus("accepted")

    // … more irrelevant variables here …

    beforeEachTest {
        asyncQueue = AsyncQueue()
        fetcher = FetcherOne(asyncQueue, client)
    }

    describe("perform") {
        beforeEachTest {
            fetcher.perform()
        }

        it("tells client to do stuff") {
            assertThat(client.actions).contains("doStuff")
        }

        it("triggers an async polling job") {
            assertThat(asyncQueue).contains(fetcher::pollStatus)
        }

        // … more irrelevant tests here …

        context("when there is no need to check for status") {
            beforeGroup {
                client.mockResponseStatus("successful")
            }

            it("does not trigger an async polling job") {
                assertThat(asyncQueue).isEmpty()
            }

            // … more irrelevant tests here …
        }

        // … more irrelevant contexts here …
    }
}

So the test suite starts with the root context. Here is where you can set the global defaults for your test suite, and override some of them in the nested contexts.

This is good if you have a typical “happy path” scenario, and then you have more “special cases,” for which you’ll use nested contexts.

Notice that we’re mocking the HTTP client to respond with an “accepted” status:

val client = Client()
    .withMockResponseStatus("accepted")

And then in one of the nested contexts, we override the response status to “successful”:

beforeGroup {
    client.mockResponseStatus("successful")
}

With that all in mind, take a look at the second test suite:

describe("FetcherTwo") {
    lateinit var asyncQueue: AsyncQueue
    lateinit var fetcher: FetcherTwo

    val client = Client()

    // … more irrelevant variables here …

    beforeGroup {
        client.mockResponseStatus("successful")
    }

    beforeEachTest {
        asyncQueue = AsyncQueue()
        fetcher = FetcherTwo(asyncQueue, client)
    }

    describe("perform") {
        beforeEachTest {
            fetcher.perform()
        }

        it("tells client to do some other stuff") {
            assertThat(client.actions).contains("doSomeOtherStuff")
        }

        it("does not trigger an async polling job") {
            assertThat(asyncQueue).isEmpty()
        }

        // … more irrelevant tests here …

        context("when there is a need to check operation status async") {
            beforeGroup {
                client.mockResponseStatus("accepted")
            }

            it("triggers an async job to check the last operation") {
                assertThat(asyncQueue).contains(fetcher::checkLastOperation)
            }

            // … more irrelevant tests here …
        }

        // … more irrelevant contexts here …
    }
}

As you can see, the author of this test suite have chosen a different response status as the default “happy-path” scenario—“successful”:

val client = Client()

beforeGroup {
    client.mockResponseStatus("successful")
}

(and used a different mocking style on top of that)

And the nested context overrides the response status to “accepted” status:

beforeGroup {
    client.mockResponseStatus("accepted")
}

Now, with this example, you could figure out how to refactor it quickly enough, after inverting the default and custom scenarios for one of the test suites, right?

This example is elementary. What we had was more complicated. Imagine that your async polling and retrying logic (what we were trying to refactor) was dependent on 4 factors:

You’ll have 4 levels of nested contexts describing each element as a part of the overall scenario;
Each context may choose a different default case as opposed to which ones should be overridden in the inner context.

As you can see, this can quickly become a mess, and very hard to refactor.

If we had a classic flat test structure, we’d have a little bit of duplication in the test suite, but it would be so much easier to compare test suites side-by-side and refactor them.

Let me show you an example:

describe("FetcherOne") {
    lateinit var asyncQueue: AsyncQueue
    lateinit var fetcher: FetcherOne

    val client = Client()

    beforeEachTest {
        asyncQueue = AsyncQueue()
        fetcher = FetcherOne(asyncQueue, client)
    }

    it("perform - calls client") {
        client.mockResponseStatus("accepted")

        fetcher.perform()

        assertThat(client.actions).contains("doStuff")
    }

    it("perform - triggers async polling job when accepted") {
        client.mockResponseStatus("accepted")

        fetcher.perform()

        assertThat(asyncQueue).contains(fetcher::pollStatus)
    }

    it("perform - does not trigger async job when successful") {
        client.mockResponseStatus("successful")

        fetcher.perform()

        assertThat(asyncQueue).isEmpty()
    }
}

The second test suite will now look very similar (not worth showing here, but you can see the gist if you like).

As you can see, refactoring the duplication between two test suites now is almost a no-brainer.

Do you like to learn more about testing and TDD in Kotlin?

I have written a 4-part (350-pages total) “Ultimate Tutorial: Getting Started With Kotlin” (+ more to come), and you can get it as a free bonus by becoming a member of my monthly newsletter.

On top of just Kotlin, it is full of goodies like TDD, Clean Code, Software Architecture, Business Impacts, 5 WHYs, Acceptance Criteria, Personas, and more.

—Sign up here and start learning how to build full-fledged Kotlin applications with TDD!

Conclusion

Now, I’m not trying you to convince of one style or another. I’m just trying to tell you that both styles have their strengths and weaknesses.

And as we’ve noticed even strength of the style might let you shoot yourself in the foot. So be careful: with power comes responsibility.

Don’t make your hierarchical tests too complex and too nested!

Your Turn

If you like my ideas, consider giving this article lots of dev.to reactions 😊 and share your own experiences with both styles in the comments below:

What tricky situations with testing can YOU remember?

originally published on HackerNoon
picture credit: pexels

9 Rules of Effective Development Team Meetings

Alex Fedorov — Thu, 31 Jan 2019 06:28:37 +0000

Let me ask you a question.

Have you ever had a meeting scheduled 45 minutes after the stand-up? Have you been able to do any productive work before it?

Hardly can get into any deep enough focus before such distraction. It’s frustrating, I know!

Also, do you remember that time when some important decision was to be made at 7 freaking PM?? You didn’t have any energy and not so invested in making the best choice at this point, which is entirely fair at this time.

Nor your colleagues.

How successful was that decision then? Not so great, I guess.

What do you think about heated discussions that can’t come to a close after 4-5 hours straight? Yeah, I know, you’re lucky to have had that lunch break in the middle…

And how often did you feel that you shouldn’t have been invited to the meeting in the first place? Because you really don’t have anything to contribute or you trust others to make the right decision?

If any of these questions evoke bad memories of worst meetings in you, then you’re in for a treat.

Here is a short list of four rules to make your team’s meetings effective again:

1. Early in the morning, right after the stand-up.

As a knowledge worker, you don’t want to have 30-60mins between your start of the day and important meeting. You’re likely not to be able to focus on anything deeply.

It’s frustrating, I know!

Also, if the decision is important, you want your people not to be tired when making it. Otherwise, they’ll be pretty bad decision-makers, right?

2. Short. Non-negotiable time limit.

If you allow your meetings to run more than 15-60mins, then you’re likely to have 5-6 hours discussion where opposing sides with strongly-held opinions can’t agree on the decision.

Put a hard time limit in place.

This will force people to not waste time on what’s not important in the meeting.

3. The 2nd best decision is better than no decision at all.

Have a team come up with some decision, even if not everyone agrees. Adopt the mantra “A decision is better than no decision. We can always correct the course when we have more information.”

4. Minimum viable audience.

If you can make this decision with only 3 people instead of 12, then go for it, and pull people as you need them and if you need them only.

Contributed by commenters:

5. No meeting without an Agenda

(by Martin Riedel)

If you get an invite without agenda and unclear goal, just decline it. If somebody asks why tell them that there was no agenda.

6. Rule of the two feet

(by Dimitri Merejkowsky)

If you feel like you can’t contribute to the meeting in any useful manner, or you don’t think that the meeting has any value for you or for your team/org, then just use your two feet—leave the meeting.

Surely, everybody needs to understand this rule and accept that this might happen.

7. No phubbing. No screens allowed other than presenter’s one.

(by Dimitri Merejkowsky)

Don’t use your phone or tablet—they’re forbidden. Some apps allow whole group to block their screens on their phones for the time of the meeting, and if somebody phubbs, then the entire group gets “punished” in some virtual way (for example, your virtual tree dies, and you have to start over).

If the meeting needs a presenter’s laptop, this is alright. If you need to take notes, then do it on pen&paper.

If you have somebody who protocols the meeting, they can have a protocol laptop (single-purpose device: there should be no distractions possible on such a laptop).

8. Have a facilitator

(by Oleksii Fedorov)

Have a person responsible for running the meeting. This shouldn’t be a manager of any sort. The facilitator’s role is a role of servantship, not management.

They’ll make sure that we’re not diverging too much from the agenda, keep track of time, and make sure to table discussions that are not going anywhere or are too disruptive for goals of the meeting.

This person should be a rotating role so that every team member gets a chance to be one.

9. Manage your manager/stakeholder… if you have to

(by Oleksii Fedorov)

You know, that troublesome scenario where people avoid their commitments (decided from the meetings) pretending that they’ve forgotten or misunderstood, etc. This fosters a lot of negativity and conflict. Oh, and especially if they are a stakeholder or something like this.

In this case, documenting all the decisions made is great, and sending them as an email to:

Make sure both parties are on the same page and wish to commit to this.
To hold everyone accountable, including your stakeholder(s) or manager(s) later when “sh$t hits the fan.”

Thank you for reading! If you liked this, please share the article on your favorite social media!

How do you improve your meetings? Share in the comments!

(picture from Pexels)

Why Are Some Developers so Allergic to IDEs?

Alex Fedorov — Mon, 28 Jan 2019 06:58:25 +0000

Countless times I meet developers who prefer simpler editors. And by “prefer” I mean that they have strong negative feelings towards any IDEs, especially the ones that one needs to pay money for.

Now, it’s worth mentioning that my path through coding tools over the last 20 years went like this:

Notepad -> Turbo Pascal Editor -> Delphi -> Visual Studio -> Gedit -> Sublime Text -> Vim -> Emacs -> Emacs (Evil mode) -> Atom -> Vim -> IntelliJ Idea (settled for now).

The switch to IDE had happened when I attended a Software Craft meet-up. I’ve paired with another developer who’ve shown me something that looked like magic to me at a time.

Basically, I’ve felt doubts about the tooling of my choice, since this IDE that was in front of me (in the hands of an experienced user) could allow me to do development at a 5x-10x rate of what I could currently.

Now the question is: why do we, developers, feel such negative feelings towards a paid tool that can boost our productivity so much?

Let’s discuss!

How to Try Kotlin in Java Backend Codebase Without Risk

Alex Fedorov — Wed, 16 Jan 2019 13:32:08 +0000

Who’s heard of this lovely and astounding programming language Kotlin, and wanted to try it out on the real backend project and couldn’t?

This is common. The team discusses that everyone really wants to go Kotlin, and they still decide to create that new codebase in Java. You and your fellow colleagues are afraid that this will go crazy wrong, right?

And you are right to have such a feeling, as you don’t have enough confidence yet to make the switch. What if the whole team is still learning this new technology, and there is an unexpected challenge that nobody can resolve for weeks?

Now, you’re probably quite a bit into this project, and your backend codebase is all in verbose Java, and you think: “No way I can try Kotlin now! Not until next one…”

Wrong.

There is no point in waiting until the next opportunity because of the high chances that it’ll turn out the same!

Now, what if I told you that you can still try out Kotlin together with your teammates in this codebase without any risks, and no strings attached?

Let me explain.

Mixing Java and Kotlin code

With Kotlin’s 100% bidirectional interoperability, it’s possible to mix Java and Kotlin code easily.

What this means, is that you can convert a single file from Java to Kotlin to get the feels of what it’ll look like. And everything will work just like before.

Now, what if I told you that such a conversion is one hotkey away?

Let me show an example. Imagine you had this simple service class in your Java backend application:

// QuizService.java
package com.iwillteachyoukotlin.quizzy;

import org.springframework.stereotype.Service;

@Service
public class QuizService {

    private final QuizRepository quizRepository;

    public QuizService(QuizRepository quizRepository) {
        this.quizRepository = quizRepository;
    }

    public Quiz create(Quiz quiz) {
        if (quiz.id != null) {
            throw new BadRequestException("id should be empty");
        }

        return quizRepository.save(quiz);
    }

    public Quiz getQuiz(int quizId) {
        return quizRepository
                .findById(quizId)
                .orElseThrow(() -> new NotFoundException("quiz not found"));
    }
}

Now, you can press CMD+ALT+SHIFT+K (or CTRL+ALT+SHIFT+K), or you could use Convert Java File to Kotlin File action:

The result is the following code. Notice how both constructor and field definition has merged into a single declaration in Kotlin:

// QuizService.kt
package com.iwillteachyoukotlin.quizzy

import org.springframework.stereotype.Service

@Service
class QuizService(private val quizRepository: QuizRepository) {

    fun create(quiz: Quiz): Quiz {
        if (quiz.id != null) {
            throw BadRequestException("id should be empty")
        }

        return quizRepository.save(quiz)
    }

    fun getQuiz(quizId: Int): Quiz {
        return quizRepository
                .findById(quizId)
                .orElseThrow { NotFoundException("quiz not found") }
    }
}

Note for Lombok users:

Use Delombok on this file before converting to Kotlin.

Of course, you need to add Kotlin support to your build tool before you can even run this code:

Add Kotlin support to Gradle

(Note: refer to this guide if you’re using Maven)

Add a Gradle plugin appropriately:

plugins {
    id "org.jetbrains.kotlin.jvm" version "1.3.11"
}

Note for Spring Boot users:

You need to add this plugin, so that Kotlin classes will open automatically where needed, so that Spring Boot can use reflection on them:
id "org.jetbrains.kotlin.plugin.spring" version "1.3.11"
And if you’re using JPA/Hibernate entities, you’ll need this plugin:
id "org.jetbrains.kotlin.plugin.jpa" version "1.3.11"
This adds the default constructor for your entities.

Also, you’ll need to add a dependency on Kotlin standard library and reflection library:

dependencies {
    implementation "org.jetbrains.kotlin:kotlin-stdlib-jdk8"
    implementation "org.jetbrains.kotlin:kotlin-reflect"
    // …
}

Now you have one Kotlin file among the sea of Java files. Java classes are calling this Kotlin code, and this Kotlin code is calling to Java code.

And it all perfectly works. And all tests pass!

Now, simple automatic conversion is ok and all, but it’s not enough to really leverage the power of Kotlin.

1. Use Elvis operator instead of most null checks

If you had any null check anywhere that returns or throws an exception, for example:

fun update(quiz: Quiz): Quiz {
    if (quiz.id == null) {
        throw BadRequestException("id should not be empty")
    }

    return quizRepository.save(quiz)
}

These null checks that either throw or return are usually called guard if statements. In Kotlin these can be done more succinctly with "Elvis" operator ?::

fun update(quiz: Quiz): Quiz {
    quiz.id ?: throw BadRequestException("id should not be empty")

    return quizRepository.save(quiz)
}

2. Convert `Optional`s to nullable

Another example that can be simplified with Kotlin is the usage of Optional type:

fun getQuiz(quizId: Int): Quiz {
    return quizRepository
            .findById(quizId)
            .orElseThrow { NotFoundException("quiz not found") }
}

Here we’re going to use another method of our repository that returns either a found object or null:

fun getQuiz(quizId: Int): Quiz {
    return quizRepository.findByIdOrNull(quizId)
            ?: throw NotFoundException("quiz not found")
}

As you can see, here we use the Elvis operator, as well. Quite handy, isn’t it?

3. Make JUnit test names more readable

Let’s imagine that the application above had this test in its integration test suite:

@Test
public void failsToCreate_whenIdIsProvided() throws Exception {
    // ARRANGE
    final Quiz quiz = new Quiz(
            42,
            "title",
            "description",
            "cta",
            "https://example.org/image.png"
    );

    // ACT
    final ResultActions actions = mockMvc.perform(post("/quizzes")
            .contentType(APPLICATION_JSON_UTF8)
            .content(objectMapper.writeValueAsString(quiz)));

    // ASSERT
    actions.andExpect(status().isBadRequest())
            .andExpect(jsonPath("$.message", equalTo("id should be empty")));
}

Now, after automatic conversion to Kotlin it’ll look something like this:

@Test
@Throws(Exception::class)
fun failsToCreate_whenIdIsProvided() {
    // ARRANGE
    val quiz = Quiz(
            42,
            "title",
            "description",
            "cta",
            "https://example.org/image.png"
    )

    // ACT
    val actions = mockMvc!!.perform(post("/quizzes")
            .contentType(APPLICATION_JSON_UTF8)
            .content(objectMapper!!.writeValueAsString(quiz)))

    // ASSERT
    actions.andExpect(status().isBadRequest)
            .andExpect(jsonPath("$.message", equalTo("id should be empty")))
}

First, we can throw away this @Throws annotation immediately. It’s mostly useless in Kotlin.

And now, we can use actual human-readable sentences in the method names using backticks:

@Test
fun `create quiz - fails to create when id is provided`() {
    // …
}

My general structure is: "{method name or use case name} - {expected outcome} when {condition}."

4. Use `lateinit` instead of nullable

In cases, when something is being provided later (like dependency injection, or initialized in the set-up section of the test suite), you should use lateinit instead. It’s much cleaner.

Look, this code is a result of automatic conversion:

@SpringBootTest
@RunWith(SpringRunner::class)
class QuizzesIntegrationTest {

    @Autowired
    private val context: WebApplicationContext? = null

    @Autowired
    private val objectMapper: ObjectMapper? = null

    private var mockMvc: MockMvc? = null

    private var quizId: Int = 0

    @Before
    fun setUp() {
        mockMvc = MockMvcBuilders
                .webAppContextSetup(context!!)
                .build()
    }

    // …

}

All these fields are initialized later, AND before the first usage, so we can tell the compiler about that:

@Autowired
private lateinit var context: WebApplicationContext

@Autowired
private lateinit var objectMapper: ObjectMapper

private lateinit var mockMvc: MockMvc

private var quizId: Int = 0

Now, the problem is that all these nullable values were unsafely unwrapped everywhere in the test suite with !! operator:

Of course, we can fix them all manually, but these are things that tools should fix for us.

And they do, look:

It still would be annoying to go through each occurrence though. So we should just apply code cleanups to the whole file:

5. Use named arguments for readability

Now, you see this snippet of code:

// ARRANGE
val quiz = Quiz(
        42,
        "title",
        "description",
        "cta",
        "https://example.org/image.png"
)

We can make this code much more descriptive if we were to use named arguments, like so:

Now, you’ll get this cute little readable snippet of code. Also, you can re-order the arguments when you pass them as you wish, and as it makes more sense.

// ARRANGE
val quiz = Quiz(
        id = 42,
        title = "title",
        description = "description",
        ctaText = "cta",
        imageUrl = "https://example.org/image.png"
)

Unfortunately, to make this feature work, the class Quiz can’t be a Java class, it has to be in Kotlin, so we’ll have to convert the entity below to Kotlin:

@Entity(name = "quizzes")
@Data
@RequiredArgsConstructor
@AllArgsConstructor
@JsonIgnoreProperties({"hibernateLazyInitializer"})
public class Quiz {
    @Id
    @GeneratedValue
    public Integer id = null;

    public final String title;
    public final String description;
    public final String ctaText;
    public final String imageUrl;

    Quiz() {
        title = "";
        description = "";
        ctaText = "";
        imageUrl = "";
    }
}

This is a result of full (auto + manual) conversion:

@Entity(name = "quizzes")
@JsonIgnoreProperties("hibernateLazyInitializer")
data class Quiz(
        @Id
        @GeneratedValue
        var id: Int? = null,

        val title: String,
        val description: String,
        val ctaText: String,
        val imageUrl: String
)

As you can see we’re getting rid of all the Lombok stuff and using a data class now because it can do most of the things, you would need from the entity.

6+. There is so much more you can improve!

If you want to learn more about how good Kotlin code will look like, I highly recommend to go through the Kotlin Koans.

You can do that right in your browser, or in your IDE if you wish.

Now, remember, at the beginning of this post, I’ve promised the "Without Risk" part, didn’t I?

Trying out without any risks whatsoever

Now, if I decided not to make the switch to Kotlin yet (because I still need to convince my colleagues, for example), I can use Local History feature of my IDE to go back in time to when I started playing with Kotlin:

To open that tool in IntelliJ, you can use the contextual menu on the whole project in the project structure tool. There is an option Local History > Show History there:

When you’ve found the place where you started playing with Kotlin, you can revert to the first Kotlin-related change, for example:

Now, there is not a single Kotlin file, and all the tests are passing. This is a handy feature in general if you screwed something up, and haven’t made a commit in Git in a while.

Did that spike your curiosity about Kotlin?

I have written a 4-part (350-pages total) “Ultimate Tutorial: Getting Started With Kotlin” (+ more to come), and you can get it as a free bonus by becoming a member of my monthly newsletter.

On top of just Kotlin, it is full of goodies like TDD, Clean Code, Software Architecture, Business Impacts, 5 WHYs, Acceptance Criteria, Personas, and more.

—Sign up here and start learning how to build full-fledged Kotlin applications!

Thank you and ask for you!

Thank you so much for reading this article! I hope you enjoyed it. Please, tell me what you think about this in the comments!

Also, it would make me so much happier share this post with your friends and colleagues who you think might benefit from it. Or you could share it on your favorite social media!

You are welcome to read my blog about Kotlin, and my blog about TDD and best software engineering practices.

And let’s connect on LinkedIn: I post short weekly updates about software developer’s productivity and happiness, teamwork, mental health, and a bit about Kotlin.

If you want to hear more of my opinions, follow me on Twitter.

Originally published on iwillteachyoukotlin blog.

Kotlin: How Can a Programming Language be so Young And so Mature at The Same Time?

Alex Fedorov — Sat, 12 Jan 2019 09:48:06 +0000

In this article, we’re going to explore why young programming languages with modern features can’t be adopted quickly. Additionally, we’re going to take a look at one exceptional example that got specific parameters right to be both young, modern and mature, just ready for adoption at small and big scale.

DISCLAIMER: Some details are omitted intentionally. Keep your mind open when reading. If something seems naive, or not entirely true, bear in mind that the author thought into both the front and back sides of the coin, and the unseen third side of the coin, as well. You’re welcome in comments for a more in-depth discussion—it’s going to be worth your time for sure!

We all know that most of us, software developers, love to chase after shiny things just as much as we like to build them. This is not different for programming languages.

And, in this day and age, new young programming languages pop up like these mushrooms:

Why new modern languages can’t be adopted quickly?

A distinct feature of a young language is that creators and community gets the chance to experiment with different features and designs to potentially fix some problems of the existing mature languages. Mind you, any solution to any problem will bring minimum two more subtle issues. So this cycle of continuous improvement will never end.

While young languages can explore more advanced features and designs, they usually don’t have a robust ecosystem of libraries, frameworks, and tooling. Moreover, when the community develops these, people will still have to learn them, and that means that they (albeit temporarily) will be much less productive. And I’m not even going to talk about potential vulnerabilities, bugs, and so on.

Now, wouldn’t it be great if the new young modern language could rely on the existing mature ecosystem? Wouldn’t it be fantastic if using existing libraries, frameworks and tooling was entirely natural and not awkward at all?

If you ask me these questions, I’ll tell you that you’re perhaps describing Kotlin. Kotlin is a programming language where you can naturally use any library, framework or tool from the JVM ecosystem without any awkwardness.

Now, there were languages before, that could do that as well, like Scala, Groovy, Clojure, and so on. And they all got something wrong: natural use.

Why these languages don’t want to rely on the existing mature ecosystem?

Either it wasn’t natural to use the same framework or library, or it was even impossible to use the same tooling. And in the scenario where it would be possible to use same tooling, framework, and libraries naturally; somehow, the majority of the community went out there and built new tools, frameworks, and libraries (I’m looking at you, Scala, and sbt).

My hunch is that this happens because most of the early adopters of these new languages (“promised replacements for Java”) have somewhat an adversarial relationship with Java language and JVM ecosystem.

They hate it.

As early adopters, they set the playing field, because they are in the vast majority in the community during the first few years of the new young language. This way, they get to write all the brand new shiny tools, frameworks and libraries. And they are the ones who start new projects in these languages at actual companies and startups.

This way, the community style sets in: unique tooling, frameworks, and sets of libraries that people use. Sometimes, these are even designed on purpose to be radically different from their older alternatives from the JVM community.

This makes the learning curve very steep, and so the language gets adopted only by like-minded people, and poor developers who just have no choice but to maintain the codebases where this set of tools is being used already.

How to attract different early adopters that will be happy to leverage existing ecosystem?

Kotlin is radically different from this approach. The playing field rule number one: “100% bidirectional interoperability with Java and JVM ecosystem.”

Thus the community attracts fellows who are not looking to do everything in the entirely different approach; instead, they want a more modern language, AND they want to transfer their skills, knowledge, and experience from working with the mature ecosystem like JVM.

These early adopters don’t want to rewrite their existing codebases entirely because they are large, so being able to write only new code in Kotlin, and keep older code in Java helps a lot!

Small story of a fellow software engineer

I’m going to give you a tangible example:

Clara is a software engineer, working for a big organization, mostly working with Java, JVM, and Spring Boot. Clara’s professional level is senior and perhaps even beyond that:

she applies best software practices,
knows how to design simple software iteratively,
can solve any complex problem you throw at her,
knows her audience when writing the code (current and expected in the future level of her team members),
excellent communicator and team player,
teaches and mentors other developers,
can take on the role of a team lead today,
and lives the life of a life-long learner.

Her current development workflow includes building the application and automating development tasks with Gradle, and she gets her coding done within a modern IDE like IntelliJ. She doesn’t have any of the adversarial feelings towards any of these tools and technologies.

Quite the opposite: she loves them!

Sometimes though, she feels feature envy to all these cool modern programming languages where you could have one-liner data classes, less boilerplate in general, and the null-pointer exception is not a dreaded threat at every step.

And here is Kotlin programming language that recently became “production-ready.”

So she tries out to build a tiny web app (a tad more complicated than “Hello world”). And it seems like she can still use the same build tool—Gradle; and she still can use any of her favorite libraries, and much more critical, she can use the same web framework—Spring Boot.

And using all these things is not awkward at all, and feels just as natural, as in their “home” environment—Java.

Now, she has the next question: “This language is great but quite new… do I have to lose all the great features of my IDE now?” Because that is what happens to most modern languages—the IDE support is lagging way… way behind.

And now she gets pleasantly surprised: 95% of the IDE features that she needs are there and are supported:

basic and advanced refactorings,
jump to definition,
find usages,
running application and tests from IDE,
running a single test in the current context,
debugger,
code completion, even cross-language,
etc.

And this makes so much sense because the language is developed by the same company that develops the IDE (JetBrains). This certainly ensures that the tooling will be at least somewhat up to speed with the new modern language.

“This all sounds great!” Clara thinks, “Do I have to rewrite my application at work now fully to Kotlin?”

Most important playing field rules fostering the adoption

And she gets pleasantly surprised here as well. All she really needs to do is to add Kotlin Gradle plugin (few lines of change in a single file), and she can start adding Kotlin files to the source code base. All the old files, written in Java, are still working correctly.

Moreover, cross-language calls are working out of the box: she can call Java code from Kotlin, and Kotlin code from Java; AND it all feels just as natural. At almost no point, the calling code is even aware that it is calling one or the other because there is no difference.

That is what making “100% interoperability” a most significant playing field rule right from the beginning can do for the new modern language!

So if you’re going to design a new programming language, I suggest you consider imbuing it as one of the top priorities, as it will allow for much better adoption. And what creator of the library, tool, or language doesn’t want this kind of adoption superpower? ;)

As you could notice, Clara is not looking for an entirely radically different approach to coding, and instead, she is looking for a way to keep 75% of what is working well, and perhaps use a few more modern features of the language to improve the other 25% significantly.

This could be reducing the amount of the boilerplate by letting the language figure out the obvious so that you don’t have to specify it every time. This could also be a different decision to make everything an expression, which makes specific scenarios much more ergonomic and more comfortable to read, for example, try-catch block, where you need to set a variable in the “try” part and rethrow an enhanced error in the “catch” part.

These things and more are improving the readability significantly.

Additionally, the ability to have first-class immutable variables and nullable/non-nullable types eliminates whole classes of possible mistakes and errors. It is fantastic!

Stand on the shoulders of the giants!

Most of the modern languages are created to be used standalone, detached from the existing library and tooling ecosystem, either by design or “forced” by community guidelines or culture.

These modern languages might see some adoption, but they will eventually die out or stay in the small niche because the majority of professionals will just continue using the mature ones because they have better support for literally everything. There are rare, infrequent, exceptions from this rule.

If the new programming language wants to stay strong, it needs to stand on the shoulders of the giants.

So, instead of going against the former mature language, and doing everything differently, leverage as much as you can from the mature ecosystem, and add more value on top of that. This way, people, when learning this language don’t have to give up anything, and they only stand to gain— a real win-win situation!

Did that spike your curiosity about Kotlin?

I have written a 4-part (350-pages total) “Ultimate Tutorial: Getting Started With Kotlin” (+ more to come), and you can get it as a free bonus by becoming a member of my monthly newsletter.

On top of just Kotlin, it is full of goodies like TDD, Clean Code, Software Architecture, Business Impacts, 5 WHYs, Acceptance Criteria, Personas, and more.

—Sign up here and start learning how to build full-fledged Kotlin applications!

Thank you and ask for you!

Thank you so much for reading this article! I hope you enjoyed it. Please, tell me what you think about this in the comments!

Also, it would make me so much happier if you could share this post with your friends and colleagues who you think might benefit from it. Or you could share it on your favorite social media!

You are welcome to read my blog about Kotlin, and my blog about TDD and best software engineering practices.

And let’s connect on LinkedIn: I post short weekly updates about software developer’s productivity and happiness, teamwork, mental health, and a bit about Kotlin.

If you want to hear more of my opinions, follow me on Twitter.

Originally published on iwillteachyoukotlin.com blog.

cover image source: pexels

How Kotlin Calamity Devours Your Java Apps Like Lightning?

Alex Fedorov — Sat, 18 Nov 2017 22:18:29 +0000

Originally published on Hackernoon.

I hear what you are saying. There is that buzz around Android actively adopting Kotlin as a primary programming language. And trends don’t look good either.

Things on a web-development front are not by a bit better. Most popular web-framework in Java supports more and more idiomatic Kotlin as we speak by providing suitable APIs.

You can feel they are making their bet for the future.

And it seems that this future is closer than you think.

Now you are thinking. Should I make that bet, as well? Or is it just some hype that will die out in a year?

That little mixed controversial sensation in your heart. It just keeps worrying you.

You are unsure and afraid that if you don’t do something, then that new hire who is excited about Kotlin will convert your code base to Kotlin, and you’ll lose your productivity as a result.

That makes you worry about your job position.

On the contrary, you felt disappointed in previous programming language attempts to replace Java. You feel discouraged to trust new such attempt. There is no chance a new language can make its way to most of the legacy code bases or is there?

Perhaps, you feel curious about why tech giants (such as Google and Spring Team) place their bet on Kotlin.

Could it be that you are new to the code base, and still learning some new technologies you haven’t used before? And there are few Kotlin enthusiasts on your team, who have already started converting Java code to Kotlin code?

And the rate of said conversion is alarming?

That makes you feel confused and angry. You already have a lot of moving parts that you have to learn on your plate. That just adds more.

If you don’t spend time learning Kotlin, you are afraid that you’ll have to transfer to a different project, which still uses Java. For now.

If you do learn Kotlin, you are terrified it will be time wasted, as it will not take off as everyone promises.

I know, right?

How Can That New Team Member Convert The Whole Code Base to Kotlin in a Few Months?

So can one team member make such a drastic change to your legacy code base?

I mean, it is huge! There is no way a person can convert it all in the new language. So I can always stay mostly productive because the majority of the code will be in Java, right?

Wrong!

For you to understand how quickly Kotlin can consume your legacy Java application, I’m going to attach this image. It describes perfectly what I’ve seen so far:

“How quickly Kotlin consumes Java applications.” (source: https://www.pexels.com/photo/blue-clouds-color-danger-268774/)

Kotlin is the programming language built by JetBrains. They have quite a vast Java code base, as well. They made it their mission to create a language that they can use today in their code base. Not just for the new features.

How do you convert a Java file to Kotlin then?

Probably, you write the same thing again in the new language. Then make all tests pass. That is pretty time-consuming. No way your project manager will allow such effort without a strong reason. Right?

Nope.

One hotkey.

You’ve heard me right. It takes one keypress in IntelliJ to convert the Java file to Kotlin file. And in 99% of the cases, all the tests will still pass.

You know what’s scarier?

That works for the whole package, as well…

Let me tell you a story.

I have joined the project that had such a Kotlin enthusiast. They have convinced other team members to “try out” Kotlin for a single feature.

The project was two and half years old. The size of a project was big enough to have multiple Gradle modules, and start extraction of some independent services.

In two months nobody on the team was writing any Java anymore. Any Java file that needed to be changed to implement a user story was converted to Kotlin on sight.

It is important to say that team’s velocity didn’t drop during these two months, as it didn’t take much time and effort to do the conversion. Especially, for Kotlin enthusiasts. They do such conversions all the time.

Let me tell you another story.

This time it was a non-successful conversion to Kotlin, for a change. But there is a catch, though.

A few Kotlin enthusiasts joined the team at the same time. As they were already pretty experienced in converting Java to Kotlin, they just started doing it.

The other half of team members were still learning the tech stack, as they were quite new on that code base. Kotlin was just adding other moving parts.

They have resisted the change to Kotlin. The team agreed not to continue the conversion, as it will slow down getting these team members up to speed with already existing technology.

But here is the catch.

Upon one-on-one conversation, these team members liked Kotlin. And they were open to continuing the conversion once they feel more comfortable with the tech stack.

I’m pretty confident in about half a year they will stop writing any Java, as well.

Let me tell you the last story for today.

It was a long-running project. Quite big and complex. I would consider it a legacy Java code base with more than ten macro-services (notice “macro” — not “micro”).

One day, two team members asked a Kotlin enthusiast to help them try out Kotlin. They were curious because of all the buzz on the internet. And because that Kotlin enthusiast radiated passion about Kotlin.

You can guess what has happened.

In five months, nobody was writing Java code anymore on that team. Same story.

And you know what is even more terrifying about that conversion? Once you’ve converted to Kotlin and started using Kotlin-exclusive features, it becomes hard to convert that code back to Java.

There were enough of these would-be Java replacements in the past. And they’ve all failed to deliver on that promise.

So what so different about Kotlin?

How is This Java Replacement Attempt Different From Previous?

A few words.

100% Java interoperability.

You can easily have a mix of Kotlin and Java files in the same directory.

Java can import Kotlin classes and use them as if they were Java classes without any weird syntax or tricks. The same goes for Kotlin. Kotlin code can import any of your Java classes and use them regularly as if they were Kotlin classes.

There are no weird things like object.field_$eq(value) to set a value.

To invoke a Java setter from Kotlin, you will use Kotlin syntax: object.field = value. And to invoke a Kotlin setter from Java, you will just use normal setter method: object.setField(value).

Kotlin code can implement Java interfaces and Java code can implement Kotlin interfaces.

Kotlin has that interoperability as a top-priority feature of the language. That is because JetBrains team wanted to use Kotlin on their vast Java codebase right away. And without any pain.

That enables you to convert only a single class from Java to Kotlin and not trigger humongous cascading changes. Sometimes you would still want to convert a few related files, but you don’t have to.

Another reason why Kotlin is more likely to deliver on the promise of replacing Java is build tooling.

Kotlin doesn’t need any unique build tooling. A Maven or Gradle plugin is sufficient.

Moreover, Kotlin’s build times are extremely fast. It can be even faster than Java if you have incremental compilation enabled!

Alright. As you can see, there are not so much of negative points on the scale of the trade-off with Kotlin.

So what is on the positive side of the scale? What do you get when you stop writing Java and start writing Kotlin?

So why tech giants like Android and Spring are placing their bet on Kotlin?

So Why Tech Giants Are Placing Their Bet on Kotlin?

Kotlin language is concise. It is concise without losing the readability of Java. Kotlin removes all the boilerplate that you see in a regular Java or Android application.

Ever wanted stream API to be available directly on collection objects? Kotlin has that. Its standard library extends quite a few standard Java classes with additional functionality.

That reduces boilerplate by a lot. Where you had to create five different classes to read a stream, Kotlin allows you just to do what you expect. To read that stream.

Kotlin is safer than Java. It promotes nullability to the type system. That means that compiler can statically analyze your code and if you have a chance of a null-pointer exception somewhere — Kotlin code won’t compile.

And these nullability checks are not even annoying like they are in other languages.

That is thanks to smart casts. Let me show you an example:

Compile error because quiz variable can be null

Because quizStorage.load(quizId) returns Quiz? (a nullable Quiz) the compiler complains that you can’t directly call methods on quiz variable because it can be null.

So to make the compiler happy you will need to add a null check:

By adding null-check we are fixing the compile error and making quiz “smart-casted” to non-nullable

As you can see, quiz.moveToNextQuestion() is highlighted in a “special” way. If you hover over that variable, it will tell you that it has been smart-casted to Quiz type.

Because compiler knows now, that quiz variable cannot be null at this point.

In different languages with nullable types, you typically need to unwrap the nullable value to non-nullable. Even after you made a null-check!

Such unwrap operation is unsafe. And therefore, another programmer (including your future self) won’t be warned if they remove your null-check.

Smart casts are cool with that. As soon as someone removes the null-check — there will be a compile error.

And there is a much more concise way to write the same thing — elvis operator ?::

Most null-checks can be eliminated using elvis operator to further simplify the code

By the way, these examples are from my Ultimate Tutorial: Getting Started With Kotlin. It is a three-part tutorial in the form of e-book totaling 260 (and more in the future) pages of hands-on content that you can follow along.

By this point, if you are interested in learning Kotlin, download that Ultimate Kotlin Tutorial as a PDF here.

Not only you are going to get hands-on content from which you will learn to program in Kotlin. You will be able to ask me any question when you are stuck, and I will help you.

Anyways. What is there more to Kotlin benefits?

Apparently, if you spend enough time writing Kotlin, you will start writing more readable and robust Java code, as well.

That is an interesting side-effect, isn’t it?

A few friends of mine, even told me, that they would prefer to hire Kotlin developer over Java developer for the project that is all Java and doesn’t have Kotlin at all.

Moreover, Kotlin took a lot of principles from “Effective Java” book and converted them to basic language concepts. So by just writing Kotlin for some time, you are going to learn how to write a better Java code. Not so bad, right?

So what about the tooling? Is it easy to use Kotlin? Or will I have to give up my refactoring and Intelligent powers of my IDE to code in Kotlin?

Am I going to have to write it like in a text editor again?

No.

Kotlin is made by JetBrains. It is the same company that made IntelliJ IDEA. They did their hardest to make sure you will feel at home when using Kotlin in IntelliJ.

Current support is humongous. All the essential refactorings are already in place.

And, as we speak, they add more and more.

So is it a good time to learn some Kotlin now?

Is it a Good Idea For You to Learn Kotlin Right Now?

Of course, you will need to decide.

If you were to ask me… In your shoes, I would go for it. Here is why.

Even if Kotlin doesn’t deliver on the promise of replacing Java in most of the legacy code bases (or even for new ones), I know I’ve become a better Java programmer.

Only that should make it worthwhile. Do you need more?

I have that for you.

For a programmer it is always worthwhile to be learning another language at any point in time. The only exception is if you are only just starting out.

So if you are comfortable with your language, tech stack, and everything, and you are not learning any other programming language at the moment, it is a great idea to get your hands dirty with Kotlin.

It is going to put things into perspective and take you out of your current bubble. It is always good.

Learning is a skill. So the more you learn, the better and more efficient learner you become.

Perhaps, you think you don’t have the time to learn a new skill because you have a full-time job, family, hobby, and everything else in your life?

Then you should learn how to find the time to learn a new skill when you are working full-time.

If you think you are up to the challenge of upgrading yourself from Java developer to Kotlin developer, download the Ultimate Tutorial: Getting Started With Kotlin.

I genuinely thank you for reading, and I encourage you to give Kotlin a try. You have nothing to lose, anyway. And you can only benefit from that.

If you want to make me happy, then you can share it with your friends, on social networks, hacker news, Reddit, etc.

Originally published on Hackernoon.

How To Never Fail At The Fizzbuzz Interview Challenge

Alex Fedorov — Wed, 11 Oct 2017 20:11:32 +0000

Ah, the classic FizzBuzz coding challenge.

I’ve decided to include this picture to get your attention. Oh, and also because it associates with the “Buzz” part of the challenge.

“Buzz” – alarm clock…

Onward! Do you know that you don’t have even a single excuse to fail at one of these? So you think that you know that coding kata well?

Let your imagination run wild:

You are at the coding interview, and the interviewer has just asked you to implement FizzBuzz and given you the following problem description:

Write a program that prints a sequence of numbers from 1 to N.

Every number that divides by the three should appear as “Fizz.”

Every number that divides by the five should appear as “Buzz.”

Every number that divides by the three and the five should appear as “FizzBuzz.”

– anonymous interviewer

A piece of cake!

So you are writing away, and the code is pouring out of you…

Five or ten minutes in and you are done. You feel the interviewer might just suspect that you were ready for the challenge. In that case, they will have some additional unexpected requirements for you.

Just like in the real world programming.

Continue reading, and we will explore these additional requirements and possible solution for them. And for now, we will solve the FizzBuzz challenge in Kotlin.

It is probably a good idea to have some automated tests so that we know when we are done. Let’s create a new test suite in JUnit4:

import org.junit.Assert.*
import org.junit.Test

@Suppress("FunctionName")
class FizzBuzzTest {

}

Now we are going to write a first test – the simplest one, that covers the fact that we can produce a normal number sequence without any “fizzes” or “buzzes”:

@Test
fun `simple numbers`() {
    // ARRANGE
    val fizzBuzz = FizzBuzz()

    // ACT
    val sequence = fizzBuzz.generateSequence(size = 2)

    // ASSERT
    assertEquals(listOf("1", "2"), sequence)
}

I like to split my tests in three sections: arrange, act and assert. It is not necessary to write out loud these comments as I do here. I don’t usually do myself so, but I think about these three sections when constructing a good test.

On the other hand, I highly recommend you DO split your tests in such three sections. And write down these comments too for the sake of explicitness.

If you are already comfortable writing great tests, feel free to ignore my advice.

Onward! There are few compile errors in this test that we will need to deal with. First, we haven’t defined FizzBuzz class yet. Second, we will need to create the generateSequence method.

Just to make things compile, we will make that method return an empty list:

class FizzBuzz {

    fun generateSequence(size: Int): List<String> {
        return emptyList()
    }

}

Now we can run our test. As expected, it fails because we are expecting a list with two items ["1", "2"], but we are getting an empty list [].

Making this pass is pretty simple. We are going to generate a sequence from one to size using Kotlin’s range syntax:

1..size

Then we are going to generate a new sequence out of it by calling toString() method on every item of that sequence. To do that we are going to employ map function defined on any Kotlin sequence:

fun generateSequence(size: Int): List<String> {
    return (1..size).map { it.toString() }
}

Oh, by the way.

Wondering what all these neat features of Kotlin are? Maybe you want to learn how to build a full-fledged application in Kotlin?

I have accidentally written this 80-page hands-on getting started tutorial for Kotlin. Feel welcome to download the free PDF Ultimate Tutorial: Getting Started With Kotlin. You are going to learn how to build a full-fledged command-line application in Kotlin. You’ll get free access preview for Web app and Android app tutorials, as well!

Anyways, we should run our tests now.

And they all pass.

Alright. Our next step is to start handling some “fizz” numbers. For that, we can write a new test. It is as simple as copy-pasting (oh no!) the previous test and making some modifications to it:

@Test
fun `fizz numbers`() {
    // ARRANGE
    val fizzBuzz = FizzBuzz()

    // ACT
    val sequence = fizzBuzz.generateSequence(size = 4)

    // ASSERT
    assertEquals(listOf("1", "2", "Fizz", "4"), sequence)
}

Now we are going from one to four, and we are expecting all numbers to be normal except for number three. It should become “Fizz” in the generated sequence.

If we run this test, it is going to fail, because so far we are producing only simple numbers converted to strings.

To make this test pass we are going to extract it.toString() part into a private method generateMethod(number: Int): String. We will add an “if” statement to handle the case when the number divides by three:

fun generateSequence(size: Int): List<String> {
    return (1..size).map { generateNumber(it) }
}

private fun generateNumber(number: Int): String {
    if (number % 3 == 0) {
        return "Fizz"
    }

    return number.toString()
}

It passes the test suite now.

Next, we would like to write a test for the “Buzz” requirement. For that, we are going to generate a sequence from one to fourteen. There will be a few “fizzes” and “buzzes” there.

No “fizzbuzzes” yet, though.

@Test
fun `buzz numbers`() {
    // ARRANGE
    val fizzBuzz = FizzBuzz()

    // ACT
    val sequence = fizzBuzz.generateSequence(size = 14)

    // ASSERT
    assertEquals(listOf(
            "1", "2", "Fizz", "4", "Buzz",
            "Fizz", "7", "8", "Fizz", "Buzz",
            "11", "Fizz", "13", "14"), sequence)
}

That test fails because we are not producing any “buzzes” yet. We will add another “if” statement to handle that case:

private fun generateNumber(number: Int): String {
    if (number % 3 == 0) {
        return "Fizz"
    }

    if (number % 5 == 0) {
        return "Buzz"
    }

    return number.toString()
}

And the test is passing.

Finally, we want to write a test involving some “fizzbuzzy” numbers. In this case, we want to generate a sequence from one to thirty-one, so that we include at least two of these:

@Test
fun `fizz buzz numbers`() {
    // ARRANGE
    val fizzBuzz = FizzBuzz()

    // ACT
    val sequence = fizzBuzz.generateSequence(size = 31)

    // ASSERT
    assertEquals(listOf(
            "1", "2", "Fizz", "4", "Buzz",
            "Fizz", "7", "8", "Fizz", "Buzz",
            "11", "Fizz", "13", "14", "FizzBuzz",
            "16", "17", "Fizz", "19", "Buzz",
            "Fizz", "22", "23", "Fizz", "Buzz",
            "26", "Fizz", "28", "29", "FizzBuzz",
            "31"), sequence)
}

And of course it does not work.

That is because the first “if” statement (for “fizzes”) catches this case and produces “Fizz.” To fix that we will have to write a new “if” statement that handles the case for “fizzes” and “buzzes” at the same time.

That case will have to be checked before all others. That way, nor “Fizz,” nor “Buzz,” will match before it:

private fun generateNumber(number: Int): String {
    if (number % 3 == 0 && number % 5 == 0) {
        return "FizzBuzz"
    }

    if (number % 3 == 0) {
        return "Fizz"
    }

    if (number % 5 == 0) {
        return "Buzz"
    }

    return number.toString()
}

Alrighty! All tests are passing now.

Let’s extract some duplication in the test suite. Notably, the ARRANGE part. That is because it is the same for every single test. We will promote fizzBuzz local variable to the private field of the test suite class:

import org.junit.Assert.*
import org.junit.Test

@Suppress("FunctionName")
class FizzBuzzTest {

    private val fizzBuzz = FizzBuzz()

    @Test
    fun `simple numbers`() {
        // ACT
        val sequence = fizzBuzz.generateSequence(size = 2)

        // ASSERT
        assertEquals(listOf("1", "2"), sequence)
    }

    @Test
    fun `fizz numbers`() {
        // ACT
        val sequence = fizzBuzz.generateSequence(size = 4)

        // ASSERT
        assertEquals(listOf("1", "2", "Fizz", "4"), sequence)
    }

    @Test
    fun `buzz numbers`() {
        // ACT
        val sequence = fizzBuzz.generateSequence(size = 14)

        // ASSERT
        assertEquals(listOf(
                "1", "2", "Fizz", "4", "Buzz",
                "Fizz", "7", "8", "Fizz", "Buzz",
                "11", "Fizz", "13", "14"), sequence)
    }

    @Test
    fun `fizz buzz numbers`() {
        // ACT
        val sequence = fizzBuzz.generateSequence(size = 31)

        // ASSERT
        assertEquals(listOf(
                "1", "2", "Fizz", "4", "Buzz",
                "Fizz", "7", "8", "Fizz", "Buzz",
                "11", "Fizz", "13", "14", "FizzBuzz",
                "16", "17", "Fizz", "19", "Buzz",
                "Fizz", "22", "23", "Fizz", "Buzz",
                "26", "Fizz", "28", "29", "FizzBuzz",
                "31"), sequence)
    }

}

If we run the tests, they should still pass. As our next step, we should take a careful look if there is any duplication in the production code.

And there is some!

The checks for “fizziness” and “buzziness” are duplicated between “fizzbuzz” case handler and corresponding “fizz” or “buzz” case handler. Simplest refactoring we can do is to extract these into private functions:

private fun generateNumber(number: Int): String {
    if (isFizz(number) && isBuzz(number)) {
        return "FizzBuzz"
    }

    if (isFizz(number)) {
        return "Fizz"
    }

    if (isBuzz(number)) {
        return "Buzz"
    }

    return number.toString()
}

private fun isBuzz(number: Int) = number % 5 == 0

private fun isFizz(number: Int) = number % 3 == 0

At that point, you were about to refactor some more, for example, extract magic strings to constants.

But the interviewer told you it is enough refactoring.

You see they are impressed. You have finished earlier after all. But you feel as if the interviewer is a little bit suspicious. It is a classic exercise after all.

So they decide to give you an additional requirement!

A number should also be “Fizz” if it contains digit “3.”

A number should also be “Buzz” if it contains digit “5.”

A number should also be “FizzBuzz” if it contains both.

– anonymous interviewer

Oh, no!

Nobody told you there could be more…

Don’t fret! We are going to go through that. Let’s add a new test for the “Fizz” part with the new requirement.

We are going to generate the sequence until 32. Some numbers, which weren’t “Fizz” before, will become such:

@Test
fun `fizz numbers that just contain digit '3'`() {
    // ACT
    val sequence = fizzBuzz.generateSequence(size = 32)

    // 13 becomes Fizz
    // 23 becomes Fizz
    // 31 becomes Fizz
    // 32 becomes Fizz

    // ASSERT
    assertEquals(listOf(
            "1", "2", "Fizz", "4", "Buzz",
            "Fizz", "7", "8", "Fizz", "Buzz",
            "11", "Fizz", "Fizz", "14", "FizzBuzz",
            "16", "17", "Fizz", "19", "Buzz",
            "Fizz", "22", "Fizz", "Fizz", "Buzz",
            "26", "Fizz", "28", "29", "FizzBuzz",
            "Fizz", "Fizz"), sequence)
}

Of course, the test is failing.

To make it pass we will need to modify the function isFizz appropriately. You should include the check for “it contains digit 3” on top of the original condition. In boolean logic (last time I checked) it was an “OR” operation between those two conditions:

private fun isFizz(number: Int) =
        number % 3 == 0 || number.toString().contains('3')

Note the number.toString().contains('3') part. The test is passing now. But a few of other tests are failing!

Oh no!

We will have to fix those tests. We should replace numbers containing digit “3” with “Fizz”:

@Test
fun `buzz numbers`() {
    // ACT
    val sequence = fizzBuzz.generateSequence(size = 14)

    // ASSERT
    assertEquals(listOf(
            "1", "2", "Fizz", "4", "Buzz",
            "Fizz", "7", "8", "Fizz", "Buzz",
            "11", "Fizz", "Fizz", "14"), sequence)
}

@Test
fun `fizz buzz numbers`() {
    // ACT
    val sequence = fizzBuzz.generateSequence(size = 31)

    // ASSERT
    assertEquals(listOf(
            "1", "2", "Fizz", "4", "Buzz",
            "Fizz", "7", "8", "Fizz", "Buzz",
            "11", "Fizz", "Fizz", "14", "FizzBuzz",
            "16", "17", "Fizz", "19", "Buzz",
            "Fizz", "22", "Fizz", "Fizz", "Buzz",
            "26", "Fizz", "28", "29", "FizzBuzz",
            "Fizz"), sequence)
}

Hold on a second… Doesn’t this feel weird to you?

Yeah, I think this last case covers all our edge cases. That is because it (kind of) includes all other tests. So you should get rid of those tests!

Oh, and don’t forget to demote the private field fizzBuzz back to the local variable.

Here we go:

import org.junit.Assert.*
import org.junit.Test

@Suppress("FunctionName")
class FizzBuzzTest {

    @Test
    fun `generating fizz buzz sequence`() {
        // ARRANGE
        val fizzBuzz = FizzBuzz()

        // ACT
        val sequence = fizzBuzz.generateSequence(size = 32)

        // ASSERT
        assertEquals(listOf(
                "1", "2", "Fizz", "4", "Buzz",
                "Fizz", "7", "8", "Fizz", "Buzz",
                "11", "Fizz", "Fizz", "14", "FizzBuzz",
                "16", "17", "Fizz", "19", "Buzz",
                "Fizz", "22", "Fizz", "Fizz", "Buzz",
                "26", "Fizz", "28", "29", "FizzBuzz",
                "Fizz", "Fizz"), sequence)
    }

}

Now we want to implement final two requirements.

For that let’s change our test to go until 53, so we hit more attractive edge cases. And some of the numbers will become “Buzz” and some other numbers ought to become “FizzBuzz” now.

See for yourself:

@Test
fun `generating fizz buzz sequence`() {
    // ARRANGE
    val fizzBuzz = FizzBuzz()

    // ACT
    val sequence = fizzBuzz.generateSequence(size = 53)

    // 35 became FizzBuzz
    // 51 became FizzBuzz
    // 52 became Buzz
    // 53 became FizzBuzz

    // ASSERT
    assertEquals(listOf(
            "1", "2", "Fizz", "4", "Buzz",
            "Fizz", "7", "8", "Fizz", "Buzz",
            "11", "Fizz", "Fizz", "14", "FizzBuzz",
            "16", "17", "Fizz", "19", "Buzz",
            "Fizz", "22", "Fizz", "Fizz", "Buzz",
            "26", "Fizz", "28", "29", "FizzBuzz",
            "Fizz", "Fizz", "Fizz", "Fizz", "FizzBuzz",
            "Fizz", "Fizz", "Fizz", "Fizz", "Buzz",
            "41", "Fizz", "Fizz", "44", "FizzBuzz",
            "46", "47", "Fizz", "49", "Buzz",
            "FizzBuzz", "Buzz", "FizzBuzz"), sequence)
}

To make this pass, we will need to add similar condition to the isBuzz private function. Notice the number.toString().contains('5') part.

private fun isBuzz(number: Int) =
        number % 5 == 0 || number.toString().contains('5')

The tests are back to green now (they pass).

Don’t you notice how isBuzz and isFizz functions have a similar structure? Don’t you think we should be able to extract that structure?

Let’s do it!

First, we will extract dividesBy(number, divider) private function:

private fun isBuzz(number: Int) =
        dividesBy(number, 5) || number.toString().contains('5')

private fun isFizz(number: Int) =
        dividesBy(number, 3) || number.toString().contains('3')

private fun dividesBy(number: Int, divider: Int) =
        number % divider == 0

Second, we will extract containsDigit(number, digit) private function.

private fun isBuzz(number: Int) =
        dividesBy(number, 5) || containsDigit(number, 5)

private fun isFizz(number: Int) =
        dividesBy(number, 3) || containsDigit(number, 3)

private fun containsDigit(number: Int, digit: Int) =
        number.toString().contains(digit.toString())

Note how digit here is not a character or string. It is an integer.

That way, we should be able to extract the whole structure (dividesBy or containsDigit) out of those two functions.

Here we go:

private fun isBuzz(number: Int) =
        dividesOrContainsDigit(number, 5)

private fun isFizz(number: Int) =
        dividesOrContainsDigit(number, 3)

private fun dividesOrContainsDigit(number: Int, digit: Int) =
        dividesBy(number, digit) || containsDigit(number, digit)

Your interviewer is not stopping your refactoring yet. So maybe he is out of requirements?

Thank goodness!

Finally, you can do that magic strings extraction refactoring! For that, we will extract “Fizz” and “Buzz” strings out of respective edge cases. And from the “fizzbuzzy” one too:

companion object {
    private val FIZZ = "Fizz"
    private val BUZZ = "Buzz"
    private val FIZZ_BUZZ = "$FIZZ$BUZZ"
}

private fun generateNumber(number: Int): String {
    if (isFizz(number) && isBuzz(number)) {
        return FIZZ_BUZZ
    }

    if (isFizz(number)) {
        return FIZZ
    }

    if (isBuzz(number)) {
        return BUZZ
    }

    return number.toString()
}

So why are we extracting these magic strings, anyway?

You might ask that yourself…

Or is it just the interviewer asking you that question?

Probably, because you want to make it easy to change one of these strings in just one place, don’t you?

And that is where the thought strikes you! What if I need to change “Fizz” to “Fizzy”?

Yep.

I’ll have to fix all these occurrences in the test suite.

Annoying!

Let’s replace all the magic strings in the test too. We will have to promote these private constants FIZZ, BUZZ, and FIZZ_BUZZ to internal access level so that that the test can access them:

companion object {
    internal val FIZZ = "Fizz"
    internal val BUZZ = "Buzz"
    internal val FIZZ_BUZZ = "$FIZZ$BUZZ"
}

And finally, we are going to replace the string occurrences in the test suite:

import FizzBuzz.Companion.BUZZ
import FizzBuzz.Companion.FIZZ
import FizzBuzz.Companion.FIZZ_BUZZ
import org.junit.Assert.*
import org.junit.Test

@Suppress("FunctionName")
class FizzBuzzTest {

    @Test
    fun `generating fizz buzz sequence`() {
        // ARRANGE
        val fizzBuzz = FizzBuzz()

        // ACT
        val sequence = fizzBuzz.generateSequence(size = 53)

        // ASSERT
        assertEquals(listOf(
                "1", "2", FIZZ, "4", BUZZ,
                FIZZ, "7", "8", FIZZ, BUZZ,
                "11", FIZZ, FIZZ, "14", FIZZ_BUZZ,
                "16", "17", FIZZ, "19", BUZZ,
                FIZZ, "22", FIZZ, FIZZ, BUZZ,
                "26", FIZZ, "28", "29", FIZZ_BUZZ,
                FIZZ, FIZZ, FIZZ, FIZZ, FIZZ_BUZZ,
                FIZZ, FIZZ, FIZZ, FIZZ, BUZZ,
                "41", FIZZ, FIZZ, "44", FIZZ_BUZZ,
                "46", "47", FIZZ, "49", BUZZ,
                FIZZ_BUZZ, BUZZ, FIZZ_BUZZ), sequence)
    }

}

All your tests should be green at this point.

Did you need to do all these refactorings?

Not necessarily.

Do you need to know how to do them, so that you are ready for any requirement change?

Absolutely!

Here is the final production code:

class FizzBuzz {

    companion object {
        internal val FIZZ = "Fizz"
        internal val BUZZ = "Buzz"
        internal val FIZZ_BUZZ = "$FIZZ$BUZZ"
    }

    fun generateSequence(size: Int): List<String> {
        return (1..size).map { generateNumber(it) }
    }

    private fun generateNumber(number: Int): String {
        if (isFizz(number) && isBuzz(number)) {
            return FIZZ_BUZZ
        }

        if (isFizz(number)) {
            return FIZZ
        }

        if (isBuzz(number)) {
            return BUZZ
        }

        return number.toString()
    }

    private fun isBuzz(number: Int) =
            dividesOrContainsDigit(number, 5)

    private fun isFizz(number: Int) =
            dividesOrContainsDigit(number, 3)

    private fun dividesOrContainsDigit(number: Int, digit: Int) =
            dividesBy(number, digit) || containsDigit(number, digit)

    private fun containsDigit(number: Int, digit: Int) =
            number.toString().contains(digit.toString())

    private fun dividesBy(number: Int, divider: Int) =
            number % divider == 0

}

I genuinely thank you for reading, and I encourage you to practice your basic foundations.

There are tons of different challenges for that on websites like http://codingdojo.org/kata/ and http://kata-log.rocks. Huge thank you to creators and maintainers!

Liked this article? – Share it with your friends, on social media, hacker news, Reddit, etc. If you are interested in Kotlin, check out more of my stuff on Kotlin.

DEV Community: Alex Fedorov

When Is the Perfect Time to Move on as a Developer?

20yrs of experience or 1yr repeated 20 times?

Problem: wasting experience years

Hello, dear skeptic

Practice and get better at what you’re already doing

Get more responsibilities

Get more skills

What you SHOULD NOT do

It’s time to move on

Go independent

Conclusion

Now it’s your turn!

How have I ensured the privacy and anonymity of my website users? 🤔

This is not good enough! How can we do better?

Assymetric encryption

Passphrase-encrypted private key

Thank you for reading!

How Can Hierarchical Test Structure Absolutely Make a Mess?

Two Fetchers, elusively alike

Conclusion

Your Turn

9 Rules of Effective Development Team Meetings

1. Early in the morning, right after the stand-up.

2. Short. Non-negotiable time limit.

3. The 2nd best decision is better than no decision at all.

4. Minimum viable audience.

5. No meeting without an Agenda

6. Rule of the two feet

7. No phubbing. No screens allowed other than presenter’s one.

8. Have a facilitator

9. Manage your manager/stakeholder… if you have to

Why Are Some Developers so Allergic to IDEs?

How to Try Kotlin in Java Backend Codebase Without Risk

Mixing Java and Kotlin code

Add Kotlin support to Gradle

1. Use Elvis operator instead of most null checks

2. Convert Optionals to nullable

3. Make JUnit test names more readable

4. Use lateinit instead of nullable

5. Use named arguments for readability

6+. There is so much more you can improve!

Trying out without any risks whatsoever

Thank you and ask for you!

Kotlin: How Can a Programming Language be so Young And so Mature at The Same Time?

Why new modern languages can’t be adopted quickly?

Why these languages don’t want to rely on the existing mature ecosystem?

How to attract different early adopters that will be happy to leverage existing ecosystem?

Small story of a fellow software engineer

Most important playing field rules fostering the adoption

Stand on the shoulders of the giants!

Thank you and ask for you!

How Kotlin Calamity Devours Your Java Apps Like Lightning?

How Can That New Team Member Convert The Whole Code Base to Kotlin in a Few Months?

How is This Java Replacement Attempt Different From Previous?

So Why Tech Giants Are Placing Their Bet on Kotlin?

Is it a Good Idea For You to Learn Kotlin Right Now?

How To Never Fail At The Fizzbuzz Interview Challenge

2. Convert `Optional`s to nullable

4. Use `lateinit` instead of nullable