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
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
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
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
The Economist
Parkinson’s Law
The report of the Royal Commission on the Civil Service was published on Thursday afternoon. Time has not permitted any comment in this week’s issue of The Economist on the contents of the Report. But the startling discovery enunciated by a correspondent…
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
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
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
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
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
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
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
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
What is a solution? Keep such checks in one place.
There are two possible ways to do it:
1) Method:
2) Enum:
4. Don't save on variables. Oneliners aren't cool if they prevent you from understanding the logic.
A popular example from C language:
5. One vs Many in variable naming.
If I see a variable named
6. Semantics. Make your code meaningful.
Example:
7. Null object pattern
In some cases instead of writing checks like
"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
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:
*This example doesn't apply to languages with null safety like Dart and Kotlin
#dev
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.delivering4. 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
YouTube
Мокевнин Кирилл, Хекслет - Ментальное программирование 3
Enjoy the videos and music you love, upload original content, and share it all with friends, family, and the world on YouTube.
Size matters
I've recently read about interesting studies from Microsoft. According to them, if you are looking for a technological solution to boost your productivity, almost the only effective way is to buy a large monitor or even two of them.
I found it intriguing because I'm still working on my 13-inch laptop and have recently started to think it's not enough anymore.
Another study from the University of Utah has shown that people using 24-inch monitors complete a series of tasks faster than people with 18-inch monitors by around 52% working with text documents and 26% with spreadsheets. They've also found that taking something more than 24-inch doesn't actually improve users' performance anymore.
Of course, users from experimental group may not have known hotkeys for switching between windows or their tasks can't be compared to programming. So, one may say it doesn't work this way.
But I see some obvious reasons for such results and how bigger monitor can increase my productivity as a programmer.
A bigger screen:
1. Decreases switches between windows.
I usually have 3-4 windows opened at once while working: code editor, phone simulator or browser, UI design, and StackOverflow. For now, I have 3 macOS desktops with needed apps in full-screen mode. Switching from one to another takes time and mental energy.
2. Allows seeing more information at once.
"When people have to remember more, they tend to focus on fewer possibilities and fewer possible solutions. In other words, when people can only see a limited amount of their data, they have to remember the rest, which tends to limit them to fewer solutions and fewer strategies." You can focus on solving the problem instead of remembering some parts of your program.
3. Takes more space in my vision field, which results in better concentration, because I become less distracted. (Personal point)
I've also read from some authoriative sources, that 24-inch is not the limit. The perfect size and configuration depends on type of tasks you have to complete and your working style. So, choose your own path to happiness.
What's your current setup? Are you happy with it?
#efficiency
I've recently read about interesting studies from Microsoft. According to them, if you are looking for a technological solution to boost your productivity, almost the only effective way is to buy a large monitor or even two of them.
I found it intriguing because I'm still working on my 13-inch laptop and have recently started to think it's not enough anymore.
Another study from the University of Utah has shown that people using 24-inch monitors complete a series of tasks faster than people with 18-inch monitors by around 52% working with text documents and 26% with spreadsheets. They've also found that taking something more than 24-inch doesn't actually improve users' performance anymore.
Of course, users from experimental group may not have known hotkeys for switching between windows or their tasks can't be compared to programming. So, one may say it doesn't work this way.
But I see some obvious reasons for such results and how bigger monitor can increase my productivity as a programmer.
A bigger screen:
1. Decreases switches between windows.
I usually have 3-4 windows opened at once while working: code editor, phone simulator or browser, UI design, and StackOverflow. For now, I have 3 macOS desktops with needed apps in full-screen mode. Switching from one to another takes time and mental energy.
2. Allows seeing more information at once.
"When people have to remember more, they tend to focus on fewer possibilities and fewer possible solutions. In other words, when people can only see a limited amount of their data, they have to remember the rest, which tends to limit them to fewer solutions and fewer strategies." You can focus on solving the problem instead of remembering some parts of your program.
3. Takes more space in my vision field, which results in better concentration, because I become less distracted. (Personal point)
I've also read from some authoriative sources, that 24-inch is not the limit. The perfect size and configuration depends on type of tasks you have to complete and your working style. So, choose your own path to happiness.
What's your current setup? Are you happy with it?
#efficiency
Caching strategies
Why do we need caching? It's simple. People don't like loaders*. Moreover, people don't like waiting. So, caching some data to instantly show it next time a user asks for it without requesting the server increases app's UX. Which increases user retention. Which increases app's profit.
I have once stumbled upon a problem related to caching and cache invalidation in a mobile app. My main problem was that I'd never done it before and tried to reinvent the wheel. Luckily, my caching strategy was not so tricky. The cache had an expiration date, so I could invalidate it after a day/week/month, and the app could force an update from the server if needed by the "pull to refresh" thing.
After a while, I've found a talk from a mobile conference about different caching strategies. I'll shortly describe all of them, so you don't need to waste 30 minutes of your precious time watching the video. If you're interested in the theme or feel that something is still unclear after reading the post, then go to YouTube and watch the video (it is not boring at all, I promise).
Thanks to the guy who has even drawn block schemes for every strategy. I'll attach them in the comments.
Okay, let's start.
1. Lazy cache
The most basic one. If user request's some data, we try to find it in cache. If it is there, give it to user. If not - make a request to the server and update the cache with data from successfull response.
Pros:
- easy to implement
- instant data delivery
- cached data is independent of internet connection
Cons:
- no cache invalidation
When to use it:
- apps with immutable data that you should upload once a while like book readers, offline apps, etc.
2. Synchronized cache
The same thing as a previous one, but there are two new steps for invalidation. Local (by expiration date for ex.) and server (by status code 304 NOT MODIFIED for ex.) invalidation. If cache is valid we return data to the user.
Pros:
- faster delivery time for up to date data
- invalidation
Cons:
- dependent of connection
When to use:
- apps with not idempotent data*** where user can't add or edit this data. For example: news and booking apps
3. Write-through cache
The most difficult one to implement. However, the reading process is the same as in synchronized cache. But when we apply some changes, we need to synchronize them with our server database.
Pros:
- faster delivery time for up to date data
- invalidation
- full synchronization with server
Cons:
- dependent of connection
- after failed write we should go back to the initial state
- complex implementation
When to use:
- messenger is a best example
4. LRU cache
It speaks for itself. Least recently used cache is removed when we are out of cache memory, so we can put new piece of data in the cache. However, the invalidation now is in write process. MRU and other algorithms can be used.
Pros:
- instant data delivery
- cached data is independent of internet connection
- customizable invalidation mechanism
- not inflating the size of cache data
Cons:
- complex implementation
- you should be careful with invalidation. For example, you may remove some cached data, that user will need in a second.
When to use:
- apps with heavy content like instagram
* those annoying spinning things, which indicate that we are waiting for data from the server
** if there is no connection, we can't properly invalidate our cache
*** the data may update if you refresh the page
#dev
Why do we need caching? It's simple. People don't like loaders*. Moreover, people don't like waiting. So, caching some data to instantly show it next time a user asks for it without requesting the server increases app's UX. Which increases user retention. Which increases app's profit.
I have once stumbled upon a problem related to caching and cache invalidation in a mobile app. My main problem was that I'd never done it before and tried to reinvent the wheel. Luckily, my caching strategy was not so tricky. The cache had an expiration date, so I could invalidate it after a day/week/month, and the app could force an update from the server if needed by the "pull to refresh" thing.
After a while, I've found a talk from a mobile conference about different caching strategies. I'll shortly describe all of them, so you don't need to waste 30 minutes of your precious time watching the video. If you're interested in the theme or feel that something is still unclear after reading the post, then go to YouTube and watch the video (it is not boring at all, I promise).
Thanks to the guy who has even drawn block schemes for every strategy. I'll attach them in the comments.
Okay, let's start.
1. Lazy cache
The most basic one. If user request's some data, we try to find it in cache. If it is there, give it to user. If not - make a request to the server and update the cache with data from successfull response.
Pros:
- easy to implement
- instant data delivery
- cached data is independent of internet connection
Cons:
- no cache invalidation
When to use it:
- apps with immutable data that you should upload once a while like book readers, offline apps, etc.
2. Synchronized cache
The same thing as a previous one, but there are two new steps for invalidation. Local (by expiration date for ex.) and server (by status code 304 NOT MODIFIED for ex.) invalidation. If cache is valid we return data to the user.
Pros:
- faster delivery time for up to date data
- invalidation
Cons:
- dependent of connection
When to use:
- apps with not idempotent data*** where user can't add or edit this data. For example: news and booking apps
3. Write-through cache
The most difficult one to implement. However, the reading process is the same as in synchronized cache. But when we apply some changes, we need to synchronize them with our server database.
Pros:
- faster delivery time for up to date data
- invalidation
- full synchronization with server
Cons:
- dependent of connection
- after failed write we should go back to the initial state
- complex implementation
When to use:
- messenger is a best example
4. LRU cache
It speaks for itself. Least recently used cache is removed when we are out of cache memory, so we can put new piece of data in the cache. However, the invalidation now is in write process. MRU and other algorithms can be used.
Pros:
- instant data delivery
- cached data is independent of internet connection
- customizable invalidation mechanism
- not inflating the size of cache data
Cons:
- complex implementation
- you should be careful with invalidation. For example, you may remove some cached data, that user will need in a second.
When to use:
- apps with heavy content like instagram
* those annoying spinning things, which indicate that we are waiting for data from the server
** if there is no connection, we can't properly invalidate our cache
*** the data may update if you refresh the page
#dev
YouTube
Дмитрий Васильев — Как кэшировать информацию в Android-приложении и не стрелять себе в ногу
Подробнее о конференции Mobius: https://jrg.su/ojGU3B
— —
. . .
. Дмитрий расскажет, чем руководствоваться при выборе предпочтительной стратегии кэширования для вашего проекта, и поделится опытом своей команды в реализации по-настоящему быстрого и гибкого…
— —
. . .
. Дмитрий расскажет, чем руководствоваться при выборе предпочтительной стратегии кэширования для вашего проекта, и поделится опытом своей команды в реализации по-настоящему быстрого и гибкого…
English from zero to hero (or from anywhere to hero)
Hi everybody, today I'd like to recommend a YouTube channel for those who want to get better at English regardless of their current level. In case you are C2, don't forget to suggest it to your friends when they ask you how to learn English.
I've heard about it from a programmer's interview who moved to the US, checked it out because I'm still on my long and complicated way to watching movies without subtitles (currently somewhere between B2 and C1). And it appeared to be a godsend.
There are 3.2k videos in total with 1.3m subscribers on the channel for Russian-speaking people. The guy has plenty of playlists of all kinds: Grammar from zero to hero (649 videos), 50 lessons for each level (A0-C1), English by formulas (398 videos), and much more. Here is the same channel, but completely in English. By the way, he also has many other channels, which partly duplicate the content of the main one. I've heard he also owns a mobile app "Engish Galaxy".
I've watched just a couple of vids from a C1 playlist and can say that I've enjoyed the process. If we take into account that all of these videos are high-quality, just imagine the amount of work done by Alexander Bebris.
Not afraid to call him Pavel Victor of the English education world.
However, you shouldn't forget to practice other skills like writing and speaking to improve your English.
If you are already acquainted with this man or his channel(s), I'd like to hear your thoughts about it. If you know any other good resources for learning English, it is a great chance to share them with others.
#english #career
Hi everybody, today I'd like to recommend a YouTube channel for those who want to get better at English regardless of their current level. In case you are C2, don't forget to suggest it to your friends when they ask you how to learn English.
I've heard about it from a programmer's interview who moved to the US, checked it out because I'm still on my long and complicated way to watching movies without subtitles (currently somewhere between B2 and C1). And it appeared to be a godsend.
There are 3.2k videos in total with 1.3m subscribers on the channel for Russian-speaking people. The guy has plenty of playlists of all kinds: Grammar from zero to hero (649 videos), 50 lessons for each level (A0-C1), English by formulas (398 videos), and much more. Here is the same channel, but completely in English. By the way, he also has many other channels, which partly duplicate the content of the main one. I've heard he also owns a mobile app "Engish Galaxy".
I've watched just a couple of vids from a C1 playlist and can say that I've enjoyed the process. If we take into account that all of these videos are high-quality, just imagine the amount of work done by Alexander Bebris.
Not afraid to call him Pavel Victor of the English education world.
However, you shouldn't forget to practice other skills like writing and speaking to improve your English.
If you are already acquainted with this man or his channel(s), I'd like to hear your thoughts about it. If you know any other good resources for learning English, it is a great chance to share them with others.
#english #career
YouTube
English Professionally - phrasal verbs in English, English grammar lessons and English words
We learn English grammar lessons for beginners (full course) and other levels (elementary, pre-intermediate, intermediate and advanced). We study how to learn English speaking easily. You'll also see lessons for English speaking pratice, tenses in English…
👍2
Efficient programmer's notes pinned «Hello, my fellow friends. I'm on detox now. It means that I'm trying to read books instead of scrolling the newsfeed, watching online courses instead of Instagram stories, eating fruits/vegetables/nuts/otherHealthyStuff instead of trashy snacks, walking every…»
Efficient programmer's notes pinned «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…»
The Broken Window Theory or Why Technical Debt is an Evil
Have you ever heard about the broken windows theory?
It states that any visible signs of crime and civil disorder, such as broken windows, vandalism, loitering, public drinking, create an urban environment that promotes even more crime and disorder.
"One broken window, left unrepaired for any substantial length of time, instills in the inhabitants of the building a sense of abandonment—a sense that the powers that be don’t care about the building. So another window gets broken. People start littering. Graffiti appears. Serious structural damage begins. In a relatively short period, the building becomes damaged beyond the owner’s desire to fix it, and the sense of abandonment becomes reality." - Andrew Hunt & David Thomas in "Pragmatic Programmer"
Therefore, we may conclude that policing these relatively small misbehaviors will decrease or prevent an increase of the crime rate in the area.
I hope you've already noticed where I'm going.
If you leave "broken windows" (bad designs, wrong decisions, or poor code) in your codebase, very soon it'll become a "dangerous place to live in". So, don’t leave them unrepaired. Fix them as soon as they are discovered, otherwise, all of a sudden, you'll need to get a dumpster, or move to another neighborhood.
Easier said than done, yeah?
#dev #thoughts
Have you ever heard about the broken windows theory?
It states that any visible signs of crime and civil disorder, such as broken windows, vandalism, loitering, public drinking, create an urban environment that promotes even more crime and disorder.
"One broken window, left unrepaired for any substantial length of time, instills in the inhabitants of the building a sense of abandonment—a sense that the powers that be don’t care about the building. So another window gets broken. People start littering. Graffiti appears. Serious structural damage begins. In a relatively short period, the building becomes damaged beyond the owner’s desire to fix it, and the sense of abandonment becomes reality." - Andrew Hunt & David Thomas in "Pragmatic Programmer"
Therefore, we may conclude that policing these relatively small misbehaviors will decrease or prevent an increase of the crime rate in the area.
I hope you've already noticed where I'm going.
If you leave "broken windows" (bad designs, wrong decisions, or poor code) in your codebase, very soon it'll become a "dangerous place to live in". So, don’t leave them unrepaired. Fix them as soon as they are discovered, otherwise, all of a sudden, you'll need to get a dumpster, or move to another neighborhood.
Easier said than done, yeah?
#dev #thoughts
👍5