DEV Community: Daniel Rendox

How to not mess up your first project

Daniel Rendox — Tue, 12 Mar 2024 15:02:20 +0000

Short answer: That’s simply not possible. We’re all humans so it’s hard to make something good on the first try. But it’s possible to minimize the number of mistakes and effectively fix everything later.

I've recently completed writing my latest program, and I must say, it's one of the most decent ones I've ever created. However, it wasn’t without its challenges and I hit the wall quite a few times. This experience taught me several valuable lessons, which I'll be sharing in this article. Here, you won’t find a bunch of cliche advice from ChatGPT but rather practical insights gained from my mistakes.

Thoroughly think over everything before writing any code

The program I was working on is a habit-tracking app. Not a simple one though. The matter is, many habit trackers and planner apps out there do not work as I’d expect. When I miss completing the habit on a due date, I expect the program to tell me about this backlog later. And vice versa, when I complete a habit on a non-due day, I want the next scheduled occurrence to be canceled. So I created my own that does exactly that.

It also calculates a habit streak. And after all calculations, it should look something like this:

Sounds simple in theory but in reality, you’re gonna hit some major pitfalls. To determine habit dueness, it’s not enough to check whether it’s due on the current date or not. If the habit has been over-completed previously, we want to cancel the current occurrence. And if the habit was failed on a certain date, we can’t surely say it’s failed because this backlog may have been sorted out later.

So how do we determine whether it’s actually due or not? By calculating the number of times it should’ve been completed and then comparing it with the actual number of completions? How do we calculate these numbers? By checking whether each date is due or not? Is it performant? How do we store all of these in a database? And remember that the results will be different depending on whether the given date is in the future or in the past. Finally, how do we then calculate streaks?

So, instead of thinking over all of those, I decided to write the code first. And, honestly, it didn’t turn out well. 🫠 I ended up creating an architecture where

it wasn’t possible to compute habit status for a certain date without affecting other dates;
I had to compute everything up to the current date;
and the worst part, all this was stored persistently so I had to somehow update everything every time something changed.

I won’t go into the details of how awfully everything was implemented, but trust me, it was simply unmanageable.

That’s why we have to thoroughly think through every aspect of a project before touching the keyboard. While it might seem like a slower approach, I now understand that it leads to cleaner, more efficient code that is far easier to maintain and extend. Because it’s usually a lot more complicated than we think it is. Rushing to write the implementation will often lead to a huge amount of time spent for refactoring later. For this very reason, seniors spend a lot more time thinking than juniors.

Also, our thoughts do not extend to every single edge case. That’s where AI comes into play! It’s a good thing to ask AI about that, especially if you don’t have anyone else to discuss it with. I discovered that just recently when I asked about my next project’s implementation. And it dropped some really good points, which I’d otherwise not consider.

Adding features is easy, but maintaining them is hard

Some functionality may not be as useful as it seems. I had to drop some of my app's features because they were not worth the effort. I learned to avoid adding or expanding features on a whim or without a clear purpose. Be a lazy developer!

The thing is, even if some functionality seems easy to add, you have to remember that you will also have to maintain it, fix bugs, test and enhance it, integrate it with the rest of the app, optimize its performance, make sure it works on different devices, and so on. It will be frustrating if you eventually realize that you have to drop this functionality because it is not needed by the user or it actually hurts the user experience.

Follow git best practices

When I started working on my project, I didn't have a clear plan in mind. I was jumping from one task to another, resulting in a messy codebase because everything was done all at once. I ended up building on top of functionality that wasn’t working properly and wasn’t tested thoroughly. Debugging such a structure was also quite challenging. Not only could I not identify what wasn't working, but I also struggled to easily revert to the latest working state.

What I've learned is that it's crucial to have a clear goal for each part of the project and to focus on one task at a time. After completing a small chunk of work, test it thoroughly — either manually or automatically — to ensure it functions correctly. Only then should you move on to the next task.

This approach aligns perfectly with git best practices—making your commits small so that you can easily pinpoint the exact change that caused the issue. With this method, you’ll also be able to roll back to a previous commit without losing unrelated work.

I also discovered the power of pull requests. They are not only useful for team projects but also for personal ones. While you would typically want to keep your commits as small as possible, you can gather them in a pull request to form a feature. This way, you’ll have a clear separation of what you’re working on.

Whenever you start working on another feature, create a new branch and commit to it instead of committing directly to the main branch. And here’s the important part: you have to be confident in your code each time you hit the merge button. This ensures you don’t build further on top of broken code.

Adopting this workflow has other benefits. For example, you can leverage AI code reviews by setting up a GitHub action that will automatically review your pull requests. This way, you can discover things you might otherwise be unaware of because, after all, we don’t know what we don’t know.

This approach will also make it less tempting to make changes to unrelated code and instead focus on building the planned functionality. Follow the single responsibility principle!

Additionally, I suggest documenting your changes by writing descriptive commit messages. You’ll thank yourself in the future because future you won’t necessarily remember those details. You can also provide more context in the pull request details than you can in commit descriptions including images and videos.

What is actually an MVP

Finally, I made it work. And now Routine Tracker’s code is clean and works properly. But here comes the last insight from building this program.

When it was time to write the readme, I realized one important thing. I actually haven’t achieved the functionality I wanted to make initially. Apart from other habit-tracking apps, my app was supposed to display the habit’s progress and the estimated completion date. You see, I thought that I would first create a minimum viable product and then fill it with cool features.

However, what I discovered too late was that an MVP doesn’t presume a project with minimum features. It presumes a project with minimum functionality that is required to test whether people find your idea useful. So what kind of feedback can users give you if you provide an app that copies features from already existing projects and the only thing that differentiates your project is that it is immature and buggy? Instead, the MVP should contain those very features that set your app apart. In my case what I should’ve built first is habit’s progress and completion date estimation functionality.

How do you build those cool features if the foundation isn’t ready yet? The answer is in this tweet:

I was so focused on making that core functionality work that I forgot about the very purpose of the app. 😅 That was fine though because its core functionality is also kinda non-trivial.

Also, while pet projects are a playground for skill development, applying such business principles to them brings a whole new set of benefits. From faster development and preparation to a real-world scenario to these projects bringing more chances to give you a job.

Write the Readme first

You may have noticed that I gained the last insight while writing the readme. Why? Because the readme is where we have to outline the mission of our project, how it achieves it, and what makes it unique. So I had an opportunity to better think about that in the final stage of development. Cool, but it’s not very smart. What if we turn things around and write the readme on the planning stage of the project before writing any code? This is called Readme Driven Development and it’s not a new idea.

This also makes it possible to receive some initial feedback by sending this readme to other people and asking what they think.

👋 Hi, I’m Daniel

I’m a native Android developer. I’m currently focused on building a strong portfolio, improving my skills, and establishing an online presence. If you want to collaborate with me in any way, please let me know.

7 Key Insights That Made Me A Better Developer

Daniel Rendox — Thu, 22 Feb 2024 17:56:52 +0000

Throughout my software developer journey, I've had several "Aha!" moments, which made me take my skills to the next level. In this article, I'd like to share those realizations with you! I've arranged them in chronological order so that everything flows seamlessly from one topic to another. So we’re gonna start with the most newbie topic and then move to deeper insights.

How to choose your first programming language

I know that such decisions as choosing your first programming language are the most challenging ones. It’s like choosing what college program you’re gonna apply to, and what country you wanna move to. The challenge is that when you don’t know where to start, you just don’t know where to start. There is nothing you can do about that. Sadly, such confusion sometimes keeps people from starting in the first place.

But the good part is that if you’re just starting out, you don’t have to care about that. Seriously, my first language was Java only because I wanted to learn some programming and found a free boot camp where I was supposed to learn Java.

As a beginner, you need to understand that what actually matters is the tech stack you are working on. If you switch your tech stack, it’s almost a new world for you and you need to start all over again. But if you already know one programming language, it’s not an issue for you to learn another one. That means you can start by learning the essential concepts in any language you want and later decide which tech stack you want to proceed with.

And that’s what I did. After getting the hang of Java, I decided to delve into the world of Android development. And nowadays, there is no way to thrive in the realm of Android without the knowledge of Kotlin. So I had to learn Kotlin and I’m happy to say it didn’t take long because I already knew Java at the moment.

But wait a second. Have you already chosen the area you want to specialize in? For some reason aspiring devs struggle with the language-question and seem to not even think about what kind of products they actually want to develop. That may be making web apps, desktop apps, mobile apps, making games, developing artificial intelligence, etc. There are many options. And there is no secret solution to this. You’ll have to pick something that just feels closer to your heart! Or use can my next advice.

Alright, but you are an intelligent developer. You don’t want to pick the language randomly, do you? Plus, how do you approach this problem when you’re already at the stage where you need to choose your tech stack?

I think the most reasonable approach here is to choose one that will give you a job. So what I mean by that is you can research technologies for such factors as how many job openings there are, what are the salaries, what people think about the technology, what would they learn if they could start over, what are the trends, and so on. This way, you can figure out what is in demand and what is the most appropriate option for you. The situation may be different depending on where you live.

You can start with such websites as Stack Overflow Developer Survey or simply check out vacancies on LinkedIn, where you can also find out about the requirements for the job. In addition, you can find some sources that post info related to your location. For example, in Ukraine, we have dou.ua that shares insightful statistics.

And don’t just choose whatever is the most popular. If something is popular, it means that there is also a lot of competition for it. I used to be concerned that there aren't as many job openings for a native Android dev position as there are for, say, a web developer position. But if we think about it from another perspective, there also aren't nearly as many applicants. So mobile devs have much less competition now despite the saturated tech market.

Or consider another situation. You wanted to learn Spring Boot for example, but then you did a research and found out that .NET is actually in higher demand in your region, and there is less competition for it. So this way, you can discover such things and make an optimal decision for yourself.

The reason why I think choosing a technology that will give you a job is the best approach here is because you don’t have any personal preferences yet. Unfortunately, it’s impossible to determine whether you enjoy working with some technology or not before you dedicate a substantial amount of time to it. So job market demand is essentially the only decent criteria you have.

The choice is everywhere!

As you proceed in your programming journey you discover that choices are everywhere. You now need to choose between libraries, frameworks, and various coding practices. As much as there is choice, there are lots of people's opinions. For example, some people think native apps are better than cross-platform ones. Some people think that dynamically typed languages are preferable to statically typed languages. Some people think that doing everything in the command line is “the right way” of doing things. The list goes on and on.

Of course, every technology is there for a reason. Each one aims to solve some specific problem. But when it comes to choosing which one you’ll use for your project, the choice usually depends on

what kind of product one wants to make;
the current state of the project;
decisions that have been already made in the past;
personal preferences of the team members.

