What is Self-Image, and why it's so important?

My close friend recently asked me how do I work out every day? How did I develop such consistency?

I took some time to think about how I make habits stick in general and what helps me wake up every morning and work out. I guess I've finally found an answer.

The answer is Self-image.
It is all about how we perceive ourselves. What kind of person do we think we are, and what do we believe others think about us.

It all comes down to 1 simple idea. You do what you think you're supposed to do as a person from your self-image. For example, if you think you are a shy person, it's unlikely that you'll start a conversation with a stranger in the bar.

I know. It may sound ridiculous. Like another useless mantra from an amazon bestseller self-help book. But it works.

So, in my case, my self-image tells me that I am a sportsman (as I've been professionally playing tennis for 11 straight years.) So I do what I'm supposed to do. I don't need any motivation or discipline to keep it going. Somebody may call it a habit. Maybe.

I also consider myself a consistent and responsible person who keeps his word and likes to build new habits, to try something new.
- It helps me to do everything before the deadlines. Of course, if they are adequate.
- Plans work as a promise to myself to do something. So, I do it.
- I like taking up new challenges. Meditation for a month or solving a couple of problems on Leetcode every day (yet to come).

Of course, there is also a negative part of my Self-Image.
Back then, when I was playing tennis, I thought I have a terrible backhand. So, my backhand was magically disappearing during the tournaments.
I still think that I'm a bit shy and not-talkative person. And if I don't have a strong reason to talk to some stranger, I won't.
And never ask me to solve some Physics problem. I'm the worst at it.

Self-image forms unconsciously from our past experiences, successes, and failures. And there is a way to change it. It takes a lot of time and effort, but it is the easiest way to alter your behavior, not for a month or a year (wasting all your willpower), but for as long as it is consistent with your self-image. If you're interested in it, read this article on Medium.

Do you use the best tools money can buy?

I'm not a money-waster.
When I need to buy something, I think like hundred times if I need this particular thing and where it'll be in several days/months/years after the purchase. But when it comes to investing in myself and my tools, SHUT UP AND TAKE MY MONEY.

I've upgraded my laptop two times. In both cases, I was thinking about how it would make my job easier and more efficient. In both cases, I regretted not getting them earlier. I still believe making these purchases was the best choice at the moment.

After the first upgrade, I was able to develop web projects in professional IDE. So, I've made like 5-6 small web apps (Python/Django) in 2 months and got some pocket money and a hell of a lot of experience.
After the second one, I gained the ability to develop Flutter apps for iOS and macOS and decreased an app build time by 200%. It allowed me to look for new job opportunities and explore an App Store Connect (better keep away from it).

I've made an example of my laptop because it's the most crucial tool in a programmer's inventory. That goes without saying. The same approach applies to additional hardware&software, working place, and other things that can make my life as a programmer more enjoyable and efficient. The more I can remove avoidable stress and frustration from my daily routines, the better the work I'll be able to deliver.

So, don't ever try to save money on your tools. Upgrade and open up new opportunities.

P.S. Don't take it too far. If you don't have enough money at the moment, try to save up a bit. Taking a loan may not be the best decision in your situation.

It's not rocket science

You don't need to be smart to be a programmer. There are many areas in IT, that don't require you to be eggheaded. You have a language, framework, and many ready-to-apply approaches, that cover almost every use-case you'll need to implement during the development of your app.

Building a typical mobile client requires you to know how to:
- get and send JSON
- handle authentication (JWT token in most cases)
- create a layout based on a design in Figma
- UX (just a bit) to keep a user informed on what's happening in your app
- navigate between screens
- add payments, subscriptions
- add notifications
- add localization
- cache data
- implement the basic architecture, at least separate different layers of your app

It seems like it's a lot, but here's a trick. You can easily find manuals for all of these things in docs, on youtube, or somewhere else. Do it once and learn how to do it even better and faster in your following projects. In some cases, you can apply a "special" copy/paste technique. And you are a newborn developer.

Of course, most likely, your first apps will be unscalable and unmaintainable (in Russian: gavnocode, in English: suboptimal code). But it's totally fine. I firmly believe that only practicing and reading deep books make you a better programmer.

On the other hand, there are also complex apps that require all of your problem-solving skills and some deep knowledge to come up with unique solutions to unusual problems. If this is the case, congratulations! Your job is not so tedious.

Learn in public

I've discovered this concept a year ago or so in a Coding Career Handbook. Its author claims that this is "the fastest way to build an expertise, network, and second brain." Sounds cool, right?

The main idea is to open-source your knowledge, share the process of learning a new thing with other people in the form of an article, youtube video, conference speech, etc.

Why should you start learning in public?

- To deepen your understanding of your work. The protégé effect in action. While trying to explain a new concept to somebody, you're gaining more understanding of this topic and closing all the gaps.
- To keep yourself accountable. If you have an audience, at least one person, it will be harder to give up on everything and stop posting. You probably don't want to be that inconsistent person in your reader's eyes.
- Fast feedback loop. Cunningham’s Law: "The best way to get the right answer on the Internet is not to ask a question; it's to post the wrong answer."
- To create a reviewable archive of your knowledge. Building a knowledge base to which you can refer at any given moment (you can also do this in Notion or any other note-taking app).
- To connect with others along the way. You'll get new friends, colleagues, mentors by simply showing up.
- To set yourself up for new income-generating opportunities. You build a self-brand. You promote yourself as an expert in your area. Potential recruiters may seek you out themselves for one of the 80% of jobs that are never published.

I recommend you to read this free chapter of the book I've mentioned above to find more reasons on why you should accept the idea and make the first move.

I've already started applying this principle by sharing my general knowledge and experience with you and tech knowledge with my teammates. I do plan to expand in this direction cause it works, and I enjoy it a lot.

Embrace boredom

Can you put aside your phone for 30 minutes and sit in silence one on one with your thoughts? It sounds so easy, isn't it?

We live in a world of distraction. Our brains got used to multitasking and escaping boredom at all costs. Can you recall yourself having a long ride on public transport without looking at your phone? Do you often find yourself reading news, scrolling Instagram, or watching Youtube just not to feel bored? Why don't we like boredom so much?

Our hatred for this state is so extreme that in some cases, people would prefer being in pain to being bored. There was an experiment where students had to sit alone in a room with a shocking button for a short period of time (6-15 minutes). A quarter of the women and two-thirds of the men preferred to give themselves mild electric shocks to be somewhat entertained than to think. How crazy is that?

I don't have an answer on why we can't stand the boredom and always need some stimuli. But I believe that a bit of boredom is what we need to be more creative and productive.

Several experiments show that people are more creative after doing some boring monotonous tasks. My experience and Cal Newport's (author of "Deep Work") observations show that experiencing a lack of entertainment also boosts our ability to concentrate on some task for longer periods.

Moreover, I'd say that trying to avoid boredom but having no access to social media makes me want to start my work as soon as possible. This is why I like detox (no Youtube, no Instagram). You should definitely try it out as a one-week challenge. I'd like to hear about your experience and what you think about it.

P.S. Don't take it to extremes. Don't try to stay in total isolation for 3 days like this crazy guy.

The easiest way to get your first job (as a developer)

Vacancy requirements for a mobile developer usually look like this:
- Several published apps (AppStore/GooglePlay)
- Coding a layout from Figma
- REST principles
- CI/CD
- Some advanced state management approach
- Some libraries used by this company/team
- 1-2 years of experience

And why do all these points matter (except for the last one*)?

The answer is quite simple. Small business needs an app from scratch here and yesterday. And if you've built something cool already and managed to deliver it to the audience, probably you'll do it again. No matter how good it will be from a code perspective.

Congrats if you've already made several apps that appeared in stores. You're on fire. Everybody wants you. But what to do when you want to land your first job?

Most programmers learn fundamentals and practice them here and there by building small nobody-cares-about apps. But in this case, they miss out on a large part of app development. Architecture, theming, CI/CD, testing, different capabilities like notifications, in-app purchases, and much more.

The easiest way to stand out from the crowd of juniors is by building a production-ready app and posting it to the store. I talk about real pet projects. Not tic-tac-toe or another to-do app. This way, you'll cover the whole project lifecycle.

You probably already have an amazing idea for an app. Find a free API or create one with some cloud backend like Firebase. Get a mobile app design sample from google. Create tasks in Trello or somewhere else. And start coding. Screen by screen. Feature by feature. Try to touch every point from vacancy requirements.

I know it's hard to build something great** because you don't know how to structure your app, divide it into layers, why it even matters, and many useful tricks and hacks. Find a person who will review your code. Then fix everything and ask to review it again.

Voilà. You've just increased your chances to land a job by 1000%.

*I don't think that measuring experience in years is an accurate approach. It highly depends on the person.

**I've built a quiz app with the help of Firebase. I've changed my initial design in Figma to make it look more modern. I've changed state management to more advanced when I realized that my code is highly coupled, and it becomes harder and harder to maintain it. I refactored it a couple of times, added theming, linting, and localization in the process. Today I can see that there is so much more to refactor. But I've learned a lot during the development process.

Some thoughts on this channel

Hello, my friends. It's been about a month since I've started this channel. And there are already 10 posts in here. These posts mostly are about good habits + efficiency. I appreciate all of you who were reading them. Hope it was valuable.

Also wanted to add that I fell in love with writing. Although, it's super hard for me. I still spend plenty of time writing one post. Partly cause it's hard to put my thoughts on paper, partly due to the fact that English is not my native language. No pain, no gain)

