Mobile or Web (or both)?

Many beginning developers are questioning themselves about the area of the software development they want to build their career in and I was one of them (I'm still beginning, but I did choose already).

Today there are several major areas you can focus on.

1. Operation Systems (Windows, Android, iOS etc.) - here you would write pretty low-level code that would handle interaction with the hardware.
2. Game Developing - could be broken down into many subcategories, such as game engines, UI in games, gameplay etc. 
3. Mobile - building apps for mobile devices running Android, iOS, Windows Phone etc. This area is growing really fast nowadays because of new mobile devices. Android is embedded in TVs, cars, VR and IoT (I personally think, that someday Android development would be one of these major areas of software development itself).
4. The Web is growing just as fast as mobile, and the reason for it is online clouds. Almost everything is going to the web, it's convenient, you can access it almost everywhere, and in developed countries, it's fast and cheap. 
5. Data science - this one is about big data analysis, machine learning and sometimes artificial intelligence. Note that it's actual science. You would be learning much theory before doing something actually working, unlike the other categories.
6. Embedded software - this is low-level software that is built for one particular product, for example, for a digital camera. This category got a second breath with the emergence of the Internet of Things.

There are more, but it could take a whole post to list them all. If you think there is a category that definitely should be on this list, please drop a comment I will include it.

Today I want to talk about the two most popular (for now) categories: mobile and web development.

Mobile VS Web

Some people think that there is some kind of competition between these two. And they are right, in some way.

Mobile and web developers always try to make the experience on their platform feel better that on the other. 

Which is better, create a mobile app or just make an ada``ptive design of web version for mobile devices?

What is great about this competition is that it's healthy, it makes both platforms create new ways of interacting with the users, enchant them, simplify their life, and make them amazing.

I even heard the opinion that you should both web and mobile. Which, as I think, is wrong because if you want to build the career it's better to focus on something instead of picking all into sight.

So if you want to be a developer what should you pick? Unfortunately, it's not that straightforward but let's look at advantages and disadvantages of every category and I hope it will help you to decide on your own.

Web Development

Advantages	Disadwantages
Cross-platform. You can run your app on every device that has a web browser.	Runs only with browser so if you want to build offline app using web technologies (e.g. Atom) you need to ship a browser with it
A huge developers community	You can only use JavaScript and it's kinda slow so you limited in optimization.
Fast development cycles (write->build->test->repeat)	You do not have the computer resources control unless you're using some framework for building offline apps

Mobile Development

Advantages	Disadwantages
Over a billion of people have a mobile phone	There are two major platforms and you should choose only one (while it's better to have your app on both)
A huge developers community as well (for Android and iOS).	Slow development cycles.
Full control over resources.	You should care about optimal resources usage.
You can use native low-level processing (for example NDK) to optimize your app

For me, mobile is more convenient. And I don't mean that Web is worse, it should be your choice.

If you want to build something more interactive it's better to learn mobile, if you want your apps to be accessible from anywhere and anything that has a browser it's better to get to Web development.

I hope I helped you to choose the direction to go.

See you in the next one!

The Boy Scout Rule in Coding

The Boy Scout Rule is the simple rule that can solve a huge problem of software development within a team.

It states: "Always leave the campground cleaner than you found it". Sounds pretty simple, right?

But, despite its' simplicity, not every developer follows this rule (me neither sometimes).

Sometimes, it's just kinda hard to take responsibility for someone else's code. I tell myself: "If someone else made that mess, why I should even work with it?".

But undoubtedly, it's way better for everyone to take care of the code you working on with a team. All the same, we are programming in the high-level languages and those were made for people who work with machines, not the machines themselves.

What is clean code?

To keep the code clean you obviously should know what clean code is and what it takes to write one.

Let's formulate some qualities of the clean code.

1. Clean code is focused.

You don't want your methods to consist of various blocks of unrelated code. You want one particular method to do one particular thing.

First of all, it's easier to remember what the method does and if it has a good name (which is a quality of clean code too) then the user of this method don't even need to know what it does behind the scenes, he can use it out of the box.

But you can say, what if my method should do many things behind the scenes? The key to handling this problem is an abstraction. 

For example, take the Glide library which I discussed in one of my posts Image Loading With Glide. To load an image you should handle HTTP connection, media decoding, memory and disk caching etc. But Glide makes it look like one thing, loading an image.

2. Clean code is expressive

I already talked about it when mentioned that method should have a good name.

Good naming can make your code self-documenting and make documentation less important and in some cases even redundant.

Let's think of a simple example.

  int method(int[] array) {
    if (array == null || array.length < 0)
      return 0;

    int integer = array[0];
    for (int number : array)
      if (number < integer)
        integer = number;
    return integer;
  }

It's pretty easy to determine what this code does, but it would be even easier if we choose better names for the method and variables.

  int min(int[] numbers) {
    if (numbers == null || numbers.length < 0)
      return 0;

    int currentMin = numbers[0];
    for (int candidate : numbers)
      if (candidate < currentMin)
        currentMin = candidate;
    return currentMin;
  }

I just changed the names, nothing else, it does the same thing (and now even the name implies that it searching the minimum in the array). But now it looks much much better.

To be honest, when I was writing the example of bad naming, I made a mistake. I wrote `number > integer instead of `number < integer` and noticed it only when I changed the names. In such a simple procedure, such a huge mistake just because of bad naming. Imagine what can happen when you work on a huge system!

3. Clean Code is minimalistic

Some studies say that it's better to keep your classes and procedures small. 

For classes, there is a magical number that states how many public methods it should have this number is 7. 7 public methods per class makes it easy to remember all the responsibilities of the class. But it doesn't mean, of course, that every class should have only 7 methods, just keep this number close to it.

For methods, there is no concrete number. Robert "Uncle Bob" Martin in his book "Clean Code" says

The first rule of fucntions is that they should be small. The second rule of functions is that they should be smaller than that. Functions should not be 100 lines long. Funcions should hardly ever be 20 lines long. 

While Steve McConnell in "Code Complete" says the following

The routine should be allowed to grow organically up to 100-200 lines, decades of evidence say that routines of such length no bore error prone than shorter routines.

Some people (including Steve McConnel) say that a method should fit the screen without scrolling which is, in my opinion, is the good estimate, despite the fact that everyone has different screens.

I personally think that you should break down the method as soon as you find yourself trying to remember what does some part of the method do. Probably, when someone will look at this part he won't understand it, so it's better to replace it with well-named procedure.

These are in my opinion are top 3 qualities of clean code. There are more of course and you can find all of them in already mentioned books: Code Complete by Steve McConnell and Clean Code by Robert C. Martin.

Now when you know what clean code is you can start following The Boy Scout Rule of coding and make your and your co-workers' live easier. Sometimes it would be easy as renaming some variables. Sometimes it would require changes in the architecture of the software but it always worth it because you are the one who will work with this code.

Now let's make our code a better place! Maybe there is a badge for it ;)