See why these decisions are tricky for beginners? They usually don’t have enough information to make them. One can research about what is more appropriate for them. However, a big part of such decisions usually depends on the insights gained from real-world experience. Because the devil is in the details. No article, video, or tutorial will open up all the potential pitfalls that you can face if you use some framework or library.

Programmers face these decisions every now and then. So how to deal with that? Well, IMO the wise approach for a beginner would be, again, choosing those technologies that they are more likely to use in the real job setting. For example, in Android development, these decisions are usually dictated by Google. Why is that? Because it is what is the first party, supported the most, and well documented. As a result, it's what people tend to use more often.

For example, when developing an Android app, you need to use some navigation library. There is an official solution but it’s not mature enough to satisfy all the needs. Many developers hate the absence of type safety in the official library. And some use third-party solutions instead. Does it mean that it’s better to learn a third-party library instead of the official one? Absolutely not! Because no matter how good that library is, it can’t compare with the official solution in terms of documentation, support, and the number of people that know this technology. Regardless of how much better other solutions are, many people will still choose whatever is recommended in the official documentation. And this makes you much better off using it as well. Plus, you’ll not understand why it’s sometimes not suitable if you don’t even try applying it.

The more experience you get, the wiser decisions you make. And remember: programmers can't agree on many topics so there is usually no “right approach”. “It depends” is usually the best answer in tech. In some cases, you will have to choose something that you feel is better, because you just don’t have any other criteria. This is cool too because you’ll get insights and form your own opinion about that.

At a certain point, this gave me a lot of freedom because I understood I could essentially do anything I wanted. I’m not restricted to what some other guy on the web thinks is right. I can make my own decisions. As long as I’m responsible for them, of course.

Tech is so opinionated!

Due to human nature, we tend to become addicted to our favorite toolset and propagate it not admiring the benefits of others. In my experience, this approach is neither good in programming nor in life. So it’s sad to hear something like “Why Java programmers hate python?”

Throughout my journey, I learned to ditch my personal preferences in a professional job setting and get out of my comfort zone. That’s because when you become addicted to your favourite tool set you stop developing and miss out on the opportunity to look at some things from another perspective. Programmers are lifelong learners and real programmers do not hate any technology. They understand that if something is the most optimal choice in their situation, they need to learn it and use it no matter whether they enjoy using it or not.

It’s easier to say that to do and not fall into that trap, so I’m gonna provide an example.

In mobile development, there is a term “native user experience” that typically requires a user interface that is native to a specific platform, super fast data loading, etc. In terms of user experience, websites usually can’t compete with that. However, in mobile development, we can instead use web views that essentially look the same as the mobile version of the website. But everything will get loaded a lot slower.

So should I as a mobile developer propagate using native components? I should, but only if the business requires it. Because most of the time the goal of the business is to quickly get the product into the hands of the customers and only then think about the user experience. And in terms of speed of development, webviews are many times faster.

I learned that from Donn Felker. A person who was a native Android developer in the past now propagates the Native where you need it approach, which involves first building everything with webviews and then gradually replacing them with native components in the parts of the app that require that.

So even though the web is not my area of specialty and it’s not what I like doing, shouldn’t I instead of arguing that native is better appreciate how convenient things are in web, how many developers know HTML, CSS, and JavaScript, and acknowledge the versatility they offer?

If a customer approaches you requesting a project within your area of expertise, and you recommend another technology that would better suit their needs, rather than simply agreeing for the sake of earning money, I believe you demonstrate a higher level of professionalism.

And as much as it’s not okay to hate some technology it’s also bad to become addicted to one. Better appreciate the whole variety of them and be eager to learn.

Don’t get stuck in the rabbit hole of learning everything

Tutorial hell is a common thing in tech. It happens because of people’s natural desire to stay in their comfort zone. Unfortunately, in our world, it’s hard to achieve something when you stay in your comfort zone. So in terms of learning programming, I think the #1 reason why tutorial hell happens is because one doesn’t want to make personal projects. This is absolutely convenient to stick to following some tutorials given that they indeed teach you stuff. But, as proven by science, we start to remember and understand something only when we question it or when we try to apply that in practice.

For example, when it comes to learning a foreign language, I noticed that learners who don't rely on their tutor too much, have intrinsic motivation, and are willing to investigate something on their own become much more successful and do that in a shorter time than those who just go to some courses.

There are areas in life where tutors are almost indispensable like in sports, dancing, acting, etc. And there are areas where the situation is completely the opposite, such as learning foreign languages and programming. Although mentors can save you lots of time by directing you in the right direction, creating a structured roadmap for you, and telling you what you don’t know, you can totally manage without the mentor.

That's why I always propagate the practical approach to programming. Here is how it works. You certainly can’t manage without the foundation, so at the beginning, I recommend still following some tutorials or courses that can teach the main idea of how everything works. And I mean not when you are the absolute beginner, it may be that you have some development background in another area or another tech stack. But as soon as you get enough knowledge that allows you to build something simple, which can even be a command line app, think about what program you’d like to build and jump right into the development. Regardless of your unawareness about things like how to set up a database structure, how to make everything scalable, and how to apply the best practices. You’ll learn that on the go. And this will be the practical knowledge from the outset, no going deep into any rabbit holes.

This approach also allows you to stress less about what you don’t know because you acquire the mindset that if it’s necessary, you’ll learn that fast. If I’m developing an app and I discover that I need to implement some functionality that requires some custom layouts, I won’t search for a course that will teach me everything about custom layouts. I will instead search for some quick tutorials or code snippets on the web and try to replicate them for my needs. And only if I discover that it’s not enough, I will investigate deeper. If I did otherwise, I’d probably spend a large amount of time learning something that I’d eventually forget because I wouldn’t use it that much.

Even though I followed that paradigm throughout most of my learning journey I still fell into that trap at one point. I wanted to create an app but couldn’t start developing it because I thought I didn’t know enough. The matter is that you’ll never do.

Don’t be naive

Everyone tends to run after new and shiny but I’ve come to realize that it’s usually not a good idea to be the first adopter of cutting-edge tech. The reasons are simple. Such technologies are immature, not thoroughly tested, and not well-documented. You can’t count on community support because too few people use it. And the devil is in the details so it may be a lot harder to implement some functionality than you think.

But a more interesting thing is why everyone is obsessed with new and shiny. I think that’s because there is always hype around new technologies. It’s advantageous for content creators to follow the trends and post about something new. Few resources make a comprehensive overview of these things. They only highlight the benefits of the technology and usually leave out its drawbacks entirely. And if they do, they often either don't consider all of them or these drawbacks are far-fetched for the overview to look more competent. This is understandable though because you need to use something yourself in a real job setting to make informed decisions about it. So what we get is just hyping, which only results in the technology becoming more trendy.

But have you ever wondered who creates this hype around new shiny? I noticed it’s often the creators themselves! You see, given the open-source nature of the tools we are using, I used to think that the main motivation for developing new tech is to make it better, simpler, and more effective. However, I have to remind you that, unfortunately, we are not living in the ideal world and few people are ready to invest lots of their time and resources for the genuine desire to make something better.

It’s usually business needs that drive the development of new tech. And usually, the main motivation for creating something new is to make money.

Yes, every technology is there for a reason and each solves some specific problem. And yet the main motivation stays the same.

For example, I used to not even question the appearance of Kotlin. It's such a pleasant language to work with. So I thought that as part of the continuous improvement of technology, people who learned from other languages saw the power of Java and decided to create a better version of it. Bullshit!

What really happened was Google had billion-dollar-worth lawsuits with Oracle about Google’s use of Java APIs. So it became no longer reasonable for Google to heavily rely on Java. They needed to find a replacement for it and think about the backup for Android devs in case they lost these lawsuits. So they started creating Kotlin as a replacement for Java and developing Flutter, which is now a cross-platform mobile framework.

So rather than blindly chasing the latest trends, evaluate whether adopting new tech aligns with your own goals and needs. I know these things feel nowel and exciting but we must be pragmatic. List all the pros and cons to adequately decide whether it's worth using that technology or not. Then bring these arguments to the team to decide on the implementation together.

Al will replace developers 🤩

There was an event in my country called Junior Online Conference. Speakers from different tech backgrounds were invited: backend, frontend, DevOps, test automation, etc. But there was one speaker named Lukasz Fliegel whose talk resonated with me the most.

He brought up the concept of Antifragility and how it can help one become a better software developer. The idea is that while fragile things break easily and durable things remain unaffected by damage when something is antifragile, it actually gets better when subjected to chaos or disruption.

Luckily, humans are antifragile. For instance, when you engage in physical exercise, whether it's weightlifting, running, or any form of physical activity, your body experiences stress. This stress breaks down muscle fibers, causing temporary discomfort or soreness. However, as you recover, your muscles rebuild themselves to become stronger than they were before. Apart from fitness, this works in many other areas of our lives, including programming.

Now, whenever I hear such things as AI will replace developers, it’s impossible to find a job in the current tech market, Java is gone, native Android development will be replaced by web and cross-platform technologies, and so on, I perceive this as an opportunity for me to learn and grow. I don’t deny that AI can indeed replace many developers in the future and that the job market is indeed hard right now. But I’m sure that my antifragility will not let me down. Because I’m willing to improve, learn new things, and get out of my comfort zone. And even in the worst-case scenario, I’ll find a way to solve my problems somehow.

Sadly, instead, many developers adopt the “whiner” mindset where they complain about literally every problem that exists in tech. But I don’t get it! I think his mindset is exactly what keeps people from achieving their goals.

Later on in the talk, Lukasz was asked what he thought about the future of developer jobs given the rapid development of AI. And he just said something like:

I don’t know. I don’t like to predict the future. Actually, I don’t think one should be even worried about this because we anyway can’t change anything with our concerns. Right now there’s need for software developers. If that changes in the future, being antifragile will already put you in the better position than your competitors. And if I am affected by a drastic decrease in job positions, I’ll probably do something else. Attending dance lessons, maybe.

I can add that in the case of such a worst-case scenario, dance lessons are not the only option out there. Food delivery, taxi driving, and barista positions offer plenty of opportunities as well. Just kidding. 😁

Of course, following stoic principles alone will not help much. But I hope you get the point here. It can be tough at times. Don’t give up and be patient. I believe if you love what you’re doing, success becomes inevitable over time.

Connect with people

I noticed that many developers consider themselves introverts. And I can hear that from those who attend events, network online, post blogs, do open source, etc. So if these people are introverts, it’s logical to presume that there are even more introverted people who we are unaware about because they do not open themselves up to the world in any way.