I think it's time to introduce new topics/rubrics. Maybe, make this channel a bit more technical, a bit more about Flutter and mobile development in general. Since there will be more topics, I want to add more structure by using hashtags. #efficiency, #habits, #career, #learninpublic, #books, #dev, #flutter, #thoughts and more.

I've recently written about learning in public and its benefits. Yesterday, I set a goal (actually, goals) for myself until the end of the year. It's connected to Flutter and animations. From now on I'll post my progress here under the hashtag #learninpublic. Wish me luck!

6 invaluable things I would tell myself when I was new to coding

1. Don't be a perfectionist
I've always considered myself a bit of a perfectionist and thought it's cool. No matter what, I've tried to do something in the best possible way, cover all possible and impossible use cases. Sometimes it led to horrible procrastination. In one case, it was a fear that I couldn't do it perfectly that made me put off the task. But most of the time, I was polishing everything up again and again just until the deadline instead of iterating several times and fixing not-so-obvious bugs before the deadline. I'm still trying to find a "perfect" balance.

2.Don't be afraid to go deeper into tools you are using
Just don't use everything as a black box. For example, if you use Flutter for building mobile apps, you won't be able to create a robust app without knowing some framework's internals. You can easily block the UI thread by doing complex calculations, so the user will think that the app is broken. If you knew that you should have used another isolate (because all your code by default runs in UI thread) for this kind of task, you'd be better off.

