A programmer’s view on technology that hijacks people’s minds

It was a great post about how technology is hijacking people psychologically followed by a TED talk from Ex-Google design ethicist Tristan Harris.

We can directly see it by noticing the people surrounding us. How may social networking addicts have you seen in your friends and family circles? How many people open the facebook in your office washrooms to check the stuff behind notifications?

As software developers, to some extent, we are also a part of this hijacking process. Of course not all, but many of us have been. Only for mobile and web developers: just think about all the apps and websites you have been developing. This post in all about my views about the world we are creating.

The technology we created isn’t helping ourselves to do the right things. For example, If you notice a design pattern like pull to refresh, then we are still just pulling the data from servers in order to refresh the data.

1-BNOfmUQ2nTRVPVe0CHx7ew

This is ridiculous, especially in the situation when the network connectivity is good and network costs are affordable. Why do we still need to call web services and pull the data? We should have real time data transfer in order to save time for our users. Stuff like WebSockets and platforms like Firebase and PubNub is really taking off and so we can hope the future to be good. Ideally, every data storage, transfer and manipulation should work in real time.

Second thing, we must need to care about design. We really need to focus on how can we create user interfaces that can provide functionality in the smallest possible interactions. Currently, all design patterns are doing the reverse. They either try to hide the data or to show more and more data.

The future depends on how we can help our users to have a meaningful time spent on technology in all possible ways. When the business rules the technology, it’s all complicated.

Advertisements

Carrot & Stick: that doesn’t work on Programmers!

'A raise might destroy their initiative. The good old carrot and stick bonus keeps them focused.'

Carrot & Stick – by definition “a policy of offering a combination of rewards and punishment to induce behaviour”, perhaps the oldest methodology for motivation in organisations doesn’t work for tech companies. There are many reasons for that, I will discuss them later. Any engineering solution just can’t follow this kind of rigid methodology to motivate their employees. Still, I can see many software companies following it blindly.

It was a great talk – ‘The Puzzle of Motivation‘ by Dan Pink. The quotes from the talk:

There is a mismatch between what science knows and what business does. And what worries me, as we stand here in the rubble of the economic collapse, is that too many organizations are making their decisions, their policies about talent and people, based on assumptions that are outdated, unexamined,and rooted more in folklore than in science. And if we really want to get out of this economic mess, if we really want high performance on those definitional tasks of the 21st century, the solution is not to do more of the wrong things, to entice people with a sweeter carrot, or threaten them with a sharper stick.We need a whole new approach.

There are many reasons for the fact that carrot and stick approach doesn’t work on programmers. First, Good programmers just don’t work for ‘only’ money. They work because they are passionate about developing software, self-motivated and love to do their job. Shiny paychecks don’t always fulfil all the other things they want. Second, Programming is more than a job. Programming is not a mundane routine work. It is all about solving problems, art and craftsmanship, perhaps someone’s hobby or a passion. Programmers need the proper environment to think, brilliant people to surround by and good projects to keep themselves busy. Enticing with carrots does not address these problems. After all, It’s easy to find programmers. It’s hard to find good programmers.

So, to all the employers following it – that 19th-century old absurd approach absolutely doesn’t work on us and you are doing it all wrong!

Dart : Dead or on Bullseye?

bullseye-926864_960_720                                                   [Image source : pixabay.com]

Around late 2013, Google announced 1.0 of its own programming language Dart targeted initially at the web. But since then, it didn’t receive much attention like other modern programming languages. A bunch of enthusiasts started using it and found it interesting. But as it was targeted against the web (and therefore the javascript) initially, it also received much hate. Some people also marked it dead. In late 2014, I picked it up and just did some experiments for a while. It is truly a cool language from a Java background. In this post, I will express some of my opinions about what went wrong with the language, what is still good and why the language still has the potential. It may be more opinioned and it is how I feel about the language.

What went wrong

Targeting the only web

Initially, Dart was targeted ‘only for the web’. This strategy didn’t work fine. The web development community is horribly fragmented. Also, nobody wanted another language in the web community. There are dozens of programming languages that compile to Javascript like CoffeScript, TypeScript, Scala.js, PureScript, Elm, Haxe, etc. Dart has no reason to be chosen over all of these.

Misunderstood Type System

Type systems are always a matter of controversy in programming languages. Many people would agree that dynamic typing makes programmers productive but when it comes to scalability in software, static typing is necessary. Everyone love experimenting at first. Static typing makes experimenting hard. Everyone need scalability at last. Dynamic typing makes it clumsy.

Dart’s type system is cool. It has an optional type system where you can start with loose typing and then specify the types later. The real benefit of it is that you can gradually evolve programs. At first, you can start prototyping without types and then add types later.

However, the type system was initially marketed like a combination of JavaScript and Java. Of course, Dart has Javascript-like syntax and Java-like standard libraries but the goal of optional type system was clearly not that. Many devs thought of the language as some sort of combination of Java and JavaScript. Of course, anyone would not want to put their efforts or money to learn  or use a combination of two another languages. Instead, why not they just learn those languages?

Javascript-like syntax

Dart creators said that as they are targeting for the web, they wanted to keep the syntax familiar to Javascript developers. JavaScript has the syntax similar to languages like C, Java and C#. They are all old languages. Of Course, there are many improvements in Dart like good functional and async support etc. But there are no syntax improvements.

Instead, with that verbose and old syntax, Dart feels boring. There are numerous things still needs to be improved in the language itself. The braces for named parameters and square brackets for optional parameters feels ugly and unreadable. Many modern languages like Swift Kotlin and Go did a good job of removing unreadable and repetitive stuff like ternary expressions and prefix increment decrement operators. There is inconsistency even in type names. Is there a reason for writing String in upper case and int in lowercase even if they all are objects? Why there are numbers and integers both? The underscores for private members suck. Most modern languages give importance to the readability of programs more than writing. Tiny details are important. If everything is put in a language has no solid reason for doing that, that’s a bad thing.