When we are starting, we overestimate our abilities due to the unawareness of how difficult some things are and how much time they take to develop. Developing some big things like a social media app with backend, frontend, and mobile is as complex as building a house using your own hands. And even if you manage to build the whole structure, you then need to maintain it, make sure it works properly, make everything scalable, market the app, process the feedback received from the users, and so on. Also don’t forget about such things as design and legal stuff. So it’s just impossible to make everything yourself.

Therefore, it’s crucial to develop soft skills and learn how to work in a team. Effective networking and collaboration also make one’s growth multiple times faster. And it’s actually a lot easier than it seems. There are many ways you can socialize.

Apart from passing tutorials and codelabs I also started listening to technical podcasts, attending online events, and communities and it was so much fun! I got lots of valuable advice, which I’m now sharing with you in this very article, BTW. I found out that I was not the only one who had certain problems. Oftentimes, we don’t know what we don’t know. So this a great way to find out about such things. This way you can also stay updated with the latest trends.

Entering a university turned out to be a great way of socializing too. You can find like-minded people and potentially team up with them to work on a project. I think it works with boot camps too, doesn’t it?

Posting on Twitter/X was a game changer for some people. You’re networking, sharing your knowledge, getting insights from others, becoming noticed in tech, and showing yourself as a great candidate. With the recent changes though, LinkedIn became a much better social network by a quality of content alone. Nowadays, you'll find it far easier to gain popularity and visibility on LinkedIn compared to Twitter/X.

I also started posting on DEV just because I had something to share, and wanted to share that. And now people say “You have your own blog? Cool!” Putting yourself out there is a great way to get noticed, especially in the current time when one needs to do things above average.

Putting myself out there is one of the first goals on my priority list right now. So, if you enjoyed this article, I bet you’ll enjoy the one coming up next week. And let's connect on LinkedIn.

Thank you for reading. All the best!

AI-Powered Pull Requests: CodiumAI vs GitHub Copilot

Daniel Rendox — Thu, 21 Dec 2023 19:24:07 +0000

In the past year, AI has become an essential part of developers’ lives. Back then, it could only write simple code snippets, now it can analyze and refactor whole codebases. With the rapid development of AI, we’ve raised our expectations and we’re now waiting for something even better.

With our eyes on the horizon for the next features in Copilot X, a representative from CodiumAI reached out to me, suggesting the creation of an article showcasing features that we can try out right away. Particularly an AI copilot for writing and reviewing pull requests.

Imagine there was an AI copilot that could help in describing PR changes, reviewing them, and suggesting improvements to them. The life of many open-source contributors and maintainers could be so much easier. Well, CodiumAI PR-Agent is exactly that tool!

Overview

Alright, so here’s how it works. Add a comment to any public pull request on GitHub with the following text:



@CodiumAI-Agent /review

After ~30 seconds you’ll see a comment from CodiumAI-Agent with bullet points about the PR (such as theme, summary, type, estimated effort to review, etc.) and some feedback on it.

In the same way, you can replace /review with one of many other commands to get various descriptions, suggestions, and feedback from the agent.

Write better PR descriptions with the help of AI

Find me a developer who had dedicated a substantial amount of time to implementing a feature or resolving a challenging bug and then didn’t feel want to finally send the code to production. In that moment of exhaustion, all you want to do is hit the merge button and take a well-deserved break.

Although it’s quite understandable, this often results in PRs like:

Fixed some things

I made some changes to improve the data processing in the data_handler.py file.

It doesn’t provide any specific details about what improvements were made. The pull request lacks context about the motivation behind the changes. Neither does it mention whether the changes have been tested.

Both GitHub Copilot and CodiumAI aim to fix this problem by generating PR descriptions with a summary and a detailed list of changes.

Let’s take the previous example, where I had a pull request that improves the logic of habit status computation in a habit-tracking app. Here’s the CodiumAI Agent’s review of the PR:

PR Analysis
🎯 Main theme: Refactoring and improving the logic of habit status computation 📝 PR summary: This PR refactors the 'Routine' class to 'Habit' and rewrites the logic of habit status computation. It replaces 'HistoricalStatus' and 'PlanningStatus' with 'HabitStatus' and adds additional statuses for clarity. The computation of historical and future statuses is now done on the go instead of being cached in the database. 📌 Type of PR: Enhancement 🧪 Relevant tests added: No ⏱️ Estimated effort to review [1-5]: 4, because the PR contains a significant amount of changes in the logic of habit status computation and renaming of classes and variables, which requires a thorough understanding of the existing codebase to review effectively. 🔒 Security concerns: No security concerns found

PR Analysis

🎯 Main theme: Refactoring and improving the logic of habit status computation
📝 PR summary: This PR refactors the 'Routine' class to 'Habit' and rewrites the logic of habit status computation. It replaces 'HistoricalStatus' and 'PlanningStatus' with 'HabitStatus' and adds additional statuses for clarity. The computation of historical and future statuses is now done on the go instead of being cached in the database.
📌 Type of PR: Enhancement
🧪 Relevant tests added: No
⏱️ Estimated effort to review [1-5]: 4, because the PR contains a significant amount of changes in the logic of habit status computation and renaming of classes and variables, which requires a thorough understanding of the existing codebase to review effectively.
🔒 Security concerns: No security concerns found

First, it determines the main theme, which may serve as a title. It suggests the PR summary that indeed matches what is done. Then, it determines the type of PR and whether the relevant tests were added. In addition, it estimates the effort to review and tells if there are any security concerns.

If you choose one of the different ways to use the agent, which we’ll cover later on in the article, it will be able to automatically update the title and description and also add labels to the PR. Use /describe command for that:

CodiumAI’s PR-Agent can also write a detailed list of changes and update your CHANGELOG.md. For that, use the update_changelog command:

Among the mentioned features, GitHub Copilot’s abilities are limited to crafting titles and descriptions with the help of copilot:summary. It also can write a detailed list of changes through copilot:walkthrough command.

Get feedback and suggestions

Alongside PR analysis, the agent gave the following PR feedback upon running the /review command:

💡 General suggestions: The PR includes a significant amount of refactoring and changes in the logic of habit status computation. It would be beneficial to include unit tests to ensure the new logic works as expected and to prevent potential regressions in the future. Additionally, it would be helpful to provide more context in the PR description about why these changes were necessary and how they improve the codebase.

So what it’s just done is address two main issues that may prevent this pull request from being merged:

The PR does not include unit tests.
The motivation behind the changes is missing.

Additionally, it provided detailed code feedback with references to specific files and even lines of code:

🤖 Code feedback

relevant file	core/database/src/main/java/com/rendox/routinetracker/core/database/routine/RoutineLocalDataSourceImpl.kt
suggestion	Consider using a data mapping layer or a mapper function to convert between the database entity and the domain model. This can help to keep the conversion logic in one place and make the code more maintainable. [important]
relevant line	https://github.com/DanielRendox/RoutineTracker/pull/4/files#diff-96a0c9cda6be7f77af13589758d30c625a761d0b1aca0e4fc5980b966fb8baecR13

relevant file	core/domain/src/main/java/com/rendox/routinetracker/core/domain/completion_history/use_cases/GetRoutineStatusUseCase.kt
suggestion	It would be better to separate the logic of prepopulating history with missing dates into a separate function or use case. This would make the code more modular and easier to test. [important]
relevant line	https://github.com/DanielRendox/RoutineTracker/pull/4/files#diff-a8044fd1c82f20ee81e28bdab1ff37151be709abc2ce52f5d96fba1e645de6f6R58

relevant file	core/domain/src/test/java/com/rendox/routinetracker/core/domain/routine/schedule/ScheduleIsDueTest.kt
suggestion	Consider using parameterized tests or data-driven tests for testing the same logic with different inputs. This can help to reduce the amount of repetitive test code and make the tests more readable. [medium]
relevant line	https://github.com/DanielRendox/RoutineTracker/pull/4/files#diff-41e217a89b141d2ec28631d7767ce69b186ef4bdb61ded70ad6e5af91af09007R4

relevant file	core/domain/src/main/java/com/rendox/routinetracker/core/domain/completion_history/use_cases/GetRoutineStatusUseCase.kt
suggestion	Consider using a strategy pattern or a similar design pattern for computing future statuses. This can help to make the code more flexible and easier to extend in the future. [medium]
relevant line	https://github.com/DanielRendox/RoutineTracker/pull/4/files#diff-a8044fd1c82f20ee81e28bdab1ff37151be709abc2ce52f5d96fba1e645de6f6R90

But hold on, there is something even more impressive. You can ask follow-up questions! Check this out:

Moreover, it can also modify the code that needs to be improved with the help of the improve command. This can be something simple such as a naming inconsistency that your IDE has not been able to detect:

Rename the variable 'routineId' to 'habitId' to match the new naming convention:

Existing code:


 Kotlin
val previousStreak = streakRepository.getStreakByDate(
    routineId = habit.id!!,
    dateWithinStreak = date.minus(DatePeriod(days = 1)),
)

Improved code:


 Kotlin
val previousStreak = streakRepository.getStreakByDate(
    habitId = habit.id!!,
    dateWithinStreak = date.minus(DatePeriod(days = 1)),
)

Or it may point to a missing test case:

Isn’t that cool? It now motivates me to submit pull requests for my personal projects, where I'm the only contributor because there is no one else to review my code.

With all this automatic feedback, people can not only learn how to write good pull requests but also learn about programming practices that they might otherwise overlook. Take, for instance, one of the code feedback suggestions that recommended utilizing parameterized tests. One might be unaware that such a thing exists.

GitHub Copilot currently does not provide any of the functionality described in this section.

Even more commands!

Unlike Copilot, CodiumAI also supports commands like:

similar_issue: retrieves and presents similar issues;

generate_labels: suggests custom labels based on the PR code changes.

add_doc: adds documentation to undocumented functions/classes.

Moreover, commands can be appended with a parameter from the configuration.toml file. For example,



/describe --extra_instructions = "Emphasize that ..."

Supported platforms and different ways to use

For simple usage, it may be enough to call @CodiumAI-Agent every time. However, this approach has several limitations, such as:

Multiple comments from the agent can potentially clutter the conversation. You may want to write everything on your behalf so that you can easily delete these comments.
CodiumAI-Agent can’t edit comments, files, and PRs.
It can't be used for private repositories.

Fortunately, there are solutions to all the listed cases, as well as numerous other scenarios where a more nuanced control is desired. To cater to any of these situations, you’ll need to install the agent in one of the following ways:

Locally

GitHub specific methods

GitLab specific methods

Run a GitLab webhook server

BitBucket specific methods

BTW, you may have noted that in contrast to Copilot, CodiumAI's availability is not limited to GitHub. It also gives you a choice between different AI models, such as GPT-4, GPT-3.5, Anthropic, Cohere, and Llama2 models.