3. Learn how to debug, please
Yes, yes. Debugging is not inserting print statements in any situation. It's logging. Learn how to use breakpoints, so you can inspect the entire program state, not just the values you thought to print out in advance. This can massively speed up the bug-fixing process.

4. Bugs are inevitable
"If debugging is the process of removing bugs, then programming must be the process of putting them in" - Edsger Dijkstra. We are human beings. We make mistakes. Sure, there are all sorts of techniques to decrease the number of defects in software, but none of them can prove the absence of bugs.

5. Write code every day
Every day is just another opportunity to learn something new. Consistent practice makes perfect. This guy has managed to do it, so you also can.

6. Use code generation whenever possible
I'll never write another toJson/fromJson method. There is just no reason to write more code when you can write a short description of what you need, and a generator will be willing to make it happen.

#career #dev

Server-Driven UI (SDUI)

In a traditional world, data is driven by the backend, and the UI is driven by each сlient (web, iOS, and Android).
Let's take products listing. You get a JSON with data like: [{"title": "iPhone", "price": 999}, {"title": "MacBook", "price": 1999}, .....]. The client parses this JSON into List<Product> and shows products to a user with predefined UI logic which is hardcoded on the client.

This comes with a few issues.

The most obvious one for me is the versioning problem, which applies only to native apps. If we do things this way, each time we want to add a new feature to our listing page, we need to release a new version of the app for each platform. Most probably, you'll have users that always protract with updates.

This leads to another problem - A/B testing is harder. It's more difficult to validate ideas and extract data from users’ interactions, which could be used to conclude important things about the product.

Many big fast-growing companies like Airbnb, Ozon, Avito have faced these problems and created tools to overcome them.

Let's take Avito - the service where you can sell and buy literally anything. If a user wants to place an ad to sell a flat, the app will show input fields like address, floor, number of rooms, square meters, etc. If a user is selling a car, he sees fields like model, year, mileage.

Okay, you've, as a good developer, foreseen every possible type of product and written a huge amount of complex logic on the client to show required fields based on the selected product type. But the world is constantly changing, and now your users want to sell NFT tokens here and now. What will you do?

