Архив недели @krossovochkin
Понедельник
Hi, I'm Vasya and I'm an Android Developer.
Working with Android since 1.6 and HTC Dream. Jumped into IT directly at Android w/o other experience.
Worked in outsource and products; apps and libraries; games and "enterprises".
Writing weird articles on Android.
Week plan:
M: Education and learning
T: Time
W: General solutions
T: "Great Job" vs Criticism
F: Android
S: Languages
S: Various topics on Justice, Magic, Toxicity, Seniors, …
As I'm working, the format of posts will be the following:
- in the morning I'll write some thoughts on the topic
- in the afternoon comment on something, if anything
- in the evening provide some additional notes and conclusion
I'll write tweets in English. The exact reasons probably will describe later in the week.
For anyone who would like to comment on something and not that comfortable w/ English – you can comment in Russian and I'll answer in Russian too.
🏄♂️
Education is important.
One should constantly learn.
The main thing to learn is how to learn.
The second main thing to learn is how to learn efficiently.
By Education I mean school, university etc.
It happens so that in our post-soviet countries university might be considered as a waste of time.
A lot of people I know don't work at their university specialities, me included.
My speciality is Mechanics/Robotics, though I haven't worked or even touched that area since university.
Instead straight jumped into programming and Android.
There are cool QA guys, who studied in the linguistic university.
Some developers, who were working outside of IT for a long time.
And with all the courses in the internet and considering that it seems so easy to work at IT without any university diploma – why bother?
Putting aside question about quality of the university education in our countries, I think that statements like "you don't have to study at university to work in IT" while being true, can make more harm than good
Some people just think that they'll get some silver bullet while studying. That the fact of studying already should make them ready.
Instead, I think university is a way to learn some things, get in touch with smart people.
Everything else as always depends on you
Experience is a second part of the puzzle.
One can't learn the experience. One can develop it only with practice.
From this we can get the directions for self-development: learn new stuff, get experience by practicing it.
University imo is not "designed" to get the experience, so one should be cautious about that.
Instead there is a good deal on getting some base knowledge, on top of which one can build whatever you like.
Experience part of learning is more difficult than knowledge, because getting knowledge is relatively simple: you can read books, articles, talk to other people.
To get experience one should solve some problems with knowledge one had.
Problem might be synthetic (such as some equation to solve, w/o context or real usage) or some real-world.
Problem might be simple and complex.
From simple synthetic problem one get few experience.
From complex real-world problems - a lot.
But one can't start practicing with complex problems. Complexity should be gradually increased.
While doing such a practice one might find out some gaps in their knowledge – effectively learning something.
And this makes some learning cycle: learn -> practice -> learn.
Where each new cycle ideally increases complexity.
What to learn and how to learn?
I don't know. One should find out by themselves.
And this is exactly great.
There are no boundaries. There are no rules.
One can watch and notice what others are doing.
Talk to other people.
Think about personal needs, wishes.
Compile that in the brain and produce own way.
There are probably some general "rules" like "read books" though.
But again, it is not mandatory.
And while I think university is important.
It is again not mandatory. One can decide.
One last thing in this morning chat I'd like to touch is talent.
There are some talented people, who learn pretty fast.
Seems they have solution in their head almost immediately.
How they did it? What if one has no such "talent"?
As with everything else I think that there can be multiple answers:
- that person might have a lot of experience and all these problems look similar, so solution comes from the top of their head
- person is fast thinker - maybe something related to genetics)
- ...
How to become such a "talented" person?
I think if it didn't come naturally, then the only way is to hard work.
For this I have a story.
When I'd been studying in Lyceum (with physics speciality) I was by no means a talented person.
It was truly difficult time because knowledge we should've got there was complex, and problems to solve as well.
The physics teacher gave us a task to solve 5 problems every day.
Any tasks - simple, complex whatever.
Just grab 5 problems and solve them every day.
Each week or two he reviewed all the solutions (I doubt he looked at all the solutions though) and put the mark depending on whether you are on track or not.
One should've solve 5 problems per day including weekends. One could decide whether to solve 5 every day, or have one day of a rest and then solve 10.
I don't know what was the purpose of the teacher for such a task.
But what I've learned is that if you're not "talented" in something and at the same time want to be good at something, then you have to practice.
One should spend some amount of time to learn.
And this is one of the techniques I use till today to learn)
University. Yes or no.
Evening time
Let's continue on the learning topic.
Now I'd like to discuss ways to learn, how to organize that, etc.
Doing so from the (Android) developer perspective.
Currently for anyone there are a lot of opportunities to learn: books, articles, videos, conferences, online/offline courses and so on.
It might be difficult to find out what is needed.
Let's look at them one by one:
Books
The most fundamental source of general knowledge.
As tech changes pretty fast, books on some new topics quickly become outdated. On the other hand there are books which stood the test of time, such as GOF patterns. They are definitely worth reading
Key thing in reading tech literature is that one should not just read text, but instead try to analyze, make notes, do pauses for practice or thinking about questions.
Articles
Every day more and more people write more and more articles. Quality of such articles quite often might be bad.
Many of the articles look more like tutorials.
But there are also pretty well articles e.g. if they provide some in-depth analysis.
It is simpler to write article than to write a book, so articles can appear faster and have more relevant information.
That means that reading articles is very strong "weapon" in your learning arsenal.
With having so many articles out there it might be difficult to understand what to read. Especially bad, if you spend time on "bad" articles, which don't provide you value.
For this I'd recommend to find some publications (like proandroiddev.com), some aggregators (like androidweekly.com) or build your own rss feed.
Good thing about aggregators is that they can help you to find blogs of some good developers/writers on the topic that you're interested in.
This way you can add links of these blogs to your rss-feed and get updates faster (without 3rd-party aggregators)
So, we're good with getting updates on new articles, but which to read? There will be quite many of them.
General rule: read what you're interested in.
Don't try to read all of them, if you are not sure.
You can save links to articles in e.g. getpocket.com
But saving to read later doesn't work for everyone. If you don't clean up inbox for a while, then there will be just dozens of articles which you'll never read.
I use the following approach: when looking through the rss-feed I do mental-pre-filtering. Guessing whether I'd like to read some article based on name and short description.
If yes, then save it to pocket.
(Almost) every day I check pocket and try to spend some time (around 15-30 mins) to read some articles.
Once a month I do a triage of articles and delete some which are not relevant.
This time to decide I can open article and quickly go through
There are always exceptions. Recently I finally got time to read very long article while commuting. It took me around 1.5h to read. So, some articles require time to be scheduled.
Online courses are really different.
There are pretty complex ones on Coursera, there are a bunch of "tutorial-like" courses on Udemy.
Coursera-like courses are pretty similar to some extent to university courses, but probably not that deep in the general syllabis topics.
Udemy courses I'd recommend only if one wants to quickly go through some technology with virtual guide.
Otherwise it might be better idea to go through official docs by yourself.
Generally, on Udemy you don't look for knowledge, but some initial experience in some area
Another option for Udemy courses is to get free certificate.
But it anyway doesn't matter much.
In general doing something for achievement and not to get some value for yourself, I believe is a bad approach.
Conferences
Currently offline conferences are postponed because of covid, but there are a lot of online events.
In general one should consider going to offline conference not to listen to some talk, but instead to chat with other people
If one wants to see the actual talks - it is likely that it will be recorded. And I personally prefer watching conferences talks recordings, as in such a case I have an option to watch it in 1.5x saving some time.
@mobileunderhood Yes, knowing patterns helps you solve complex problems a lot. For me, they showed how small, neat code can easily solve complex problems.
Exactly
Another important note about books is that it is worth to re-read them from time to time. First time I read GOF I felt like it was great, the second time I found that I got much more than when reading it first. Still looking forward to check it once again in the future twitter.com/mexikane_c/sta…
Survived temporal account deactivation.
😓
What sources to use to learn also depends on how you better understand the world.
Some people better stick to visuals (diagrams, videos), some to audio (podcasts), and so on.
For me the best way to learn something is to write about that. That is why I'm from time to time write some articles. By writing them I learn.
One of the best ways to learn is to explain something to another person.
Writing has additional advantage to me, because of activating my muscle memory – when some knowledge seems to stick in memory by itself while you write.
So, depending on what works for you best, you can adjust the way you learn something.
Of course, if we got back to the University, then the common task there is to make your own workbook with all needed notes handwritten.
This approach is good for me (see above), but I think in general there is no need to re-write books, when you can just open them and read
Practice and experience are important as well, but are something that more difficult to get.
It is always better to solve some real-world problems to get relevant experience.
One good way is to have your own pet projects.
Pet projects, being real products to some extent, give you a way to solve some real problems.
Also, they are good for you to test some new frameworks, approaches and so on.
One of the most difficulties with pet projects I found is that it is difficult to maintain them.
When you build something from scratch - it is awesome. Then when all the interesting part is done - it becomes boring.
I had few pet projects on Github back to 2015, which were even not finished. Of course because of lack of maintenance they just died.
I found one good way to work with pet projects: you should care on what you do.
The simplest way is to build something that solves your problem.
Not necessarily huge problem - it might be something small (like weather forecast)
You'll have some small project, which you care about, because it solves your problem.
You, as a stakeholder, can develop that product if you wish.
And as you care you would like to maintain it properly.
It is always easier to invest into something which brings you the value
Second thing about pet projects: you don't have to make them perfect. If you try to polish it you might get bored and instead of solving your problem - you'll spend a lot of time of debugging something which is not very important.
Hopefully, we'll talk more on this another day
Finally, we have a lot of approaches to learn, different goals, various areas - how to combine all of this into some working plan or strategy:
One of the good things in education is that someone already worked on a learning plan for you.
Developing your own plan is difficult and important work.
First of all one need to find out the goal - what you'd like to achieve. These goals can be not very specific initially.
They you start breaking your goal into smaller pieces trying to add more specifics.
Then prioritize somehow.
And you have a plan!
If someone is interested, some time ago I've written article about my way to organize things to learn: hackernoon.com/how-to-structu…
Of course, it might not work for you, but maybe will work as an inspiration.
One of the things why I wanted to have such a plan is time, and I hope we'll discuss that tomorrow.
I have few topics I feel not very comfortable about, which I try to plan for the next 3-6 months.
I try to review the plan around every month and make needed adjustments.
Always be flexible. Any plan is subject to change. You don't have to follow it strictly.
For example, in the beginning of the year I wanted to dive deeper into Dagger 2 stuff.
Since that time there were so many "dive deep" articles written, so I've abandoned that goal feeling that I have enough knowledge for now.
Reading articles, watching videos and attending conferences won't make you a better developer by itself.
But I believe without striving to learn something new, get into details of something - it is very difficult to be good.
How you prefer to learn something:
Вторник
Today I'd like to talk a bit about time.
Time is a funny thing: one can't control it, but it is possible to manage it.
Time is a resource which everyone has (unlike money). So it becomes primary "tool", which can help us do something.
Depending on the context by referring time one might mean different things. For example, some exact moment or duration. Today I'll mostly talk in the context of "resource" and time management.
When talking about time management "work-life balance" and "spending time efficiently" comes to mind first. So, let's try to talk about these.
Work-life.
First it is needed to define what we'll mean by that.
In my "definition" by "work" I mean all time that is spent on a job and on any activity related to job or your speciality.
For example, I am a developer. I have 40h work week. After work I can read articles, check some frameworks etc. This all counts as "work".
If I learn or do something unrelated to job (say playing basketball) - I call it life.
With a job it might be simple if you have 40h work week, everything is done in time, you don't have to overtime.
Or if you are not working on a product (where you'll work as much as needed).
You don't need to think how much time to spend.
How much time do you work per week usually?
Second part of puzzle is family. It is also very important and great to spend time with your family.
So, it is needed to find some balance between time you spend on some work-related stuff and family.
There are many ways on how to approach that and as with education one should listen to yourself and find out what works better for you.
One might work in some startup almost 100% of time, with support from family that it is done for overall good.
One might work exactly 40h at job and spend all other time on community, posts, conferences. Again in some sense sacrificing family.
One might work exactly 40h at job and spend all the remaining time on family. Loosing opportunities to learn something outside of job (and maybe becoming better in professional plan)
This leads us to the same question on personal preferences and goals.
Yesterday, I was talking about education, learning and particularly about "learning plan" - some list of things you'd like to improve
If you are fine with fixed-hours job and spending all the rest time with family - then you of course don't need any learning plan.
If you spend all your time on work/learn - then most likely you also don't need very detailed plan - you can learn as you go
But if you would like to have some kind of a balance, then plan might become handy, because it might allow you to spend time more efficiently (but we'll talk about that later)
Will leave part about "efficiency" for the evening.
Now would like to talk a bit about "speed of time"
I don't know whether it is just me.
And if not just me then whether there is some official term for such.
But my personal feeling that every year time goes faster and faster.
Looking back it felt like there was quite a lot of time, it was going pretty slow.
Now it goes week after week and sometimes I think it would be awesome if it would be possible to slow it down a bit
Maybe this feeling is indication that I do quite a lot of things (maybe also trying to do as much as I can), maybe over years one has just less free time.
Or maybe there is some well-known paradox related to how brain works - I don't know.
But with all that feeling that time runs very fast, question about spending that time efficiently becomes to me very important
Spending time efficiently means get max value in min time
One extreme side of that is spending time on something that doesn't bring you any value - wasting time.
As topic again too broad and can depend on various context, will look only at spending time efficiently on some work-related learning stuff.
And will not look at some activity like playing video games. Some might consider that as a waste of time.
Typical waste of time while learning is investing time into something useless. When you wanted to learn something new, spent some time and instead got nothing in return.
It might be that you've watched a video or course and everything in there was already known. Or read article which was some simple tutorial or re-compilation of something you've already read.
In such situations I think it is important as soon as you feel that you don't get what you expected is to stop and switch to something else.
As soon as you've found that time is likely wasting - you don't have to proceed.
Though it is easier to evaluate value in process of doing something, it might become important to estimate value upfront.
For example before reading something you can decide whether that reading makes sense to you.
Filtering out some content upfront can save you a lot of time.
So, we have now a bunch of things you'd like to do. But which one to start first? Here it might be handy to prioritize.
I like the idea of ICE score, where you calculate Impact - value, Confidence, Ease (in our case can be considered as time) and prioritize based on that
In this particular example of prioritizing your own tasks doesn't require to check confidence. As it would be same for all tasks.
They you put values from 0 to 10 for Impact and Ease of each, then multiply and choose the top one.
I like this approach because it is very simple and allows one to think in more "rational" way.
How it all relates to programming? I think a lot. Because estimating and prioritizing is very important and is something one will do on a daily basis.
Finally, we have some prioritized list of things to do. The only question left is "when" you'll do that.
If you have a lot of spare time, then you already know what to do. In case someone has very limited time it might be good to define some "windows" or "time slots" where you can work on your plan
Important thing about time slots is that most likely that both short and large slots will be needed.
For some day-to-day activity like reading newspapers one can reserve 15-30 minutes every day.
But half-hour is not enough if you'd like to get in touch with new tech.
Or if you'd like to start new pet project, or attend conference and so on.
For such larger time slots are needed.
This is exactly the way I do spend my time. I have many small intervals on which I read something. And have some dedicated time about 4-8h in the weekend.
Again, it is not strict
For example, when I agreed to participate in mobileunderhood, I've been notified around 2 months before, and was able to adjust myself accordingly.
Trying to formalize all of this is one of the reasons why my posts are structured in time like that
Being in the constant doing something is exhaustive.
Taking a rest is part of work.
So it is important for some time to stop all your work activity and just switch to complete rest.
This might refresh your mind and give you additional boost in the future
Среда
Today we'll talk a bit about general solutions
As usual we'll start with some kind of definition (though this time it will be by examples)
At work we solve a lot of problems. Sometimes we face something new, sometimes we get problem we've already solved somewhere in the past.
Being programmers we tend to solve each problem once.
I think there are two ways of doing so: composition and generalization.
By composition I mean that we build small modules and connect them in various way to solve given problem.
By generalization - that we create some high-level interfaces which can be used in general solution
Both ways support each other.
I would say that first one is like going bottom to top, while second - top to bottom.
In first case you take your existing code, add new, recombine and you get the solution.
In second you refactor your system to be able to solve more general problems
So, depending on the task one might go top at first, then to bottom and so on.
Doing some "mental cycles" until the problem is solved.
Of course, there is another way on how to solve problem: modify existing code. Particularly, add some logic using flags. But this approach tend to increase complexity significantly and shouldn't be your first option.
If we work in constraints (such as time) and the change is relatively small, value is much greater than risks which might happen - then one can take more risky way.
Again, there are no strict rules. Everyone has to decide in particular situation
In general one aims to keep modules small and interfaces clean. But it also not something that should be used as a rule of thumb. Context in which problems are solved might drive your weighted decisions to break some rules. And this is fine as long as you care
Building a system which solves some task in general is difficult. It consumes a lot of time, requires multiple rewrites (when one learned enough to "jump" to next level).
One of the difficulties - is defining the problem.
It is easy to find your specific needs in a product. You can communicate with other people and find out their use cases.
But these use cases are just some specific cases, they don't provide you idea of general solution
First step might be to try to "build" virtually some systems for few most common use-cases.
Next step might be to start analyzing all these use cases and virtually built systems and trying to extract similarities, pushing the level of generalization up.
And then repeat these steps (find more use-cases, test your virtual system against it, make adjustments).
The issue with such approach, that in the future it might happen that there will be one very important use-case, which your system won't support. And to support it one have to rewrite everything.
But at the same time I don't think that there is another "better" way of doing this.
Thinking about general solution upfront is very difficult task and requires good expertise.
How it is all related to programming (and mobile programming)
In my opinion one of the most important qualities of system designed for mobiles is maintainability.
On Mobile usually we don't build app once under clear requirements, instead we constantly add features, test and so on.
With all these constant changes it is important to have your app "modular" (by saying this I don't mean build-system modules). It should have clear interfaces. And each separate problem should be solved once and well.
Example of the feature which all the apps need is navigation.
We have in Android Activities stack, FragmentManager. But suppose we don't have them and would like to build app with Views only.
We'll need some solution for navigation and we really want it to be written once and support all the cases we might need today and in the future.
Making simple backstack implementation is easy, but if we extend it to work with modifying the backstack itself, implementing nested backstacks - it might become a pretty complex.
Considering that we don't know what exactly will be required in the future, we might waste time.
Waste time on something that we don't really need.
Here from my experience I think the best one can do is to think about today + near future. Ask stakeholders on what are the possible next steps in the product and various options. And try to create minimal system which will be easier to adapt to new changes.
And always be ready for changes.
Changes are inevitable. And no matter how much we'll try to prepare for them, always will be some changes which might require a lot of work
While building some general solution there is a caveat of missing small but important details.
This is not necessarily a problem, because most of the time general solution would work fine.
Sometimes it is not possible to raise level of abstraction without loosing some information (effectively declining set of specific problems) or without introducing some limitations
The simplest example I can come up with is sorting.
There are a bunch of various solutions on how to sort a list. When we face such a problem in real life we don't write own routines to do that.
Instead, we take some library implementations ready for general use
In many cases it doesn't matter in which way and how list is sorted. Some simple interface provides us a way to use different versions of algorithms. Some which require more memory, some which require more computation time.
But there might be some algorithms optimized for some specific case, where general solution won't work well.
Therefore understanding what's the use-cases you are aiming at is very important.
Another example, from Android world is Jetpack library. It is set of libraries for general use cases to simplify developer's life.
Started with AppCompat to provide unified interface for features which have differences between OS versions
Now Jetpack has a lot of various solutions trying to provide general solutions for common pain points.
Though some of these libs, being officially recommended, are called "opinionated", because they might not fit into all the possible use cases
Trying to generalize something complex - such as architecture approaches - is very difficult and nearly impossible.
That is why for me Architectural Components look to me like solution for some medium-size projects.
If you build PoC which you can throw-away, then you can live without architecture.
If you would like to have great flexibility, then most likely you can invest into your solution
Your solution built for your specific use case.
If you somewhere in between, then probably yes, you can use general stack.
Working with some common solutions provides good reusability and similarity between projects. Allowing to spend less time to onboard new people.
At the same time there seems always way to improve, because over time people gain more knowledge on the problems which allows to provide better solutions.
It works for something like programming languages as well.
First one worked with assembly code basically writing low-level instructions. Then more general (business-centered) solutions started to wrap old solutions and provide more user-friendly API
C++ simplifying work, Java simplifying working with memory etc.
Kotlin which tries to solve issues in Java by providing even more general APIs for common use-cases
All the time it is needed to look for better solutions, more general ones.
At the same time needed to keep in mind what use-cases you try to cover and what additional limitations you will introduce.
And consider your resources (such as time) to decide what solution would be sufficient in your situation.
Last three days I've talked about three different topics.
Education/learning, time and general solutions.
The main idea was to try to show how these topics really relate to each other. And they might influence each other as well.
And as well it is important in the context of programming, though again it might not be necessarily clear from the beginning.
You spend time to learn something to make a better solution.
You make a better solution to save time to learn more.
And then you repeat the cycle
The more time you spend on right things - the less time you'll spend in the future.
If you waste time on wrong things - then you'd likely spend even more time in the future
You invest more time to make better solution and learn from it.
Or you try to spend less time to work iteratively, so you have enough time for multiple iterations
Четверг
Today's topic is about feedback. Particularly giving feedback.
Feedback is essential part of moving forward.
Without it it is unclear whether we're going into the right direction, and if not - what is needed to be changed.
Criticism is the most important way to drive some changes.
Though while giving feedback on something people tend to be emotional, which can be a problem.
Code review - is where developers get most of the feedback on the work they've done, so will refer to it in some thoughts.
When someone makes a code review it might be tempting to write about all the issues (big and small) that you could find. Nitpicking is a common name of such activity.
Giving such a feedback might lead to drop in motivation (especially if author was looking for architecture suggestions).
So excessive negative feedback I'd consider as bringing more harm than good.
On the opposite, always say that someone did "Great Job" whatever it was – something small or whatever – I'd consider harmful as well, as lack of criticism leads to stagnation.
Why try to do your best if anyway the result will be a "Great Job"?
As in everything else one should try to find golden mean. And that means for me to give constructive feedback where necessary, and praise for the work which was really done well.
Constructive feedback - is a feedback which can improve something in meaningful way.
Whether pointing at code review to all the places with bad formatting is a good feedback?
I think no.
Can your feedback change something - yes, author will go through each change and fix.
Did you solve original issue in a meaningful way?
No
Next review you'll probably still write a bunch of comments about formatting. And you'll be distracted from other issues.
For such cases it is better to integrate some static analysis tool, which will scan code for all the violations.
Though integrating such a tool still will give the same feedback to author (that formatting is broken), it has two advantages: 1) it is automated, 2) seems people take criticism better if it is provided by machine rather than by other people
Probably the reason behind that is that machine doesn't actually "think". It doesn't judge.
When some other person says that what you've done is wrong - you might think that person in general doesn't like you because of that (when 99% of time it is not the case)
The feedback you provide is not necessarily correct - and it is something worth remembering.
Feedback is not one-sided. Feedback on feedback is also a good thing as it starts discussions. And from discussions as a result some even better solution can be found.
As people are not 100% right on everything, it is advised to use more polite wording while giving a feedback.
By pointing at something you feel wrong or by raising questions, your first motivation is to understand the problem better.
Even if you see something wrong it is better to first ask whether it was done intentionally - probably there is some reason on why it was done in such a way.
If you state that something is incorrect and has to be changed, and then it turned out that there is a reason to do so and there is no other better way - then you just unnecessary heated up the situation and this would not make you work with your colleague better
My suggestions on giving feedback (whether it is a code review, 1-to-1 or providing some "360") is first think what bothers you, then try to think why it happens so, then how it could be solved. And then evaluate whether the solution seems viable.
Giving feedback - even if you feel that something is bad - should not become ranting.
If you just constantly dissatisfied with everything - it will be difficult to work with you. As other people will feel your dissatisfaction and it will affect their attitude and motivation.
Being a good guy for everyone and not expressing criticism is bad as well. You might be the greatest guy to work with after all, but whether you'll be able to get to success if you miss an important tool of moving forward - constructive criticism?
Discuss issues, try to find the root cause, try to understand the value which one can get.
Provide good feedback.
Feel free to provide feedback if you have any
Пятница
Android is my main speciality.
First I've heard and touched it in 2011. Right before starting to "develop" apps for Android.
Funny thing that at that time I didn't know even about iPhone. The whole idea about smartphones was somewhere in parallel universe.
In theory I could've been an iOS developer instead, but I didn't have Mac, and didn't have money to buy one.
Android was a cheapest option, and here I am.
I could've been a Web developer, but I don't understand all the HTML/CSS/JS world. It feels simple to write everything, but also there are so many small details, which makes me crazy.
For example, complexity of centering something is insane.
I could've been a Backend developer (Java), but when I wanted to go to EPAM's free courses, I was rejected because of (as they said) bad English.
Though some knowledge in Java allowed me to jump into Android.
If you are an Android Developer, how you've chosen that path?
Not just Android but whole smartphone world felt like something very powerful.
You have a handheld, which can do almost everything that desktop can. And even more. With sensors (as GPS) it becomes even more powerful.
Games have more potential, because of touch-screen mechanics. Browsing internet on the go.
This all was cool.
Building an app which works and you immediately see that - was cool as well.
Over time Android becomes more and more mature. And now it is pretty stable and competitive OS.
To be honest I guess it is a bit of luck for me, because also I could write some apps for Windows Phone, which is already dead now.
I like Android and hate it.
There are a lot of things to hate, especially being a developer.
From user's perspective I hate how many vendor-specific phones are on the market. It is so difficult to find one with vanilla Android.
Pixels are good, but they are too expensive. I don't want to spend that much on the phone. I even can live with some lags. I need just phone which will solve my day-to-day tasks, and not which will have a powerful camera etc.
All my Android phones I had had vanilla Android (or very small customizations). Philips w732, Nexus 5, Nokia 6.
Nexus 5 of course was the best.
If it had OS updates till now, it still would be my current option. But it stopped at Android 6 and I don't want to sue custom ROMs
From developer perspective, of course, one of the worst things in Android is UI framework.
Hopefully, something will be changed when Jetpack Compose will be in production.
Though even after that I don't know how much time it would be needed for migration.
For a long time I didn't think that UI framework is bad. At some moment, while doing yet another task related to UI (customize theme making it dynamic, handle complex state control in some dependent checkbox-item list) I found how much time I spend on something weird
If I need to customize component then it might go through 1) theme/style 2) public API 3) custom colors 4) custom drawables 5) reflection 6) disappointment
As not everything is even possible to do.
And the main thing which bothers me: it is possible to do a good API.
But even in MaterialComponents lib it has the same issues (bad API to customize component, just look at Text Input if you wish).
So, the problem is most likely not with lib itself, but with people who write it. That even doing rewrite API still looks similar not solving issues.
Of course, if we talk about dynamic theming, then there is a limitation in Android Framework - as all the styles/themes solution is static and defined at compile-time. So, partially, it can't be solved without either introducing something new in parallel.
The second moment, when I found out how bad Android UI framework is when I had to deal with internal state which resides in Android views.
Checkbox is the simplest example. When user clicks on it - it immediately toggles with animation.
That means that immediately you click - view already has updated state, while your business logic has no idea about that.
Sometimes it becomes a problem when your business logic has some state modification, which should be pushed to UI, effectively disabling animations
And the last moment was when I tried Flutter. It felt insanely flexible. Yes, this is exactly what we need. One can customize almost everything in a way one likes.
The biggest issue with Flutter, though, is Dart. There is no pleasure to write in Dart after Kotlin.
Dart Dev Team adds more features to Dart for it to look more like Kotlin (I guess), but _ for private, implicit interfaces and "dynamic" - this everything is just bad.
Default/named/required arguments are just mind blowing.
But I really like Flutter community. How open they with a feedback. Android seems also becomes better with time.
But in Flutter it is like: "We have this new cool thing"
And in Android: "We now [probably] should have less pain with old thing".
But pain is still here
About UI framework and Flutter vs Android: medium.com/flutter/materi…
Here is an article describing Range Slider implementation in Flutter.
Just look at the API, level of customization. Even touch strategy can be customized in a flexible way.
Wasn't such possible in Android as well?
That is why I have huge hopes for Jetpack Compose. As I hope it will solve our old pains in a better customized way.
I am not 100% aligned with having @Composable instead of some "Widget", but probably it is not that important. And if it provides better flexibility, then whatever.
Compose feels very MVIish, but I guess we should be able to use it in old way with any other arcitecture, if we wish.
Separate hope is to use Kotlin MPP with Jetpack Compose/Swift UI to have common logic shared
@mobileunderhood 10 years ago (and now, lol) Objective-C looked and felt ugly.
Couldn't agree more! twitter.com/0leGG/status/1…
@0leGG @mobileunderhood I bet many guys chose Android because of Java, the language they already knew
Fair point. I think it was a good choice to use Java as a language for Android – lowered the entry threshold.
Though slow updating of Java version in OS is a problem now. twitter.com/xCh3Dx/status/…
Few thoughts about Jetpack libraries overall.
It is good that we have some solutions for our common problems.
I find it a bit depressing that it wasn't possible to make something like this earlier.
It is clear that having appCompat libraries and being a big company with a lot of employees it is not that easy to do such migrations.
Migration to AndroidX was very important but tough decision
The main concern about Jetpack libs I have is that they are usually in beta.
And it is even stated that "beta is good enough"
No, it is not.
The most hilarious is MotionLayout library. It is in development for more than 2y for now I guess. Pretty complex library - trying to solve very complex problem in general.
But being in beta it is advised to use it in production already. I don't like such approach.
Still, it is clear to me that without feedback from real projects it is easy to make ConstraintLayout 2.0 stable with immediately starting to implement 3.0 because of some issues.
Though at the same time many libs maintain two separate releases: x.0 in release parallel to x.1-a
Funny thing was when editor for MotionLayout was released before library itself.
One additional thing about "beta is good" is Android Studio. I don't know whether it is just a feeling, but it seems that Canary builds are more stable than actual stable builds.
When release version is published it is advised to wait for week or better two before switch
Or even better to have multiple versions of IDE installed for quick switch.
But beware that in such case you should not raise android gradle plugin version otherwise old version won't be able to work with that project.
Overall I think that Android ecosystem for developers evolves and becomes better.
Of course, there are some issues with stability etc. But we can't do anything with that. Just post issues to bugtracker
I like how much better communication become. We have more and more information for learning: codelabs, enhanced documentation, online videos, news, articles.
All of this is excellent.
Also, I like Android because it is like full-stack development. There is a place for someone who likes front-end and UI. And place for someone who likes back-end with some algorithms, work with sensors, platform etc.
So, it is possible to change what you do at work without changing your speciality. Also, always there is a way to dive deeper into DevOps for mobile, automated tests etc.
Суббота
If someone asked me what is the most important thing that every developer should know, then I'd say that it is English.
English is the best you can invest your time into.
First reason is that there is much more useful for developers content created in English than in other languages.
If you know English then you have much more opportunities in various areas.
Developing local communities is important as well, because in native languages it might be easier to share ideas between people, but it's a bit out of scope of this thread.
Second reason is that English is relatively simple language. You don't need much to start. Especially, if you focus on some technical literature.
Even having something like A2 level I guess is enough to dive into.
Third - is that English is concise. In less words it is possible to pretty well express your intent. And clearly state one's intent is one of the most important things in development.
You can spend less "resources" to share your thoughts than in other languages.
One of the reasons we like Kotlin is that it is concise. Java currently feels to verbose for common tasks.
That same imo happens to English vs Russian as well.
The last I can come up with is that many terms, which originally were added in English, are difficult to translate to other languages.
Here we go with BroadcastReceiver in English, which is translated sometimes like "Широковещательный приемник".
Not only this is longer, but adds pressure for communication.
Considering all these, that are the reasons why, in particular, I write to my personal Twitter in English.
Having limit in characters makes point about "conciseness" more important. As if you can express more thoughts shorter in some language - it should be default.
I've understood that this shared Twitter account probably aimed at local Russian speaking community.
But that is not stated anywhere.
So, I've decided to keep my habit of posting to Twitter my thought in English.
Basically, doing it at my own risk.
If that was not what you've expected, then I can say that shit happens.
Still I think that it is easier to me to post in a way like that.
And can just hope that it can be useful or interesting to someone.
Learning languages is difficult.
First one should have some initial knowledge (at least vocabulary and some grammar) to be able to go forward.
I found that the best way to learn languages is to use them.
As with any kind of learning there should be practice, remember?
And the best practice - is real-world usage.
But one can't go right into listening podcasts or watching movies. There should be some learning, synthetic practice by examples and so on.
Here I try to refer to day 1, which was about learning.
Trying to generalize the way one could learn makes it possible to try to apply these general solutions to some particular situations and see whether they fit as intended or not.
I've been learning English for idk how many years. 9 years at school, 2 at lyceum, 2-3 at university, some low-skill courses at work, yearly course at work.
That's a lot.
But I think real improvement came when I started to use it.
For me for a long time it was difficult to find real usage. It felt complex, but I managed to find my "formula".
With language we have:
- Vocabulary
- Grammar
- Reading
- Speaking
- Listening
- Writing
First one should get initial basis in all of these in some courses, I believe.
Probably it is possible to do everything by yourself or with a help of some books. Totally legible, but it is up to everyone to decide.
Later I guess Vocabulary and Grammar will be learnt by examples implicitly, while for everything else it is better to find some real usage.
Reading is simple: articles, documentation, books. Take what you like. Of course, some technical books require in general less advanced vocabulary, so probably makes sense to start from them.
Listening as well: podcasts, youtube, movies.
Though it is not that easy to start. The recipe is to start with what you like and choose something where there are a lot of talks.
I personally don't like TED as it is boring to me, though it is fine overall.
I've switched to learn Chess in English, watching some live streams of championships with some analysis. They speak pretty well and sometimes it is possible to turn on captions.
Streams in various areas I found one of the easiest ways to train listening skill.
With writing there are two parts: what to write and how to write. Writing in English at PC requires you to type faster on a keyboard.
Here is just a practice needed.
Start your own blog (it might be even private) and start writing every day a bit.
It will pay off soon.
Speaking is the most complicated task.
The best I could find is to talk to myself. Just when you walk the dog, or go to work - try to say what happened yesterday, what will be today. Express your feelings. Provide analysis.
Maybe some online-chats could work for you better.
I'm just a bit introvert-ish, so I was happy to find a way to train speaking without bothering others.
Last but not least.
The simple trick which boosted my English language skill a lot.
Change language at your desktop and mobile UI to English.
That is really simple, though very effective, trust me.
Did that back in 2013 after I saw that at one's of my friends laptop.
Then I've also changed all the interfaces wherever I could to English.
And I think that was one of the best ways to make me use English.
I use PC/internet idk maybe 10+h per day. And if all that time I face English - then over time it becomes irrelevant. I just use it without thinking on how something is translated.
I just get used to it.
And it is the last advice: one should not try to remember words. Even more: one should not try to remember translations
Learning 1 to 1 connections between words in different languages is not the good way to learn it
Try to find general idea behind language. Try to understand it
Then try to make your brain switch to think in different language.
Then it would be a success
And don't forget that it is a long journey. It is not something that is really simple.
It depends also on a "talent". Some people get learning languages pretty easy, while others not.
If you're not lucky - everything is still possible, one should just work on that.
In the meantime I try to learn German.
I don't have much time, so trying to spend small amount of time every day.
Currently try to learn basic vocabulary and grammar.
Use for that Duolingo.
Few days ago it was somecute milestone
WIth the pace I have right now I guess I'll be able to try to move to "next level" somewhere in a year.
So this is somewhat a big investment.
I don't even know whether it will pay off, will see.
One note is that learning Germain in English is simpler than Germain in Russian.
Not just because of similarities.
But because services like Duolingo, which are community driven - have English community larger, so the content is better as well.
That means that by learning English I've not just got the opportunities which English can give, but also opportunities to (probably) easier learn other (similar) languages
Воскресенье
Today we'll have a few of smaller threads on various topics.
And I'd like to start with Magic.
For me it seems that over time I see word "magic" more and more.
Library is doing some magic, code is doing magic, framework magically doing something.
There is no magic in programming.
Libraries, frameworks, some code blocks abstract out some details and hide the complexity.
There is no magic involved.
Some tool makes some specific optimizations. It doesn't do any magic things.
When I hear "magic" on some conference, see it in articles I feel like someone is trying to fool me.
And I don't like to be in such a position.
So, say NO to word "magic" in programming. And tell others.
#nomagic
Justice.
There is no justice.
In life, at work, anywhere.
If you do something important (as you think) and you feel that someone should notice that and you'll get something good for that - then you're wrong.
Always share your thoughts with other people. Don't think that they do everything for you.
And don't refer to justice.
"I'm working better than someone, it is unfair she got a pay raise and I don't".
If you feel that something is unfair - go and talk what you think. Don't think that someone has to do something to you.
That is sad, but true.
I myself has pretty heightened sense of justice. And should say that it doesn't help at all.
At least you will be depressed.
Toxic developers.
I think that all developers are toxic.
The percentage of toxicity is just different.
Some have about 80%, some just 10%.
The definition of "toxic developer" is itself pretty complicated.
In general I think toxic developer is one with who it is difficult to work because of soft skills.
It is not someone who is bad developer.
And the reasons why one developer might not like to work with another are endless.
One might think that another developer is lazy. Has more salary doing less. Think that another developer can't do work well and so one.
In general, I would say that toxic developer doesn't respect other.
Toxic developer decreases motivation of the team, make the overall processes worse and seems the best candidate to be fired.
Though still I think it is possible to work on that problem and even find some solution. As it is possible to work with anyone, I think.
One of the reasons, because IT community seems have a lot of toxic developers, I think, is that in IT there are a lot of ways to do something well. And even more ways to make something badly.
IT people tend to have different vision and think that only they are right.
Maybe fear of mistakes makes such a bias. This might lead to situation when lack of communication makes people not work together but fight for their solutions instead.
Because if you're right - then you are cool and other people not. And you can't allow anyone to be right.
This is exactly wrong assumptions. Development is a team work. And communication, finding solutions, work around conflicts - is very important for successful solution.
Another idea why there are toxic developers - IT industry is relatively new. And there are a lot of people who came here for money by accident.
And such aggressive way to work is their only chance to defend e.g. their "seniority".
Over time I think situation from that angle hopefully will be better.
In general, how to make community less toxic: as with everything start with yourself. Try to make your toxicity level lower. Try to put yourself into other's position.
Try make weighted decisions. Communicate. Discuss.
Maybe someone worked with a real toxic developer and could solve the issue somehow. Would be interesting to hear.
Seniors.
The definition of a senior is even more difficult than for toxic developer.
In my opinion I was working with just a few real senior developers (though many of them were officially seniors).
Sometimes it were people who imo were not that strong as me (ha-ha). But it is highly subjective.
Did I envy that these people were seniors with higher salary while I'm not?
No, because it wouldn't help.
The question was "why I am not senior yet"
And the answer was "because I think that what I know is not enough". I don't dig deeper, I don't have enough experience, I have gaps here and there.
There are a lot of things to improve.
And my quality bar for being a Senior is very high, I guess.
One day my colleagues realized that I'm the only mid developer in a team and said: wtf, how you with your experience and knowledge cannot be a senior developer. Look at us, compare.
Then while conducting interviews, when there were a lot of seniors I was pretty sad.
Because a lot of them were not seniors by my definition.
There is no justice.
So I've become part of the system and officially I am a "senior" developer. Though still I am working hard to become a true senior.
The issue with "senior" in IT is widespread. I think the reason is that because of some toxicity "middle" means "bad", when actually it is not.
Some companies even don't need to have all the developers of senior level. Some companies even don't need seniors.
But working in a company with no seniors is bad. Because how would you grow yourself. Partially that is a fair question, as working with strong people can help you to get more relevant experience.
But not everyone has to become a senior.
Not all builders should become architects.
(analogy is a bit weird as I guess builders can't become architects in the first place, but I hope you've got the idea).
There is nothing wrong to be a middle developer.
The meaning of the word "senior" has depreciated. Now if I wanted to recruit a senior developer I probably should've looked for an "upper-senior" to manage expectations.
Probably, somewhere in the future we'll have some level between senior and lead, so the issue will be resolved.
Until then I'd not think about levels a lot.
If you care about money - then talk about that.
If you care about your growth - make a plan and work on that.
But anyway try not to compare yourself with other people (especially in a form like "I'm doing better or more than ...").
Because you might not know everything about other people. And anyway you'd better to say what you do well, what are your strengths, plans, etc.
What you do already, what gains you bring. Whether expectations are correct. Where there is a room to improve.
Communicate.
And probably the last.
We as a developers tend to be introverts. We work at laptop, write code, talking to machine.
But don't forget about communication.
You work in a team, you work with people.
Talk, discuss, communicate.
It feels to me that so many issues happen because people don't talk to each other. Don't talk about important things.
Don't say what their concerns are. Afraid of saying what they want because they not sure about consequences.
Don't fear, communicate.
Be polite.
Try to understand others opinions.
Try to find compromises.
Work as a team.
That's it for this week.
It was @krossovochkin here.
Hopefully, it was useful or interesting to someone.
I'm still here till the end of the day, if there will be some notes, so feel free to reach.
Please vote for feedback and share in comments anything you'd like to suggest, probably.