What is still good

Standard Libraries

Dart SDK provides a complete standard library with built-in collections, futures, streams, asynchrony and much more. So, you don’t have to rely on any external modules to do basic (probably most) things. This is also true for any programming language born at Google, take Go for example.

Tooling

Dart plug-in for IntelliJ IDEA community edition works fine. Tools for the formatting and analysing code – dartfmt and dartanalyzer are also available. The Dart Observatory is really a big deal.

Productivity

Starting with Dart is easy.  I like getting started fast and experiment a lot. Fairly, I like the idea of an optional type system. Optional typing helps a lot here. With all the built-in libraries and good tools, it is easy to build a good app without bothering yourself about searching libraries for basic things. Experimenting is always fun without those type-heavy systems and later I can turn those experiments into structured programs, which is really a cool thing about Dart.

Conclusion

Dart is a very productive programming language and has a great potential but a bunch of bad decisions and circumstances turned the language away from being popular. Dart was always designed as a ‘general-purpose’ programming language. Dart creators have already realised these things and Dart now wants to take on all the client-side development including browsers, mobile platforms and embedded devices. As the language has already failed to meet the expectations, there is a good room for improvement. At this moment, Flutter and Dartino are being mature and we just heard a brand new mysterious OS named Fuchsia that will use Dart as a front-end for building apps. Dart developer summit 2016 is nearby in October and we can hope to see what is next. Personally, I am excited about Dart 2.0.

 

Random thoughts on modern programming languages and Go

When I started my career as a developer, it was about last year of my graduation. At that time, I was like a Java fanboy. I fell in love with Java while studying it. Honestly, It felt very natural as a programming language. (and don’t get me wrong – I still really like Java) When I started working on real projects in my early days of the career, I realised that there is much to learn about programming languages & their semantics. I worked with many smart people and introduced to a whole bunch of new techniques, patterns, libraries and tools to build software in the fast and efficient way. It was a good and overall very enjoyable learning experience but I also passed through some of the issues about the current state of programming.

The Problem with Black box Abstraction

When I started building apps, I was introduced to some popular libraries that are recommended to use for general stuff like networking, databases and image decoding etc. I am very curious and so I always tried to find out how some big libraries works under the hood. I tried to look at their GitHub repositories and navigate to some code and tried to understand how it does some XYZ things. It was very beginning of my career and I always failed to fully understand how they do. So, I asked to some of my colleagues and some of them replied:

Who cares how it does something? It always works”

“You just need to learn about how to to use them. Don’t worry about inner details”

The library is just someone other’s code that provides an abstraction on certain things to make our life easy. But the point is why it is harder to read code than to write it? Why sometimes it becomes difficult for a beginner to look at someone other’s code and reason about it? Is it because the code is written as that one may get confused. or is it because one may not know certain design patterns used in that library? or is it because the programming language itself can do many things in many ways that one doesn’t know about them?

Almost every beginner and most end programmers tend to use libraries and frameworks without understanding how it does something under the hood. They see them as a black box. The black box that does certain things for them and make their life easier.

This is a big problem. Most of the times, it takes more time to understand someone’s code than writing it by yourself. This is why code reviews are taken more around code quality rather than software architecture or performance. Readability is the only most important thing considered while taking code reviews.

I don’t think that libraries and frameworks should provide the abstraction in such way that hides the details of the underlying system. Rather, they should provide the abstraction in a way that people can actually understand the underlying system. Too much abstraction becomes a barrier for most people, especially beginners to actually understand what the system does. It makes them think more about doing things rather than going deep and understanding things. That’s not a good thing. We want people to actually understand the details of stuff under the hood, not to learn the ways of using things. Anyway, this is my opinion and not everyone would agree on it.

The main reason behind all of the things I think is the current state of programming languages. When you look at some of the old programming languages like C++, JavaScript or Java and newer programming languages like Swift or Kotlin, you will realise that they are adding more and more features from one another and thus gives more ways of doing the same thing. This leads to writing program easily and faster but makes programs more complex and harder to reason about. Some people says that it makes programmers more productive. Adding more features to the language is not the only thing that makes programmers productive. When the codebase becomes large, sooner or later people realises that it could be made simpler if it had to deal with fewer ways of doing same things.

Learning Go

For the last couple of months, I have tried many new programming languages. I tried Dart and Kotlin. I looked at Rust and Swift. I like them. They all are feature rich. But they all forces you to think the same and believes that it is the standard paradigm for building good software.

Then, I tried Go. It took me less than two hours to learn the basics of Go. The language is simple and syntax is very much concise. The most important thing I liked about Go is that it has a minimal set of what called ‘features’. For an example, Look at the way of handling errors. At first, it looks very different from a Java background. But when you try it, you will realise that this is the way I should handle the errors. Go is a perfect blend of notions that makes the language very easy for learning and programs more readable for any level of programmer. The way interfaces are used feels very natural. There are no classes and so there is no type hierarchy – the hierarchy that can be broken by subtle changes after decisions. There are no generics. Sometimes I miss them. But when I think as a beginner, I think it is nice not to have them.

The most important thing in Go is that it solves above stated problem. Any beginner can easily read through the libraries and know how it works under the hood. It is very easy to read other people’s Go code and it always takes less amount of time than other languages.

With the current state of IDEs and tools, I feel very productive in Java. But as the second language of choice, I will surely go with Go. :=)