The first solution is to add another piece of logic on the client-side and release a brand-new version. I've already mentioned the problems of this approach.

The next one that comes to my mind is to show a WebView. The thing is nobody likes them. They don't offer native UX and often have performance issues.

And the last one is to add a new type of product with some rules for input fields on your backend (from the admin panel, for example) and send it to the client so the client can render the necessary fields. This strategy is called Server(Backend)-Driven UI.

Of course, it's not perfect either.
It's hard to build from scratch and maintain, which makes it expensive. And maybe one day, you'll like to add some fancy type of field or section, so you'll end up releasing a new version.

#dev

Parkinson's law and how to hack it

I've already mentioned this law in one of my previous posts.

"The work expands so as to fill the time available for its completion. Thus, an elderly lady of leisure can spend the entire day in writing and despatching a postcard to her niece at Bognor Regis. An hour will be spent in finding the postcard, another in hunting for spectacles, half-an-hour in a search for the address, an hour and a quarter in composition, and twenty minutes in deciding whether or not to take an umbrella when going to the pillar-box in the next street. The total effort which would occupy a busy man for three minutes all told may in this fashion leave another person prostrate after a day of doubt, anxiety and toil."

It's an excerpt from the original essay of Cyril Parkinson written in 1955 where he described this law for the first time. The main goal of this essay is to show the natural tendency for officials to make more work for each other. He even gives us convincing proof from the history of the British Admiralty from 1914 to 1928. While the number of ships and marines decreased by 67.7% and 31.5% respectively, the number of Admiralty officials increased by 78.5% over a period of fourteen years!!!

This is all very interesting and the full essay is totally worth reading, but the main goal of my post is to make you more efficient. And that's why I've taken the first paragraph of Parkinson's work with a story about an old lady. How often do we find ourselves in a similar situation, when we have so much more to get done? I do more often than wanted.

I can't say that the woman has made something terribly wrong. If she had no other things to do during the day, then why not? I even want to compliment her on putting and meeting some kind of deadline (the end of the day).

- But it's not our case. So what can we do to use our time more efficiently?

- In short, set clear deadlines and meet them.

- Really? That's all?

- Almost. There is a catch. This strategy may not fit every task from your to-do list. Furthermore, in some cases, if you do it wrong, it can even lead to bad consequences.

- Will you tell us about everything?

- I'll do my best in one of the next posts. For now, you can read a short interesting study on self-imposed deadlines from MIT uni. It answers 3 important questions:
1. Do people self-impose costly deadlines in tasks where procrastination may impede performance?
2. Are self-imposed deadlines effective in improving task performance?
3. Do people set their deadlines optimally, for maximum performance enhancement?

#efficiency #habits

Cloud computing or all kinds of *aaS

Initially, I wanted to write a post about Serverless. I've started researching and found out that my understanding of Serverless is not clear, at least in terms. The biggest discovery for me was that Serverless and Cloud are not interchangeable words. Therefore I've decided to make a quick overview of existing approaches before diving into one of them.

We will start with the Big Three of cloud service models: IaaS, PaaS, SaaS, i.e., Infrastructure as a Service, Platform as a service, and Software as a service. Big companies like Amazon, Microsoft, Google cover all of them. Google Cloud is IaaS, Google App Engine is PaaS, Google Drive and other services for end-users are SaaS.

IaaS provides users with hardware — servers, storage, network as an on-demand service. It gives a lot of flexibility, but at the same time, it requires users to install and configure needed software on their own.

PaaS offers an infrastructure, OS, middleware, database management + some additional software to develop and deploy applications. Probably, you've used Heroku to host your website for free. It's one of the first platforms of this kind. Another good example is Google App Engine. It is a product that provides Web app developers and enterprises with access to Google's scalable hosting and Internet service. The App Engine has limited language support. You're allowed to store data only in Google Cloud Storage services and use the Google query language. We are losing flexibility...huh?

SaaS is a way of delivering applications over the Internet—as a service. Instead of installing and maintaining software, you simply access it via the Internet, freeing yourself from complex software and hardware management. Google Drive, DropBox, Zoom, all kinds of CRM/ERP solutions, you name it.

Before the Serverless the most effective way to build SaaS applications was to develop microservices, deploy them on a Platform as a Service and let the PaaS manage a lot of things. Serverless is just another degree of automation that lies between PaaS and SaaS. It usually includes two concepts: Backend as a Service (BaaS) and Functions as a Service (FaaS).