However, it’s important to note that in order to install the PR agent, an API key of one of the supported models is required. In this case, CodiumAI’s services stay free, but the requests to the model itself may require additional fees.

It’s also possible to run the PR-Agent in VS Code or any of JetBrains IDEs. This functionality is included in the CodiumAI IDE plugin. But note that it requires a CodiumAI Teams subscription.

Response time

Both Copilot and CodiumAI respond in approximately 30 seconds on average. Roughly 10 seconds after submitting a command, the 👀 emoji appears to indicate that the result is loading.

Among the things I didn’t like is that when some exception occurs, you don’t see any response at all. You’re left wondering whether it’s still loading or not. It would also be great if the generated part of the response was visible while it was being constructed.

Nevertheless, this differs when it comes to the CodiumAI PR-Agent within the IDE. It does display partial responses, so you don’t need to wait. Additionally, I noticed that its response time is a lot quicker in the IDE, typically taking 15–20 seconds.

Generating tests

One of the most common things that don’t allow PRs to get merged is the lack of necessary unit tests, which makes generating them directly in pull requests one of the most promising things AI tools can provide.

GitHub plans to solve this problem by introducing a GenTest feature that will offer suggestions on resolving issues that would analyze the PR for missing tests and then create another pull request that suggests the necessary unit tests. Unfortunately, this feature is still not released publicly.

For now, CodiumAI does not have such a feature either, although the PR-Agent does address the absence of unit tests.

However, you can use the /ask command to get detailed test suggestions and then go back to your IDE and write them there. That’s exactly what they specialize in when it comes to their IDE code assistant.

Ghost text

This one is actually where the GitHub Copilot is most likely to win. It’s about the subdued, inline suggestions that appear as you type in the editor.

When it comes to the Copilot IDE plugin, these suggestions have been proven to be one of the most convenient ways AI can integrate into the development workflow. Now they are working on bringing this UX to the pull request experience.

So what is better?

Alright, so both assistants have great potential to improve our workflow, save time, and automate tedious tasks. I’m looking toward the future where such tools integrate seamlessly into the development process.

As we are waiting for the new cool AI features, let's now determine which of these two is currently superior.

Let’s address the elephant in the room, from all the described features, GitHub Copilot only has PR summaries available at the moment. To get access to this tool, you must sign up for a waitlist for Copilot Enterprise, which costs 39$ per user/month. But to sign up, you need GitHub Enterprise Cloud, which, in turn, costs 21$ per user/month. Other GitHub Copilot features are currently not available at all! For now, they are only planned as a part of the Copilot X prototype.

But let’s not underestimate it. According to GitHub Next, the planned features are quite promising and it may be great for user experience in the future.

CodiumAI, on the other hand, lets us try the cutting-edge technology right now. It provides more commands, is open-source, and is well-documented. It also gives us ample opportunities for customization. In terms of pricing, we can use it for free, or opt for one of the paid plans that offer more features.

CodiumAI has plans on its roadmap too. For example, enforcing CONTRIBUTING.md guidelines.

Conclusion

I’m quite impressed with the power of these tools. We can now automate AI responses for our repositories however we want. I can see such PR agents operate in tandem with tools like CI/CD pipelines in the future, and serve as efficient and quick-to-respond intermediaries for creating and reviewing PRs.

Challenge finished — reflections

Daniel Rendox — Mon, 02 Oct 2023 17:49:00 +0000

My 2 months of learning and building in public challenge is over! Time to summarize the results!

So I set two goals for myself:

Learn all I need to build a scalable Android app.
Create an MVP of my app.

And now I don’t really know whether I completed the challenge or not because, on the one hand, I fully achieved the first goal, on the other hand, my app is still far from an MVP.

However, these 2 months were really fun and productive because I

found my blogging path;
established the best way of learning that works for me;
kept myself exposed to the world;
had an ending point in learning and made it before the deadline;
entered university, had my daily routine changed, and met new people.

I have seen that all the benefits of learning and building in public I wrote about indeed apply. By summarizing my progress I organize myself, keep being motivated, and keep my goals clear.

Although I’m kind of a productivity beast, I struggle to keep up with habits, especially those that provide long-term and not short-term benefits. I found a cool solution: share progress with others to stay accountable.

Now I’m going to heavily focus on building my app, and I’ll keep sharing my progress. I’ll make it an article only when this is a really worth-sharing achievement, though. That’s because writing such articles is like a burden for me now, I perceive them as something serious, not as short reflections in a couple of sentences. As a result, I don’t have time to write other articles that I’d like to write more. I think I’ll be good with comments on threads like “What was your win this week?” This will actually keep me more accountable.

I think the decision to take this challenge was worth it. However, everyone follows their own path and I learned there is no one-size-fits-all solution. It’s important to just do what you like and follow your passion.

Finally connecting everything together 😊

Daniel Rendox — Wed, 20 Sep 2023 07:51:44 +0000

On the 2nd of August, I promised to document my progress during these two months. Here’s a report of my past two weeks of learning and building in public.

In the last time, honestly, I didn’t have much desire to be active in this digital world of developers. That’s because my higher education has started, and there are so many new connections out there that it’s actually too much for me. 😆

However, I need to summarise what I’ve done to feel the progress towards the end goal and be motivated, purposive, and consistent. While I'm delighted to return to my comfort zone and savor this exceptional phase of my life, it's important that I remain engaged in all its facets.

About two weeks ago, I was struggling with balancing learning and building. That’s because I wanted to build my program, and at the same time I didn’t know enough to actually start without messy code. Although I started in some aspects — UI, business logic, and data storage, I couldn’t connect everything together.

However, a few days ago, I was so happy to discover that I actually know everything I need to build my program! Of course, my knowledge isn’t deep, but it’s enough to create a base of a scalable program without messy code and following all the recommended best practices.

I don’t know whether it’s because I developed that mindset for learning only the necessary concepts and leaving the rest for the time I actually need a certain thing or it’s because I already knew much and just underestimated my progress, but in the first week of this period I learned all the remaining concepts I needed and discovered such pleasing truth. Seriously, look at the plan I’ve been following:

Android basics
Kotlin
Jetpack Compose basics
Advanced state, side effects, and Gradle
Inline functions, testing, introduction to Coroutines and Flow ◀️
Databases and modularization
Interaction with remote API
Dependency injection
Architecture (MVVM, MVI) and other stuff 🏆

◀️ — where I was two weeks ago

🏆 — where I am now

Now the plan is to catch up on building my program, fill in the gaps in knowledge while working, and actually complete the challenge in the remaining time. (at least I’ll try).

Oh, and here's what I've learned:

Interaction with remote API

Nothing interesting in remote API itself actually. The basics are not difficult at all and I don’t need it for now. Contrary to what I expected, it didn’t help me better understand coroutines either.

However, it was a good introduction to Rest API. It also helped me a lot in understanding dependency injection.

Here is the course I’m speaking about.

Dependency injection (di)

I learned the basics of Hilt with the help of this amazing codelab. This helped me understand how di and di frameworks work overall. And it’s not about learning Hilt because I actually don’t plan to use it in my app.

I don't really understand why people perceive dependency injection as a complex thing. For now, I see it just as a workaround in situations when I can't pass dependencies in constructors (a typical situation in Android). According to what I've seen in the codelab, manual di requires almost the same amount of code. So it currently looks simpler and safer to me.

I would appreciate it if someone explained to me what all the fuss is about.

Anyway, I probably just don't know something because experienced guys say di is very important. I was right about the manual di, though. It is indeed a great option because it eliminates the overhead created by di frameworks. But this is not an option for me because frameworks provide some template while doing it manually gives me so much freedom that I risk of creating a monster, riddled with bugs.

So I learned hilt and found out that I couldn't use it in my project right after that. 😁 I can't use it because I aim to expand my project to iOS using Kotlin Multiplatform, but Hilt is a pure Android thing. So I'll use the second most popular di framework — Koin.

Databases

When I first met the concept of databases, I found out that database programming is very limited compared to object-oriented programming. Lately, when I got back to this topic again, I found out that it’s not difficult at all, and you don’t need to read a book or pass a crash course to correctly design database schemes.

The first tricky thing is database inheritance. There are three approaches here — look at this answer on Stack Overflow. Due to limitations of the framework and other considerations, I picked the first one.

The second tricky thing is modeling relationships such as one-to-many and many-to-many. This is perfectly explained here.

When it comes to choosing the framework, Room is the obvious choice for Android. But this is once again a pure Android thing that doesn’t work with KMM, so I use SQLDelight instead.

Modularization

Checked the information about the recommended architecture of a project that consists of data, domain, and presentation layers. Also found out about CLEAN architecture from this example.

I didn’t dive into modularization itself though. That’s because I’ll introduce it later when my project grows.

There need to be 3 main modules: app, feature, and core. For now, I decided to use packages instead of modules and have several sub-packages for data, domain, and presentation.

MVVM vs MVI

Finally, when it comes to a serious Android project, there are lots of considerations. One of them is whether to use mvvm or mvi. Other solutions are generally not an option because they are too legacy. I decided to use MVI because of its benefits. There are many drawbacks too, but we can work around them. One of the decisive factors is that it’s more modern and Google recommends MVI for Jetpack Compose projects now. 😎

With XML, the situation is different because, AFAIK MVI isn’t good for performance there. It causes the whole UI to rerender each time something changes, which is not true about compose since its compiler is smart enough.

Thanks, Philipp for the great explanation.

There is another interesting thing, by the way. Although it’s better for beginners to follow the recommended practices and decide on something only when they get some experience, one can essentially do everything they want and use their own solutions as long as everything works correctly, the code is readable and still follows the best practices.

For example, the matter of whether to use ViewModel is questionable. I recently discovered that the main reason we use it is because it caches the data so that we don’t need to execute network requests when nothing changes. We also save resources by not fetching data when a configuration change occurs. There are other benefits of ViewModel. Here is a great talk related to this topic.

However, there are alternative approaches to achieving that. For example, compose provides rememberSaveable for saving state across configuration changes and even across activity recreations.

You Don't Need Android ViewModel, Here is Why

Explanation of why you don't need ViewModel component in your Android application and a list of alternative solutions that I use.

techyourchance.com

So there are lots of ways for achieving the same thing and it’s not necessary to use only recommended solutions. Getting more experience, I’m becoming more and more convinced in that.

Ending

I wrote this article for myself mainly. But if you read this far, thanks for being interested in me. 🤗

If you're learning Android and struggling with some of these topics, you can DM me on Twitter or email me (daniel.rendox@gmail.com) and we'll figure it out together.

The Last Days of my Total Time Freedom

