A list of hilarious things

(A work in progress . . .)

  • The startup that is yet to roll out an MVP says they always build for the millionth user.
  • The screening test for software positions contains 20 stock aptitude questions that need to be done in 20 minutes.
  • The $1000-budget client insists that the backend be ‘unhackable’ and infinitely scalable.
  • The one hiring for senior developer positions thinks smartphones are “technology”.

When in India, avoid CodeIgniter

There’s a curious aspect to being a PHP programmer in India – the ubiquity of CodeIgniter. The framework that first introduced the comfort of working with conventions to the PHP community, a framework that I believe has outlived itself, refuses to die. In fact, “refusing to die” is an understatement here. The framework is thriving, and at least as far as small- to medium-sized software development firms are considered, there’s mind-boggling amounts of work being done on this framework. And don’t just my word for it; the recent StackOverflow survey results indicate the overwhelming love of developing countries for this framework.

Anyway, I’m not here to shed light on the merits or demerits of CodeIgniter. I’m here to share a personal preference that has served me well as a professional strategy: avoiding CodeIgniter like plague.

As a freelancer, I get approached for a number of projects, and almost always the first question is, “How much, out of ten, do you rate yourself in CodeIgniter?” As a software developer in search of the holy grail, I’ve never had reason to pick up CodeIgniter as my framework of choice. The problem is not the framework per se, but the ecosystem that has come around it – the ecosystem of code cobblers.

I call them code cobblers because in India, a million times out of a million and one, a CodeIgniter developer:

  • Hasn’t heard of TDD
  • Absolutely loves shared hosting and CPanel
  • Thinks Git is no match to FileZilla
  • Doesn’t mind writing SQL queries in views
  • Thinks that the mail server has to be on the same machine
  • Doesn’t mind generating view HTML in controllers
  • Hasn’t heard of Design Patterns
  • Doesn’t write code comments
  • Doesn’t know how to set up a virtual host
  • Thinks Composer makes music
  • Maintains a single giant database table to store everything
  • Is in awe of WordPress
  • and
  • and
  • and
  • Thinks he’s the best thing that happened to PHP development after the introduction of OOP in the language.

How do you work with these guys?

You don’t.

I’ve tried to reform a few of these in the past, succeeding only in raising my blood pressure and making myself quit projects in fury. Just like prehistorical animals, this breed refuses to evolve or go extinct.

By avoiding CodeIgniter now, I automatically avoid having to work with such people or maintain projects coded so crappily it makes the angels weep.

PHP and Technical Debt

For many developers, PHP and Technical Debt are synonymous. After all, at some point in our career, we’ve suffered at the hands of some dimwit developer who left us possibly the worst code in the world to maintain. Code for which no documentation exists, or could exist. Code with loops within loops and functions calling other functions in return statements until your brain starts crawling out of your ears . . . you get the idea.

Generally there’s no evidence to prove that PHP has produced bad code, but the creators of the wonderful Symfony framework might have something to say about it. In 2014, Sensio Labs (the company behind the Symfony framework), performed a technical debt analysis on popular PHP projects. And here’s what they found:

WordPress sits at the top of the mountain, with 20.1 years. What does this mean? This means that if WordPress were to be rewritten today to reflect good coding practices, it would take 20.1 man-years to do it. That’s quite bad, isn’t it?

Down the chain are Symfony itself, as well as the Composer project, that have technical debt of a 4-8 weeks.

Should we conclude from this that PHP is the worst language ever? Not really. If a similar analysis were carried on enterprise-level Java projects, for example, I’m sure similar picture will emerge.

Should we then say that WordPress totally, absolutely sucks? Yes, but there’s a qualification to that, as noted by Sensio Labs:

[. . .] project age is a determining factor in its quality. WordPress and phpBB were released more than 10 years ago, before most of the modern PHP features were available. This put those projects in a competitive disadvantage over other more modern applications such as Composer or Doctrine.