BaaS makes your app a "rich client." You are not building REST-APIs anymore. Now your client application talks to the database directly with an authentication layer in front of the database. Google has a Firebase platform, and Amazon has Amplify with Cognito for authentication purposes.

With FaaS you're still able to build REST API, but, unlike traditional architectures, server-side logic consists of independent functions that run in stateless containers that are event-triggered, ephemeral (may only last for one invocation), and fully managed by a third party. AWS Lambda is one of the most popular implementations of a Functions-as-a-Service platform.

You can use just one of them or both at the same time. For example, you're building a chat app with Firebase (BaaS), and you want to send a push notification to users that receive the message. You add this message to your database on the client, and this event triggers a cloud function (FaaS) responsible for sending push notifications to specified users.

There are two big benefits when using one of these as-a-service models:
- Faster time to market. You don't need to reinvent the wheel and manage it.
- Resources sharing lowers costs. In some cases, you may even have free monthly/weekly quotas.

The main drawbacks are:
- Vendor Dependency. You're playing by their rules now.
- It may be hard to integrate with existing infrastructure.
- You may face security issues.

If something is not clear, look at the pictures below.

#learninpublic #dev

Read the source

What is the best way to become a better writer? Reading more. The same concept can be applied to programming.

I've been reading a lot of source code recently. Of course, not for fun. I had a troublesome task I'd never done before. Therefore I didn't know where to start.

So I've git-cloned an open-source library that solved a similar problem, and decided to adapt it to my needs. Little did I know what awaited me. I wanted to take the path of least resistance but found myself reading and understanding the code written by a stranger. Luckily, the package was small and relatively simple. However, I've managed to learn a lot of new things and changed my view on this topic.

Here is how reading sources may benefit you as a developer:

- It may help you to learn from gurus. Let's imagine you know a skilled programmer, but he is not as public as he could be. There is no conference with him on youtube you could watch or blog you could read. However, he contributes to open-source. The only way to learn from him is to read his code and try to understand something.

- Sometimes it's easier and faster to read the sources than look through docs or watch a tutorial on Youtube. Moreover, library creators often leave many comments in their code.

- You'll learn how popular libraries work under the hood and will be able to choose the most appropriate one. I often see heated debates about state management libraries/approaches in Flutter. How one is 1000 times faster and more convenient than another. Hello, GetX versus anything else. Everything in Dart/Flutter world is open-source. So try to understand how does it work.

- You develop a crucial skill - reading code. It's not a secret that an average developer spends more time reading code than writing. So, read more code to read code more efficiently.

- You may start contributing to open-source. Many companies appreciate it when hiring a developer. Maybe you'll add a new feature that many people need or fix an annoying bug when the maintainer has no time for it.

CAUTION! You can also face suboptimal code when sneaking through GitHub repositories. How to distinguish the good from the bad? I think you should know the basic "code smells" and have a bit of experience to trust your guts.

#career #dev #efficiency #thoughts

My Flutter story

Probably, this is one of those topics I'm the most excited to write about. The story began 1.5 years ago when I wanted to develop an app for learning new English words. If you'd asked me why didn't I take one of plenty of existing apps, I wouldn't have a rational answer. I've needed a brand new app for Android and iOS to study English with my girlfriend. (Spoiler Alert! I've never written one.)

So, I've started to look for ways to build such an app without learning Android/Kotlin and iOS/Swift. I've stumbled upon a video on YouTube that was comparing several cross-platform technologies. I guess they were React Native, Xamarin, and Flutter. I despised weakly-typed Javascript and Microsoft's version of Java - C# that went in pair with the first two technologies (I haven't even tried to understand how these frameworks work internally). At the same time, I've needed a breath of fresh air. So, I've started a pretty long course on Flutter/Dart (40+ hours) on Udemy and completed it in two months.

Probably somewhere here, I need to give a quick intro to the framework for those who don't know what it is.

Flutter is an open-source UI SDK created and released by Google in 2017. It is used to develop natively-compiled multi-platform apps from a single codebase, i.e., apps for Web, Desktop (Linux, Windows, macOS), and Mobile (Android, iOS). I think Java's slogan can be applied to Flutter: "Write once, run everywhere."
The framework heavily relies on Dart language (another invention from Google). So Flutter developers mostly write Dart code. For me, it is something between Java and Javascript. Not so cumbersome, but still statically typed.