Daniel Rendox — Tue, 05 Sep 2023 08:32:08 +0000

Roughly 1 month ago, I took a challenge for myself that focuses on learning and building in public. It’s time to reflect on what I’ve achieved.

I focused on learning and building, so writing blogs was not a priority. And I decided that today is the best time to make a review of my past 2 weeks.

Learned

Lately, I’ve been learning Kotlin coroutines and flow. It was more of a quick introduction to this topic because I plan to learn databases, so I’ll need to understand it. Although now I’d want to do things differently, it was interesting to dip my toe into reactive programming.

Coroutines are scheduled code within a thread. And the fact that a new thread is not necessarily started confuses me. For now, the traditional way of multithreading with threads and callbacks is actually more clear and readable for me. But I’m sure that’s only because I haven’t worked with coroutines much, especially in the practical setting.

When it comes to flows, they are essentially placeholders for values that come in a certain period of time. That’s why they are called streams of data.

I also learned the Compose Navigation library that is AFAIU here just for convenience so that we don’t need to hold everything in state, write a huge when expression, manually deal with animations, and manually integrate with other Jetpack Compose components.

I also was surprised by the simplicity of MVI. Met this thing unexpectedly. So the main idea is that you put all the states in one data class as plain vals and then put the whole class to a single state. First, I doubted how optimized this approach is, because I thought that an update to a state would cause unnecessary recompositions. But this turned out to be not true because they are skippable as Compose is smart enough. This is not true about xml views though. However, MVI introduces some hassle if you want to save the state to the SavedStateHandle and can also cause race conditions [source] so I think I’m good with MVVM for now.

Resources

Here are some resources that helped me learn this.

Coroutines

Flow

Kotlin Flow: Simple yet Powerful Implementation — This helped me understand how they actually work.
The Ultimate Guide to Kotlin Flows

⚠️ However, I rethought my learning approach.
According to my new mindset, I should’ve begun with the following pathways right away. ⬇️ Especially given that they do not require knowledge of coroutines and flow. It is actually taught there. 1. Android Basics with Compose — Unit 5: Connect to the internet. 2. Android Basics with Compose — Unit 6: Data persistence.

+ Jetpack Compose Navigation Codelab

Progress

I modified my roadmap a bit and now I’m in the middle of my path 🎉

Android basics
Kotlin
Jetpack Compose basics
Advanced state, side effects, and Gradle
Inline functions, testing, introduction to Coroutines and Flow ◀️
Databases and modularization
Interaction with remote API
Dependency injection
Architecture (MVVM, MVI) and other stuff

See that “Make my app — 5%”? I actually managed to let go and it doesn’t bother me. But what I contemplated is that it’s not OK. I can already write business logic and the UI, only then add data storage. I also shouldn’t care about best practices that much. So to stay both practical and motivated, I decided to focus on building now.

Oh, and I entered a university

Actually, I did it in the summer, but the lectures traditionally start in September.

And that’s coming from a person who is a big fan of the practical approach and says that higher education is a scam. 🌚

I’m honestly, indeed very skeptical about the higher education for developers. But, first, it’s free for me. Second, here are my expectations in descending priority:

More opportunities to find a job. I can get an internship or eventually go overseas.
Communication. Very high chances of finding great friends.
Plan B. Being self-taught and having a degree at the same time is a win-win, especially for someone of my age.
Get the foundation, support, and confidence. However skeptical I was, that’s what schools do well.

This is insufficient for me to justify the amounts of money people spend. My time is already a significant investment! 😼

I used to spread the information that classes only would take ~6 hours a day. People felt sorry for me, but it actually turned out not true. 😆 I just confused some stuff. In reality, it’s about 4.5 h. And Friday is a day off.

I’m enjoying it so far and feel like my expectations are going to be met. Who knows, I may change my decision in the future.

Performance (adjusted to 2 weeks)

My challenge

✔️ 7/10 tweets

✔️ 2/3 articles

Healthy habits

I’d better not tell you 🤭

Changes

So I allowed myself to fall behind a bit. And until now I’ve been only increasing my goals. But now that I’m not going to have that much time, I think it’s an opportunity to focus only on a few of them. And finally, get back to the comfort zone.

And I also have exactly four weeks until my challenge finishes. So now I don’t have room for error.

No more tweets. I’ll tweet only when I want.
I will do programming at least 6 days a week, but won’t count the hours anymore.
Back to 1 article a week.
Also deleted a couple of habits I already have, and switched to HabitNow for habit tracking.

Ending

I wrote this article for myself mainly. But if you read this far, thanks for being interested in me. 🤗

If you're learning Android and struggling with some of these topics, you can DM me on Twitter or email me (daniel.rendox@gmail.com) and we'll figure it out together.

The Art of Balancing Learning and Building

Daniel Rendox — Sun, 03 Sep 2023 15:44:13 +0000

I've been experimenting with my learning approach for a long time now, made dozens of mistakes, and I think I finally came to a conclusion. Eager to share the gained insights with you!

🐰 The rabbit hole is open

This summer, I had a lot of free time for programming. So, knowing a bit about Android, I quickly learned the basics of the new UI framework and started applying these things in my program that I think I have a good idea of. Having tried to write some simple stuff, I realized that there was a whole mountain of things that I didn’t know.

While creating some labels, buttons, and checkboxes is easy, making them actually work and doing some more complex stuff requires a lot more knowledge. Imagine, I want to create a functional screen. I need to first write business logic and UI. Then it would be good to add databases, which also requires knowledge of multithreading. And only then I can connect everything, and preferably, write tests to make sure everything works correctly. This is the whole bunch of stuff not even mentioning, interaction with remote API, dependency injection, and following best practices.

Then you actually try to figure all this stuff out and find other pitfalls which is really frustrating, especially when you don’t understand something. You don’t even know what you don’t know!

Here is the answer to why beginners feel very confused about how to cope with everything.

As you can guess, I fall right into that trap. But luckily, I regularly listen to some programming podcasts and I once found some great advice in one of them. I encourage you to watch this 50-second clip ⬇️

youtube.com

I obviously needed some time to digest it but when I did, it ended my frustration. Here is the breakdown.

🤯 #1 Have fun and experiment with stuff

When you encounter a problem that requires you to learn some new things, approach it with the right mindset — be excited that you’re gonna significantly increase your skills.

Of course, this podcast wasn’t the only thing that pointed me in the right direction. It’s usually a confluence of circumstances that causes people to rethink something.

I remember another Android dev who having found out that I was trying to learn Android and build my app, said to me smth like “You must be following a lot of Google codelabs and just experimenting with stuff”.

And this stuck to my mind. Just having fun and experimenting with stuff — that’s what I should do. One step at a time. Find an interesting guide for a topic, try to implement, and switch to another one.

🤯 #2 Build your program!

So I decided to savor learning and really enjoyed getting into these rabbit holes. However later on I realized another equally important thing.

I made some kind of a roadmap for myself that involved passing codelabs and making small programs to practice my knowledge and play around. This was pretty close to what Philipp Lackner recommends in his video — learning stuff and then making programs to apply this in practice. For example, you’ve learned a programming language and UI framework — now you can build a calculator, then you learn how to store data and build a to-do app, and so on.

Given that to make a scalable project, you need to consider lots of things from the beginning. E.g., for Andriod, it would be good to, first, care about dependency injection and architecture, it would be even better to make sure that your code is properly abstracted and tested. [source]. So as I just didn’t know all this stuff, I decided that I would learn it and then get back to my program.

And I ditched it for an unidentified period of time.

Fortunately for me, at some point, I had a little dispute about “the right learning way” with my dad who is a developer and had made all these mistakes either. He said that I was learning too much and should’ve focused on building instead. And I was like, that’s what I’m doing, I’m creating these learning projects to practice and they all involve the knowledge acquired previously so as not to forget anything.

But he told me that it’s very important to have an ending point. There is always gonna be other stuff to learn, and you’ll never be ready to continue working on your project. He’d fallen into that trap and eventually found himself knowing a lot but not having actual results.

Like when you spend a significant amount of time preparing yourself for the big venture and then your friends ask what you’ve accomplished so far, what you’re gonna respond? Alright, I can name a bunch of technical things to impress people, but what can I actually show?

What if we flip it upside down?

And then I realized that the best way of studying is not learning theory and then seeking the possibility to practice but on the contrary trying to make something, figuring out what’s needed, and learning that. Right away with the practical approach! 🙌

Learn only the stuff that you actually need

It’s crucial to learn only those things that you really need for building your program. When I started learning programming, it was my biggest mistake. I just learned things that indeed helped me understand concepts, the programming language, and the whole structure. But even though, I quickly forgot them, and could be so much better off not wasting time on those things and following the practical approach right away.

I still make these mistakes and this advice is also very to misinterpret. For you to understand, here are certain scenarios. ( ✔️ — correct approach, ❌ — incorrect approach, according to the described mindset)

To save your program’s data, you need to learn databases. But the prerequisite is that you should know concurrency first.

❌ Go find a course for mastering concurrency and after that, switch to databases.

✔️ Start with databases right away, and when you don’t understand something about concurrency, find a quick explanation on the web and go on. If you eventually feel that this concurrency knowledge is not enough, take that course.

Don’t run after new and shiny

You want to create a program and already know how to make a simple app, but a new shiny framework comes out, and you feel like you need to learn it.

❌ Learn the new framework. This will allow you to fill in the gaps, get more confidence, and see things from a different perspective.

✔️ Congrats! You are ready to start building your app. This will keep you motivated, you’ll retain your knowledge, and stay practical. In addition to that, you’ll eventually get all the benefits described above.

Even applicable to absolute beginners

You're just starting out and have an idea of an app you want to create. Before that, you certainly need to learn the programming language.

❌ Go find a crash course about that language.

✔️ Go find a course that will allow you to stay practical right away. For instance, here is one for Android development. If you can’t find one, learn the basics and jump to creating something yourself.

Don’t get overwhelmed with best practices and give up on your program

You find out that to make your app scalable from the outset, you need to know many things. You consider what to do next.

❌ Ditch your program, learn all these things, and only then get back to it.

✔️ Carry on with your program. Start small. First, write business logic, then add UI. Boom! Pre-MVP is ready. Then try and add data storage — MVP is ready. 🎉 And don’t really worry about making it scalable.

There is no point in being concerned that your code is not clean enough. It won’t ever be perfect. Trying to optimize every class you write and learn all the best practices at once will only take up your time and spoil your nerves.

It’s good to occasionally look into these things, but being overwhelmed with them is bad.

As you may guess, I made each of the mistakes above.

Adopting the mindset to build any app