In other words, these projects were developed at a time when OOPS was not well known in PHP, there were several warts and bugs in the language itself, etc. In other words, these frameworks suck because PHP in that time sucked.

Actions vs Mutations in VueX

When I first came across VueX, my head was left spinning for a few days. As if the whole idea of a store that had Getters and Mutations wasn’t enough, I came to know that there exists something called Actions as well. And actions do pretty much what mutations do: change state. Except that actions issued mutations and were called (“dispatched”) by components.

So, components dispatch actions to change the application state, which in turn call mutations to change the application state . . . ??

Once I dug a little deeper, I was offered another explanation: the differentiation exists because mutations can’t have asynchronous operations; for that, we have actions.

But here’s the problem: you can write asynchronous code inside mutations and it works fine. After all, it’s all just JavaScript functions. And you can have only synchronous methods inside actions, reversing the usage but effectively making no change.

What’s the big deal, then? Why care about this different, and more importantly, why follow it?

Turns out it’s an important question, and made it to the Vue.js issues list. The final explanation was provided by the creator of Vue.js himself. Here’s what Evan You says:

The whole point of a system like vuex is so that every state mutation is trackable. This is why mutations have to be sync.

Imagine you have only actions and you do this:

export function doSomething (store) {
    store.state.count++ // this can be tracked when this method is called
    api.callAsyncMethod(()) {
        store.state.count++ // this cannot, because it's async

If you use the logger, you will see doSomething is called, but there will be additional, async state mutations happening afterwards, and when you app gets complex you will have no idea where that mutation came from. This is particularly hard to reason about when calling multiple actions with async mutations, because they can be intertwined!

Actions vs. mutations is all about separating asynchronicity from actual mutations. When you see a sync mutation in the log, you know all the side effects it can ever produce is the different between the before state and after state. But for actions, there’s no such guarantee.

So, the big deal is that Actions/Mutations form a design pattern of sorts. You are definitely not forced to follow it, but if you do, you will have a longer life. 🙂

Being a PHP Developer in 2017

It’s funny being a PHP developer in 2017. You see all these exciting technologies blowing up (for the JS ecosystem, “blowing up” is the right term!) the landscape; NodeJS guys look down upon you with contempt (who get looked down upon by Golang guys, mind you, who get looked down upon by Erlang developers, who get looked down upon by . . . but I digress!), and as a freelancer, most of the projects you come across are coded horribly in CodeIgniter or are to do with unpleasant CMSs like WordPress or Drupal.

For a long time I tried to get out of the ‘quagmire’ of PHP, wanting to migrate to Python, maybe even JavsScript, but there was too much ground to cover and I couldn’t do it. But much more importantly, I keep finding jobs and projects as a freelance PHP developer, so I couldn’t really complain.

These days I’m making peace with the fact that PHP is ‘good enough’ for most use cases, and where it isn’t, plugging in a load balancer, Redis, and Node (for sockets) does the job really damn well. I’m also learning that large-system architecture and deep knowledge of databases are important than fretting over a language’s warts.

My advice to new/struggling PHP developers? Give up CodeIgniter, avoid working in software service companies, start with Laravel but migrate ASAP to Symfony, learn some solid OOPS, rip open a framework, learn advanced PHP (generators, co-routines, etc.), and finally, start contributing to a non-trivial open source project. It’s not that hard; at most it will take a year or two of dedication. But it’s an effort worth making. 🙂

A Founder’s Biggest Struggle

Having watched a few startups closely, I have come to realize that a founder’s biggest struggle is not in getting funded, getting traction, motivating your team, or something else. It’s figuring out whether what you are doing is worth doing, and in almost all cases, it turns out to be impossible.

Take the oft-quoted advice of “Do not quit”. We are told that we shouldn’t quit because the goal is just a few inches beyond our grasp, that there’s dazzling light right around the corner. This advice is read and applied by both types of founders: those who are solving real problems and trying to build something solid, and those in the me-too, quick-money race.

As a founder, the biggest challenge lies in figuring out which side you’re on. And if you realize you’re a me-too, quit before it’s too late. But like I said, it’s impossible for a founder to realize that. Because other than what they are doing, their circumstances are identical: they are struggling with their idea, nobody believes in them, and their families think they are idiots. So if a founder were to look at these symptoms and then compare his life to that of, say, Jack Ma of early days, he’d reason, “I just need to keep going. Like Jack Ma’s, my ideas seem worthless to these people, but one day I’ll show the world”.

Except that it won’t work. The realization may set in after a year, or maybe five years, but it will set in. Unless a founder works his hardest at removing delusion from his thinking, the chances of success are tiny.

Frameworks vs. Microframeworks

I never quite understood the logic behind microframeworks. Unless your requirements are dead simple, I think microframeworks don’t make a lot of sense. And even then, you never know when your requirements might evolve.

When I tried Lumen, I really missed the tinker capability of Laravel. When I tried Flask, the command line was missing. Someone once said that Django is what a Flask app eventually becomes, and I kind of agree. Check out any in-depth Flask tutorial and a good portion will be spent setting things up that Django already has.

I also don’t buy the argument of performance. Infrastructure is super-cheap these days, and a full-blown framework behind a load balancer is a better bet than jumping through hoops in the name of performance. If you really want high performance, go for something like Go or Elixir (or even Node).

Perhaps this will change as my skills level increases. Perhaps as an architect I’ll feel differently. But conservatism is a good thing, I believe, especially in software.

I’m very happy for Kotlin

Kotlin, the hot new programming language off the anvil of Jet Brains, has been accepted by Google as an official language for Android development. Honestly, I couldn’t be happier. No, I’m not a Kotlin developer, or even a Java developer, but I’m very happy to see these trends.

From what I hear, Kotlin is a much better designed language (aimed at eliminating null pointer exceptions?) that has a pleasant syntax and borrows many ideas from functional programming. What this means is that Android development will be much more efficient and pleasant now.

My next dream would be to see Elixir + Phoenix displace every known back-end stack. Of course it’s not going to happen, but I dream on. 🙂

Learning to take more sensible decisions

I thought life will be awesome when I accumulate a ton of learning an achievements. I was wrong. Life has become better, but because I’ve started appreciating the importance of the mundane and taking more sensible decisions.

I’m learning to:

  • Let my blog run on WordPress because it just works.
  • Stay with PHP as a skill-set because there’s lot of work around.
  • Pick Node.js over other more fancy stuff because for my uses cases and at my level, the JavaScript ecosystem of today delivers everything.
  • Appreciate mainstream frameworks like React over underdogs like VueJS.
  • Stay away from “exciting” startups targeting “exponential growth”.
  • Sleep enough and on time.
  • Waste time watching Counter Strike.
  • Purchase music from time to time and give back to the artists.
  • Accept my team/family as they are.

Well, that’s about all I had to say, I guess . . . 🙂

The sheer elegance of Ruby

My flirtation with programming languages today brought me to Ruby land.

So far, I had avoided Ruby as an “idle curiosity”, a language that was designed to be too clever and got popular. However, just how well designed and how clever it is, I had no clue until now.

Gosh, this really is the most elegant language out there. I mean, sure, Clojure and all are also very elegant, but Ruby takes programmer happiness to a whole new level. Whatever construct you peek into, whatever library you turn to, it’s dripping with passion, love, and good intentions.

There’s Python also I admire, but Python seems to be focused on cleanliness and symmetry, which are fantastic attributes in themselves, but Ruby . . . oh, Ruby is something else entirely.

No surprise, then, that the evolution of RoR, Elixir, was chosen to be modeled on the same syntax and values.

I find myself unable to stop learning Ruby, and if all goes well, it will become my go-to general purpose language. Of course Python will remain for algorithms and ML and all, but I’m really hoping to shed behind PHP. 😛