Enough of theory for now. I'll need another post to list all the features of the Flutter/Dart stack and tell you what makes it better/worse than other solutions.

After the course on Udemy, I started making a Quiz app for my Mobile development classes at Uni and learning new libraries and approaches from ResoCoder's videos, the official Flutter channel on YouTube, and different thematic conferences like DartUp, Mobius, Flutter Live/Engage/Interact. Not to mention that I was freelancing with Python/Django here and there at that time. I've become acquainted with many topics: declarative UI, streams, state management, architecture, error handling, networking, Firebase, caching, theming, localization, notifications, and more.

Seven months after I first heard about the framework, I landed my first job as a Flutter developer. Since then, I've been working on several projects, and most of them are under NDA.

#flutter #career

Soft Skills: The software developer's life manual - book review

Several years ago, I was that kid who thought that the mainstream for Soft Skills in IT was totally weird. I believed it was all about communication with others, and introverts can't be effective in this field. Since then, I've learned the number one rule for effective communication with others: "Don't be an asshole," and life became a bit easier.

Moreover, it turned out that Soft Skills are not only about communication. There are also skills like time management, self-motivation, self-marketing, adaptability, critical thinking, learning, and more.

So, if you're interested in mastering these extremely valuable skills as I am, I highly recommend you to read John Sonmez's book "Soft Skills: The software developer's life manual." The author is a developer and a life coach, founder of Simple Programmer website, owner of two youtube channels (1,2). He is now selling out a lot of courses on related topics, but that shouldn't bother you. The book has minimum amount of water.

I think this is the most up-to-date book on Soft Skills for developers. It is divided into 7 sections: Career, Self-Marketing, Learning, Productivity, Fitness, Personal Finances and Spirit. You can read it from cover to cover, or pick only those topics you're interested in. For example, I've quickly sifted through the first chapter about career 'cause I've read a lot about it in other books, and attentively read next chapters about self-marketing and personal finances which were quiet useful.

The book is easy to read, and chapters are really small which allows quickly reading one of them while riding public transport. Moreover, it is full of practical examples, personal stories and assignments, so you could start "softly" upgrading yourself right away.

So, I'm 100% sure that it's worth reading for all software developers who understand that having great Hard Skills are not enough anymore for a successful career.

#books #career

How to pass a test task

Hi there. I've been checking a lot of pre-employment test tasks recently as a part of my job and noticed that all junior developers fall into similar traps. And here is a little post on what you should pay attention to, so the reviewer will approve your code, and you'll get more chances to land the job.

Usually, test tasks for mobile developers look like a simple app that an average junior developer can create in one weekend/week. Some companies may place greater emphasis on the UI part, some - on client-server communication or something more specific to their current project. The checklist below is a must-have in any of these cases.

Two main things I'm looking for in a test task while reviewing are the usage of the stack we use in our company and code cleanliness + overall tidiness.
Why? I want to be sure that my potential colleague will start delivering new features ASAP, and his/her code will be maintainable.

Here is a full checklist:

1. Reuse your code. Try to follow DRY and SOLID principles.

2. Don't overthink architecture: divide your code into well-defined layers. If you have no idea how to do it, ask somebody more experienced from the community.

3. Use the company's tech stack. I often see companies mention some libraries and approaches in their job requirements section. Show that you know them.

4. No commented out code, no logs. That's it.

5. Use linters. It may help you to follow the style guides of the language and/or framework. It annoys me when I see files like SomeUsefulClass.dart instead of some_useful_class.dart, or functions returning dynamics instead of defined types.

6. Don't forget about basic Dependency Injection

7. Think about basic UI/UX principles: no fancy fonts, no tiny/gigantic font sizes, no colors that contradict each other. If you are not a designer and Figma was not provided, try to make it as minimalistic as possible. When waiting for the response from the server, make the user know that something is going on - show a loading indicator. If something went wrong, show a clear error message. Remember, "An error occurred" is a bad one.

8. Run your code before submitting it. Don't waste the reviewer's time making him git clone, build and run your app only to see that it crushes.

9. Bonus tip: write a clear Readme. Just a basic description of the app is enough. Maybe nobody will notice it, but I always do.

If you have something to add, write it in the comments.

If you're a junior looking for a job, break a leg🍀

#career #dev

Choosing the perfect language/techology to work with