If you rewatch that clip from the podcast, you’ll discover that the first piece of advice (🤯 #1) was actually produced by my imagination, while the thing the guys actually emphasize is exactly the importance of building your own stuff.

In the beginning, Mitch says: “It’s like what you said earlier.” And that earlier was at 1:02:00, where they answered one of the listener's question: “How can I get an attitude that I can make everything, that I can make any app?”

The answer is actually in developing such mentality that I described above. Being able to learn, and just carry on. Like Mitch says:

Get confortable with being uncomfortable.

My favorite learning approach is free

It’s one of the things that I love about it. You don’t need to pay for any books or courses. In fact, with all this information available for free, paid higher education seems to be nothing more than a scam either.

In the marketing world, salesmen put discounts to make us buy things that we don’t need. The business of making courses works in the same way. I’m not saying that it’s bad though. Products are good and we’re happy to buy them, the same thing with courses.

I love Philipp’s channel and benefited very much from all the knowledge he shares. But why would I pay ~100€ for a course on his website if everything is available on his YouTube channel? What these books and courses really offer is the information gathered and structured in a systematic way. They also artificially make you feel comfortable because you have support.

Then the question of whether to buy or not boils down to how willing I am to collect all this information and solve problems on my own. In my opinion, if this stuff is available legally and for free, buying a course is a way to spend money and get tutorial hell, whereas the project-based approach lets you adopt this very mindset.

Ending

Now that I’ve defined the most important things about learning programming, here is how I’m gonna change my approach. First, I’m going to make building my app the first area of focus and allot no less than 50% to it.

I think it’s imperative though to still embrace learning in parallel and dive into these lovely rabbit holes, but only for a limited time. This way, I can be sure that I stay on the right track and do not reinvent the wheel due to the lack of knowledge.

I’m still searching, so I’m curious to hear about your favorite way of learning. Advice and insights will be much appreciated!

Quick summary of my past 9-day week

Daniel Rendox — Tue, 22 Aug 2023 14:01:04 +0000

18 days ago I took a challenge for myself that focuses on learning and building in public. It’s time to reflect on what I’ve achieved.

In this post, I decided not to beat around the bush and quickly summarize what I did during the last 9 days and go on.

My week consists of 9 days now 😁, but that’s OK because I planned the challenge to last 2 months, not 8 weeks. It started on the 4th of August and will finish on the 4th of October, so I have 61 days in fact. Is it a legitimate move? 🤔 Should be.

Quick summary

Anyway, during this week I focused on managing state in Android. It’s important because otherwise, we lose user’s input when they turn the screen, switch to dark/light mode, etc. The same happens when the system kills the app’s process to save memory.

That’s not as easy as it looks! Using remember { mutableStateOf() } is not enough, unfortunately.

We also have side effects — code that goes out of the scope of a composable function. Philipp Lackner has a great video on this topic. But watching it is not enough for understanding. So I played around with it.

Also struggled to understand derivedStateOf, but the answers to my question in Kotlin Slack and some research made it clear. In short, use derivedStateOf only in rare cases. But in those rare cases, it’s extremely useful for performance.

Also learned new things about Gradle. Mainly that we can use different product flavors for minSdk. So I refactored my project to use core library desugaring only when running on devices with Android versions less than 26.

Found out how to create a release APK version. And finally relieved when my app launched faster on release than on debug. That’s because I had thought there was a performance issue and I did smth wrong. 🤨

Learning resources

Here are the resources that helped me learn this.

Advanced state and side effects

Advanced State and Side Effects in Jetpack Compose | Android Developers
Should You Use Compose State or StateFlow in Your ViewModels?
Full Guide to Jetpack Compose Effect Handlers
My question in Kotlin Slack about derivedStateOf
Gabor explains how to create a state holder but one that can be saved in SavedStateHandle and thus will survive the process death — What is the best way to pass a default/initial value to a Jetpack Compose TextField?

Gradle

Progress

This week I decided to focus on learning. Although I added some features to my recent learning project, I didn’t work on my real app.

AFAIK, here are the main concepts that I need to know to build an MVP:

Android basics
Kotlin
Jetpack Compose basics
Advanced state, side effects, and Gradle ◀️
Navigation and performance
Advanced Kotlin, Coroutines, and Flow
Databases and modularization
Dependency injection
Architecture (MVVM, MVI)

◀️ — Where I was in the past week

So I’m glad to increase this “Learn Android” bar by 5% 🎉

Make my app still remains at 5%. I used to feel bad about it, but in the past week, I realized something that ended that feeling. I’ll probably make a separate blog post about it.

Performance adjusted to the brand new 9-day week 🙃

My challenge

✔️ 5/6 tweets

✅ 1/1 article (this one)

VC’s Healthy Habits challenge

✔️ Programming: 45/48

☑️ Household: did at least 1 household chore 6 days a week

☑️ Physical activity: 6/6 times

☑️ Rest: had at least 1h each day

😱 Learn English: 14/42

☑️ Daily review: summarized what I did every day

Updates to the challenge

It’s great to start small and then improve over time. So here are my improvements to the challenge’s rules:

➕ New habit — Follow the schedule every day. I discovered that I am still out of sync with my defined schedule. So I tweaked it and added this habit. This is mainly to get up at 7 AM and close my eyes at 11:30–12:00 PM.

⬆️ Work 1h more each day. This is actually not a problem for me. I usually work more than planned because I love programming and can’t put it aside. My problem is to not forget about other activities and not take their time. But as I said, I changed my schedule and now it should be OK.

⬆️ 2 articles a week (or 9 days 😁). I have a lot of ideas, drafts, and notes, but can’t find time for writing.

Ending

I wrote this article for myself mainly. But if you read this far, thanks for being interested in me. 🤗

If you're learning Android and struggling with some of these topics, you can dm me on Twitter or email me (daniel.rendox@gmail.com) and we'll figure it out together.

Starting from the blank canvas, trying to be lazy, and other insights from the 1st week

Daniel Rendox — Sun, 13 Aug 2023 14:36:44 +0000

1 week ago I decided to take a challenge for myself that focuses on learning and building in public. It’s time to reflect on what I’ve achieved.

Starting from the blank canvas

This week I’ve been mostly working on the business logic of my app. Fortunately, since the day when I got the idea of it, I’ve collected enough information to know what I want to build now. I analyzed similar apps, wrote down emerging ideas, and even thought about the design.

But even so, I feel like I’m starting from a blank canvas. 😅 That’s because, when I think about how to actually implement those features, I realize that there are still lots of things to consider.

However, I really enjoy designing and building something that will certainly help me and is likely to help many people in the future. Here is the Github repo, BTW.

Speaking about design, I don’t use any design tool like Figma. All the UI is currently in my head and other apps I use for references 😆 That’s because I tried using design tools and discovered that it really takes time. I think, I’m a lot better off just drawing sketches on paper and writing the UI programmatically at once (but we’ll see).

Trying to be a lazy developer

My app development started with a challenge. I started with writing UI cause I’d passed a codelab about the framework and wanted to practice a bit. In my app’s design, I imagined a collapsing toolbar with an image. But the matter is that the framework does contain built-in functionality for collapsing toolbar, but doesn’t allow putting custom content such as an image into it.

I spent a lot of time figuring out a way how to do that and eventually found one. Here is an example layout for you to understand ⬇️

The problem was not only in the image. I was not sure whether the title should be collapsible too. This is a disadvantage of not using a design tool, BTW.

Spend time figuring that out as well. But you know what? I eventually realized that the effort was not necessary because I could simply make it nicely appear on the toolbar when a user scrolls down. Moreover, I recently came up with a more nice and modern design solution that actually does not require a collapsing toolbar at all!

For sure, I gained knowledge and experience, but next time I’ll try to be as lazy as possible. And I’ll think twice when I’m about to start something difficult I’m not sure about.

Exploring other people’s projects

I thought it was a great idea to find out how certain features are implemented in other people’s projects. I know two open-source apps that are similar to what I want to build: uhabits and tasks.org.

But I discovered that finding the correct implementation takes lots of time cause the codebases are complex. You should jump through those classes and to actually understand how something is done there, you need to understand the whole structure. In addition, although these apps are native Android, people use different technologies that may be not suitable in my case.

So I decided not to waste time for now.

A bit of technical stuff

My app is going to heavily use some API that deals with time. So this week, I decided to learn kotlinx-datetime library. I hadn’t known how to work with LocalDates, Instants, and other things so I met these concepts for the first time.

I found out that what’s very important in dealing with time is to store the time of events scheduled for the future in LocalDateTime instead of Instants. That’s because otherwise if some country decides to suddenly change their timezone (e.g. decides to introduce/revoke DST), my app’s notifications will tell the user the wrong time of the event. I even made a Github Gist with some notes on this library.

Why kotlinx-datetime when there is java.time? I want to first develop my app on Android and then expand it to iOS with the help of Kotlin Multiplatform. Even though kotlinx-datetime is yet alpha, I decided to use it, cause there currently is no other option.

My progress

Alright, it’s about time I summarized my performance this week.

My challenge

✅ 6/5 tweets

✅ 1/1 article (this one)

VC’s Healthy Habits challenge

☑️ Make my app: worked for 44 hours (goal = at least 40h)

☑️ Household: did at least 1 household chore 6 days a week

💬 Physical activity: 4/5 activities

☑️ Rest: had at least 1h each day

☑️ Learn English: learned 42/42 new words

I’m late for 2 days 😬

I should’ve published this post on Thursday or Friday but while writing it, I came up with an idea of a simple learning app, which is not connected to the main one. Started working, and that’s what I was unexpectedly doing during these two extra days cause I initially thought it would take 1 hour at most 😅.

Taking into account that my performance was OK, I’m gonna start over as if the 2nd week started now. I think I may do that (I hope so 😄).

This is also a great thing about this weekly challenge type. Though I’ve messed up on the previous week, I have a perception that I’m starting over on the next one, which gives me a bit more motivation.

Made a simple program for tracking my progress

So here is that program that took me two days (damn).

I like to visualize my progress with progress bars. That’s what this app is about. It allows users to enter a name of a routine and its progress, and displays it in a nice way. So here is how I roughly estimate mine for now:

So, while I worked even more than planned, I didn’t do much actually. 😐 I set a goal to make my app with basic functionality in two months but I think my pace is currently too slow. Yet I’m happy that I already know about 40% of what I need to build this (not the whole Android, of course).

And getting back to the app, while making this simple layout is indeed not so difficult, I also decided to make it work properly and introduce the “add routine” functionality, which was a challenge for me. I will improve it later, making the code more optimized and adding a database cause now the data gets lost when you close the app. The code is available in this GitHub repo.

Anyway, making such projects are my favourite learning style. I watch tutorials and then apply that knowledge in practice right away while creating something that is actually useful to me and other people.

Improvements

So there are some improvements to be made in both my work and life.

First, I noticed that I don’t have a strict plan of what I should be doing at a time. So I just continue what I was doing the day before or come up with an idea and start working. This isn’t very productive in my experience. I’d better create a plan.

I can’t really make a plan for building my app because I’m doing it for the first time and vaguely imagine the next thing I’ll have to deal with. But luckily, that’s not true for learning. So I’ve collected the necessary resources for the next two weeks or so and defined how much time I should spend on each. I’ll also try to apply the gained knowledge right away in my project so I do have some kind of a plan for building my app either.

Second, I initially planned to do tasks in specific time blocks and not exceed the time of each. The challenge is that we usually have some distracting things that break our schedule. I found a solution to simply change the order of these tasks, which I call routines, and at the end, spend the planned amount of time on each. Honestly, I've completely failed with this one. It’s quite challenging but I think this can significantly increase productivity so I tweaked my schedule and I’ll try again.

Also allotted some time for daily review, reading, and writing articles, cause I now have 160 only in my DEV reading list.

Measuring time, not work

With all these improvements, I’ll remember that I’m not a superman to achieve everything.

Here is one productivity tip that works for me:

Measure how many hours you worked, not how much work you did.

That’s because, at first glance, you may appear not to have done much, but, in fact, this 20% that you’ve done contribute to 80% of the overall amount. It’s especially relevant to programming, where you usually have to spend lots of time fixing a bug or reading code and not appear to be very productive.

BTW, that’s why I don’t really understand people who advise to apply the Pareto Principle, cause if this law exists, you can’t avoid it whatever you did.

Of course, one may get distracted all the time and indeed not do much. Then this trick won’t work. But I’m sure that’s not true about me.

Ending

Anyway, the takeaway from this week will be that contributing to learning and building in public is indeed helpful for me. I enjoy it and see the increase in productivity. That’s because if I didn’t share my progress, I would’ve quit the challenge in a couple of days. That’s how it used to be.

Alright, thanks for reading this article, good luck with your projects and see you later. 👋

Finding My Blogging Path: Lessons from My Journey

Daniel Rendox — Fri, 04 Aug 2023 07:00:00 +0000

If you’re starting out in writing, you probably have little idea about what to blog about and where to do it, but the last thing you want to do is to follow my mistakes. Take a look at my journey, and find answers to these questions.

Table of contents

Starting out 👶
The mistake 🤦‍♂️
Reflection 🤔
Learning and building in public 🧠
- You document your progress
- You meet new people, give and get help along the way
- You make notes about what you’re studying, which helps you remember it.
- This ignites your motivation to continue learning and building.
- You build your brand, but that’s secondary.
If you want to start 📣
- What blogging platform?
What am I going to do? 📅
- 1. Teaching is not the best learning technique!
- 2. It takes A LOT of time for little gain
- Plans for the future
Challenge 💪
- My SMART goal
Conclusion

Starting out 👶

In March this year, I registered on DEV community. I vaguely imagined what was the actual reason for doing that. But what I knew for sure, was that coding alone, I wouldn’t go far. The initial plan was to share my programming notes to possibly help others and gain followers. This way, I wanted to show myself to the world and meet new people.

To realize these plans, I started making tutorials about what I was learning. That’s because no one would’ve read my notes unless I’d made guides from them. And I discovered that these were not easy to make. It, first of all, took A LOT of time. But being goal-oriented, I tried to make everything to get them popular, to read how I can make my tutorials better, improve them in various ways, learn about SEO, and even switch the platform.

The mistake 🤦‍♂️

But that approach turned out to be a mistake. I found myself learning things only for the sake of making tutorials. In fact, now I have bad impressions of multithreading in Java, only because I spent a lot of time on that. Although this knowledge will certainly come in handy, I could be so much better off doing what I do now.

I’ve loved writing since my childhood. But, honestly, I didn’t really enjoy the process when I was writing those articles. In addition, except for the one that was successful, they didn’t get very popular and useful for others. So I decided to turn up to @jmfayard for some advice. He told me a very interesting thing that got stuck in my head for a long time:

On your blog, you are currently writing about race exceptions, threads, that kind of Java things.

If I had magical growth hacking techniques, and would make your blog more popular, what kind of people would you attract?

The kind of people whose primary interest are race exceptions in Java and such technico-technical questions.

There is no point in going faster in the wrong direction. Start writing about you and your projects. Write for and with your real audience.

I was relieved that I found a solution to my problem and that I no longer needed to write those tutorials. And it seems very logical, cause what you do should be aligned with your goals. My goals are:

I want to meet new people and showcase my work to others. My dream is to work in a team of passionate developers who are friends with each other and work together.

I think that communication is one of the key things on the way to success, and a very important one if I want that dream to come true. Attracting people that are interested in me, not in my tutorials, makes so much sense here. And while I chose the right blogging platform that meets my goals, I wasn’t doing the right things there.

Reflection 🤔

However, my initial plans and ideas didn’t come from nowhere. And if you do the same thing, you probably didn’t come up with this idea yourself.

Lots of people make tutorials and succeed. There are many good educators whom I follow and who give out very helpful information in an understandable way, and help lots of other devs. I think, there is some part of their followers, who are interested in them and are ready to work with them if they invite. And the bigger audience they have, the more people are in that part.

Educating work assures a potential recruiter about your experience in a certain field. Teaching others is also known as a great learning technique. What if I possess a latent passion for educating and if I make things right, I'll enjoy the process and achieve my desires?

So, I was torn between these two, by sight, contradicting choices. I couldn’t start doing both because I usually do something only when I clearly see what my goals are and how I achieve them.

The common sense pushed me to choose the second approach. But, I didn’t know what I could write about myself and my projects, unlike when it comes to writing about technical things.

Meanwhile, life went on, I engaged on DEV, and once found a post about the Virtual Coffee community. I was interested by the described level of communication. There were regular Zoom conferences and a Slack channel where people could support each other, give and get advice, talk about their wins and challenges, and work together. I was really impressed by how all of these meet my goals, I could also get an opportunity to speak to native English speakers for the first time in my life. Imagine my surprise when I found out that I was approved to enter!

But the reason I’m telling you that is that Virtual Coffee was exactly what caused me to discover the learning and building in public concept. Before that, I’d, honestly, found things like the following weird:

What was your win this week?

Michael Tharrington for The DEV Team ・ Jul 28 '23

#discuss #weeklyretro

What you learning about this weekend?

Michael Tharrington for CodeNewbie ・ Jul 29 '23

#codenewbie #discuss #learning #beginners

Build in Public: Week One Check-in

BekahHW for Virtual Coffee ・ Jul 7 '23

#beginners #learning #discuss

I thought, like, “Who cares about what you are learning or building?” and didn’t understand the guys who shared this info.
People are selfish. They wanna find something valuable for themselves in your articles.
But the warmth of the Virtual Coffee community in their monthly challenge, caused me to do some more research on this topic.

Learning and building in public 🧠

It appears that:

some people actually do care;
that’s exactly you who should not care whether somebody cares or not.

I tried to see things from a different perspective. What do people who share their progress get? Turns out there are plenty of benefits:

You document your progress 📝

You don’t just blindly go in an indefinite direction. You track your progress by regularly writing about what you achieved, what setbacks you encountered, and what your future plans are.

When you face up to a challenge, you can look back, appreciate how far you've come, and how many adversities you’ve already encountered, and get determined and motivated to continue.

Moreover, it may be even beneficial to your career, cause future employers will see the evidence that you've gained the knowledge over time.

You meet new people, give and get help along the way

Sharing your journey sparks a conversation, and lets you meet new people. Talking about ourselves is what we are usually doing in daily conversations, that's what creates new relationships.

There are so many people, who faced and will face the challenges you encounter, so you may give help to less experienced, and get it from more experienced.

You make notes about what you’re studying, which helps you remember it.

As explained in the “Make It Stick” book, recalling what you’re learning helps to put that knowledge into long-term memory, and is a great studying technique.

Everything gets forgotten over time though, no matter how hard you try. But taking notes minimizes forgetting. It will be also easier to recall the knowledge if you have notes.

This ignites your motivation to continue learning and building.

To my mind, the most important benefit of this activity is that making some public promises forces you to continue learning and building consistently. If I promise to post at least 5 tweets and 1 article a week documenting my progress, I’ll not break this promise. That’s because people will expect me to do that, and if I don’t, they’ll see me as a not responsible person.

You build your brand, but that’s secondary.

Your blog may get many views, after all. If that happens, you achieve all of these goals. Your next project will get seen and used, your future employers will appreciate your audience, your knowledge, and your experience.

However, this benefit is secondary. You write for yourself in the first place. You actually get most of the benefits even if you do it privately, publicity only introduces some more cool things and motivates you. Following this approach and trying to become famous is the last thing you wanna spend time on. Here is the reasoning ⬇️

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

BTW, I also started to notice that even educators don’t post only about technical things. Talking about their journeys and giving advice to other devs is an integral part of their work. For example: Florian Walther, Donn Felker, Rahul Pandey.

If you want to start 📣

If you plan to start learning and building in public, definitely check out this post ⬇️ for lots of valuable advice from an experienced person.

How to learn in public

Rizèl Scarlett ・ Dec 18 '22

#learninpublic #career #leadership #community

What blogging platform?

Speaking about the blogging platform, I’ll never regret choosing DEV, cause thanks to this platform, I found Virtual Coffee. I feel like DEV is the most suited for my needs.

If you, like many people, also consider Medium, DEV is about the community, whereas on Medium you’re a product. They aim for their membership program. I don't want my articles to ever become paid.

There are other platforms, but if you're on DEV and like it here, why not stay? For people like me, I see little benefit in cross-posting unless you have your own website or cross-post to LinkedIn.

I think, having a personal website is great in terms of promoting, being a better specialist in the eyes of an employer, keeping all your work in one place, and owning it.

But blogging on DEV is also a great thing to do. Don't wait until you get a website or any other resource that stops you from doing what you want.

What am I going to do? 📅

All of those look appealing, but what did you decide at the end, Daniel?

Well, first of all, I’m certain that tutorials are not a way to go. That’s still a great way if you want to be an educator, but I don’t.

And if you’re in a similar position, I would encourage you to consider learning and building in public instead of making tutorials because of these two reasons:

1. Teaching is not the best learning technique!

There are many people who will tell you the opposite. Lies!

There has never been a better learning technique than practice.

University professors may know more, but they don’t do a good job if they don’t practice in side projects, or don't work at some company. On the contrary, good educators often work as freelancers or make their own projects.

I don’t argue that teaching is great. It's the best after practice. It's great when you quickly explain a learned concept to your mate, but a different story when you spend a lot of time when you could be better off applying that knowledge to personal projects.

2. It takes A LOT of time for little gain

As I see it, to get successful in educating, you should do that seriously and firmly by growing your social media, publishing consistently, eventually transitioning to YouTube, etc. Otherwise, you will not get popular and will not make a profit from this. Therefore IMO, this does not worth that amount of time.

In addition, there are lots of people who are already in that business. They are doing well. The are a lot of great learning resources nowadays. So there is a lot of competition and if you want your guides to really help people, you should make them better than existing ones.

Plans for the future

However, understand me correctly, if I’m learning a difficult topic and I don’t seem to find any resources that would explain it well, I’ll certainly make my own article with an explanation. That’s what I did in this post ⬇️

Delegation vs Inheritance in Kotlin

Daniel Rendox ・ Jul 5 '23

#kotlin #tutorial #oop #programming

On the other hand, the concept of learning and building in public combines almost all the benefits of talking about your journey and writing about technical things. This approach is the most suited for beginners. That’s what I plan to do in the first place.

And I’ll try to make these posts helpful for other people so that they could benefit from my journey and get some advice.

And there are also general topics when you write about your experience in life, programming, etc. This, obviously, attracts more people than some tutorials about Race conditions. And these people are my real audience. That’s what I plan to do in the second place.

Challenge 💪

For me, this idea of learning and building in public seems very exciting. This really stirs up my productivity soul, taking into account that last time I’m trying to stabilize my schedule. So I wanna take the following challenge:

At the end of each day, at least 5 days a week I’ll post on my Twitter about what I’ve learned and made today.
And over on DEV, I'll write at least 1 summary article every week, talking about what I did, what I learned, my wins, and difficulties.

My SMART goal

Specific: I want to learn Android to get a freelance job and create an Android app to practice my skills, get myself organized, and help other people.
Measurable: I'll spend at least 40 hours a week learning and working.
Attainable: I'm already familiar with Jetpack Compose, Kotlin, and the View system, so I have about 30% knowledge of Android.
Relevant: After I achieve my goal I see further development in Kotlin multiplatform, Android is widely used and in demand, and I’ll certainly get relevant knowledge that’ll come in handy in my career.
Time-bound: I’ll give myself 2 months. In this period of time, I should have the app with the basic functionality.

The challenge starts today!

Conclusion

So write about you and your projects. Absolutely recommend considering learning and building in public. Don't care much about getting famous, write for yourself in the first place.
With that being said, I think I'm on the right way now, I hope you're too, my dear reader. Either way, let's just do what we like and follow our passion.

Delegation vs Inheritance in Kotlin

Daniel Rendox — Wed, 05 Jul 2023 14:33:18 +0000

Hello, everyone! Welcome to the article about class delegation in Kotlin. This tutorial will help you understand how to use class delegation in Kotlin and when to use it instead of inheritance.

The examples in this article are not mine and were taken from this article with some changes applied. It provides a good explanation but, to my mind, lacks some things crucial for understanding. So I brought them up here.

Why use delegation instead of inheritance

Let’s say we want a list’s item to be recoverable after deletion. To achieve this, we need to implement MutableList, override the remove function, and create our own recover function. But to do this, we need to override other methods that the MutableInterface tells us. So we essentially need to create our own implementation of MutableList. That’s not a cool thing to do as all the code is already written for us.

To avoid creating our own list, we can extend ArrayList instead. But this approach is not good for abstraction. We don’t want this list to be an ArrayList. We don’t need ArrayList's specific methods like trimToSize, ensureCapacity, grow, etc. We just want to have an additional function.

So there is a better way to achieve this. And this is delegation. We want to have only MutableList's functions overridden by ArrayList and our own implementation of remove.

How the delegation pattern works

We need to create a new variable of the ArrayList type and, at the same time, implement MutableList. And then in all the overridden functions’ bodies, respective ArrayList's methods should be called. For example,



class ListWithTrash <T>(override val size: Int) : MutableList<T> {

    private val innerList: MutableList<T> = ArrayList()

    // the variable for storing the last deleted item
    private var deletedItem : T? = null

    override fun remove(element: T): Boolean {
        deletedItem = element
        // calling ArrayList's method, not our implementation
        return innerList.remove(element)
    }

    // here is our own function for recovering elements
    fun recover(): T? {
        return deletedItem
    }

    override fun add(element: T): Boolean {
        // calling ArrayList's method, not our implementation
        innerList.add(element)
    }
}

In this example, we override only add and remove MutableList's methods. But we have a bunch of other methods we have to override for this to compile. That’s a lot of boilerplate code!

How to delegate using `by` keyword

Luckily, we don’t need to do this. That’s how it works internally. Kotlin provides first-party support for delegation, and all this is done automatically under the hood. A developer's task is to use the simple by keyword:



class ListWithTrash <T>(
    private val innerList: MutableList<T> = ArrayList()
) : MutableList<T> by innerList {
    private var deletedItem : T? = null
    override fun remove(element: T): Boolean {
        deletedItem = element
        return innerList.remove(element)
    }
    fun recover(): T? {
        return deletedItem
    }
}

In this example, the innerList variable was also moved into the constructor to let the users of ListWithTrash provide their own ArrayList. This allows them to specify the desired list’s properties, for example, its size.

This is called delegation because along with our own implementations, the rest of the functions are delegated to the other classes. In our case, we delegate MutableList implementation to ArrayList. The necessary functions are “provided by” ArrayList.

Again, ArrayList's specific functions won’t work:



val listWithTrash = ListWithTrash<String>()
//    listWithTrash.trimToSize() // → exception! (ListWithTrash doesn't have this function)

If you need them, extend from ArrayList directly.

Multiple delegation is… allowed

May 29 '17

Also remember that you're not restricted to just one delegate. Kotlin's way of implementing delegation is similar to traits implementation in languages like Groovy. You can compose different functionality via delegates. Kotlin's way can also be considered more powerful because you can "plug in" different implementations too.

interface Marks {

…

Open Full Answer

Delegation vs Inheritance

Inheritance allows to get a ready implementation by extending from the respective class. Whereas class delegation allows making a custom inheritant without lowering the class in the hierarchy. This is done by “copying” the ready implementation from the delegate. Here is the scheme for our situation:

This scheme is not entirely correct because ArrayList doesn’t extend from MutableList in Kotlin. But the idea stays the same — our class (ListWithTrash) and the delegate (ArrayList) are on the same level in the hierarchy. Check out the cover of this article.

When to use which? Use inheritance only when you are sure that your class and the class you inherit from share all the common traits. If you think your class doesn’t need some variables or methods from its possible parent, and “is a” relationship doesn’t apply, it’s better to use delegation.

That’s it! If this article was helpful, please, like it and follow for more. If you have any questions or corrections, feel free to write in the comments.

A Simple Technique to Achieve Your Goals with Consistent Action

Daniel Rendox — Mon, 03 Jul 2023 13:59:32 +0000

Hello, devs! After trying out various tools and systems people use to organize their time and projects, I think I finally found a simple yet effective technique that works for me. And I'm happy to share it with you.

Step 1 — Find out what you actually should do

So you have a goal. You vaguely imagine what steps you are going to take to achieve that goal. But if you don't know what you actually should do, you might end up simply going with the flow and working without a clear direction.

Let me provide an example. There are lots of people who want to learn English. But most of them fall into the common trap. From time to time, they need English and realize how many opportunities it opens for them. They get super excited, start reading books, learning grammar, etc. However, as time goes on, they find out how much effort is needed to learn English and start thinking: "I've managed just fine without English all this time..." Consequently, their learning comes to a halt, only to resume when the same cycle repeats itself.

I'm not a native English speaker, and I used to fall into that trap too. So don't make this mistake. Find out how much effort is needed at the beginning and make a firm decision.

Divide that big goal into the smaller ones that you can achieve in a week or month. This way, you will be happy to complete the goal and feel motivated to pursue the other ones.

Step 2 — Make it a routine

Having a concrete plan is good, but you won't go far if you don't take action. It's always recommended to take action consistently and make it a habit.

But I don't really like the word "habit". That's because a habit is meditating every day, going to bed at the same time, giving up smoking, and so on. You just do the same action consistently to, hopefully, improve your life. To track a habit, you don't need much information. You either completed the task or not. That again reminds me of going with the flow.

Whereas "routine" refers to a habit with a concrete goal and a plan. To track a routine, you should know what you actually did and at what pace you are going.

So allot a separate time to consistently move towards your goal. Make it a routine, and make sure that you complete the planned amount of tasks each week.

Step 3 — Track your progress

I prefer to always know the time frames. Deadlines may not help because it's often difficult to estimate the time required for each task.

I propose a different approach. Transform the tasks you set in the previous step in a way that they take roughly the same time. And just start doing these tasks. You'll eventually determine the pace you are moving at and will be able to roughly estimate the date of the completion day.

This way, you'll be motivated to continue doing the tasks. That's because otherwise, the completion day will get further from you.

This also helps when you want to do some other things for which you don't have enough time. Knowing how much it's going to take will help to rationally allocate your time among the routines.

For example, I often initially imagine small-scale projects, but over time, they tend to grow more ambitious. If I were to go with the flow, I would immediately dive into developing new features. However, adopting this approach forces one to think whether it's reasonable to start doing that at the present moment. Maybe it's more appropriate to add the desired features later when the core is ready.

Implementation

To give you a real picture of how it works, I'll provide an example.

Last time I've been learning Kotlin. The first thing I did when I started was find good learning resources and make a plan. Then I decided to dedicate 6 hours of work each day to this goal and started working.

As I knew Java, it took me approximately a week to learn the essentials of Kotlin. But then I estimated the time needed to learning the higher-level things. I found out that it'll take me another week or even more.

But I planned to learn Jetpack Compose. And dedicating nearly the whole workday to learning the advanced Kotlin stuff didn't seem so attractive. Putting Jetpack Compose off may have led to burnout since I wouldn't get much closer to building my Android app.

I knew that advanced stuff wasn't so necessary to understand Jetpack Compose. So I decided to dedicate 4 hours of work to Jetpack and only 2 to higher-level Kotlin instead.

That's why estimating the time is the most important thing here.

Conclusion

I believe that if you use this simple technique, eventually, it will be easier to determine time frames. The work will become habitual. And you may magically complete your goal on the desired day without even realizing how you reached that point.

But remember that no organization tool or productivity technique will help if you don't like what you are doing.

If you have a goal that excites you, productivity will come from alone. [author]

Spend time doing what it takes not searching for the best tool.

That's it for this article. I hope it'll help you! What are your thoughts about this? How do you get organized? I'd love to hear from you in the comments!