Before Flutter, I didn't know what I wanted to do as a programmer. I've tried different languages and technologies in university and by myself, and nothing made me happy.

I've taken a half-year online course on PHP/Laravel for beginners at school. Created a simple website for a cafe and forgot about this technology. Moved to Russia, where everyone around was saying that it is not mainstream anymore. "Look how cool are Python and Node.js," they said.

I've started learning Python/Django during my second year at uni. Learned a lot (at least I thought so) while working on small projects as a full-stack for other students. Several times in 1,5 years period tried to land a job as a python backend developer - failed. Funny that I've actually couldn't answer questions like "What is a hashtable lookup time complexity? What is a context manager in python?". Yeah, my knowledge of theory sucked. So I've decided to read Mark Lutts' thick book on python and try again - failed.

One day, I was looking through vacancies on HeadHunter and realized that there are so much more Java backend developer vacancies for interns and juniors in Saint-Petersburg. More vacancies - more chances to get a job. So I've started to think about switching to Java. And I've almost done that. I've tried and wasn't excited about it at all. I wanted something cooler and trendier, like Node.js.

Hopefully, at that very time, I've stumbled across Flutter. I've tried it out, liked it, and decided to do as much as I can to get my first software engineering job in a company - success.

What is the moral of the story?

This post's initial title was "The sooner you decide on what you want to specialize in, the better." But in the process of writing, I've realized that this is just half of the truth. Another half in that you should try to know what you like the most. And even if you choose to switch technology, you still have some knowledge and experience, that may be applicable in the future.

At the end comes this moment, where you have to commit to hard work for several months/years. Focus on consistency. Have a road map with clearly defined milestones. And you will succeed. Cause after all, programming is not so hard.

#career #thoughts

Procrastinate like a PROgrammer

How do people usually define pi variable (without math library) in their code:

Dart: var pi = 3.1415926535;
Python: pi = 3.1415926535

Stop it. This is just boooooring. Learn Rockstar language created by Dylan Beattie to become 'CERTIFIED ROCKSTAR DEVELOPER' and your code will look like a hard rock song from the 1980s.

Rockstar: My heart was ice. A life unfulfilled, wakin' everybody up, taking booze and pills

With its syntax, even the worst code can look like a piece of art.

There are people all over the world who like coding for fun creating many interesting things. Have you heard of naked html or generative art, or maybe a program written in C that looks like a donut that produces a 3D rotating donut in terminal?

Watch this video from a conference with a charismatic guy, I've mentioned above and have fun 🔥🔥🔥

#fun

Mental programming by Kirill Mokevnin (2021). Easy to follow rules to write good code.

1. There is a difference between understanding the code and understanding the problem it solves. Good code should have both.

2. If you are unsure if a variable or method name fits your needs, send it to a chat and ask people what they expect from it.

3. Strings. There are no checks for strings. Therefore, if there is code like if (order.status == 'delivering') {...}, and you decide to rename a status label, you should manually find all the places, where you've written such checks and fix them.

What is a solution? Keep such checks in one place.

There are two possible ways to do it:
1) Method: order.isDelivering()
2) Enum: order.status == OrderStatus.delivering

4. Don't save on variables. Oneliners aren't cool if they prevent you from understanding the logic.

A popular example from C language: while (*dest++ = *src++);

5. One vs Many in variable naming.

If I see a variable named attributes, then I expect it to store some collection, not an individual object.

6. Semantics. Make your code meaningful.

Example: if (!items.children) {...}
Do you have any clue of what did we just checked? Me neither.

7. Null object pattern

In some cases instead of writing checks like
if (user != null && user.isAdmin()) {
user.doSomething();
}*,
you can use Null Object Pattern.

"We should use the Null Object Pattern when a Client would otherwise check for null just to skip execution or perform a default action. In such cases, we may encapsulate the neutral logic within a null object and return that to the client instead of the null value. This way client's code no longer needs to be aware if a given instance is null or not."

For the example above it could be
final user = cond ? AdminUser() : Guest(),
where Guest is a null object.

8. Command-Query separation

"It states that every method should either be a command that performs an action, or a query that returns data to the caller, but not both. In other words, asking a question should not change the answer."

Example: user.isValid() - predicate that returns boolean. We don't expect it to change anything. If it somehow modifies our state under the hood, it'll be almost impossible to find the bug when we face some weird behavior.

*This example doesn't apply to languages with null safety like Dart and Kotlin

#dev