How do “rockstar” developers build their brand online

Posted on Leave a comment

Apparently, some “rockstar” developers are easily able to find time to write quality, long articles, and post multiple, meaningful updates on social media. In contrast, the rest of us “struggling” developers find it difficult to take out time to even share photos from our last vacation. Why is it so that these rockstar developers manage to go about their daily job as well as building their own robust brand with relative ease?

I have multiple times unsuccessfully tried to emulate this, blaming my own approach after each failure. But is that a fair thing to do?

So what do the rockstars do differently? A few possibilities to mind:

  • The rockstars are super-humanly hard working, and sleep for only 3-4 hours every day.
  • The rockstars have mastered the art of time management.
  • The rockstars have discovered the mystical ways of doing work or writing blogs in sleep.

Possibilities #1 and #2 are very much plausible. Still, can we add something else to this list? It turns out, we can:

  • The rockstars build their brand as part of their day job!

Weird. Does that make rockstar developers just as much human as you and I? Is that undermining their capabilities and powers? I don’t think so.

Just look at the contributors page on the once extremely popular web development learning resource, HTML5Rocks:
https://www.html5rocks.com/en/profiles

Almost 90% of all Google profiles are members of “Developer Relations” team. Popular guys such as Addy Osmani, Paul Irish, etc. are all part of this elite group. As it turns out, Developer Relations is Google’s dedicated group whose only job is to engage with the community. We may call them evangelists, teachers, speakers, consultants or developers, but their primary job is to learn new things, solidify their strengths, write great stuff, teach people, speak at events, help clients, and promote products of their organization.

There are a ton of similar examples. The next time you read a good Medium article or follow a popular developer on Twitter, take a few seconds to note their professional profile especially when they are active posters. Every great company you can think of has a team akin to Google’s Developer Relations. Microsoft, Adobe, Amazon, Airbnb… you name it.

And then there are rockstars who are freelancers or have their own startups. They are able to work on their own terms and so are able to find time to build their brands. After all, the more robust their brand the more business they are likely to get.

How cool is that!

I wish I had a job like that, even for a few months, so I could work on building my own brand.

Disagree with my analysis? I would love to hear different perspectives.

The charm of functional programming

Posted on Leave a comment

While reading modern JavaScript code, you might have come across such things as Array.prototype.map(), Array.prototype.filter(), pure functions, higher order functions, the spread operator, etc. Basically, all the things that React and Redux made us write willingly or unwillingly. I am not going to spend the next 2-3 hrs going into finer details about FP. Instead, I am going to link you to 2 great articles I found on this topic.

Functional Programming (or FP) is a programming paradigm, a collection of guiding principles to write code in a particular style. Any developer who strongly adheres to this way of writing code will tell you that it eventually leads to code that is more readable, maintainable, testable and bug-free. In saying that, they would probably be right. Creating in React and GraphQL has made me a big fan of the declarative programming style. FP promotes declarative over imperative. Again, don’t worry too much about all the jargon. Once you’ve read the following articles, you’ll have a good understanding yourself.

FP is just one of multiple paradigm that JavaScript supports (other ones being event-driven, object-oriented and prototype-based; last two being forms of imperative paradigm). There are several other languages that support FP, most notably Haskell which supports ONLY the functional style. The currying technique is an essential ingredient in creating functional code, and is supported in a lot of modern languages including JavaScript.

Interestingly, there was a (famous?) guy named Haskell Curry who is the namesake of the language and the technique described above. Haskell. Currying. Get it?

Enough said!

Here are two excellent articles that introduce functional programming superbly. Read the first one first, after which all code examples in the second article will be immediately understood (really, Avi Aryan has done a great job with those examples).

Master the JavaScript Interview: What is Functional Programming?

Intro to Functional Programming: JavaScript Paradigms | Toptal

Stop Blindly Following W3Schools!

Posted on Leave a comment

I started out learning to create websites by reverse engineering web pages that I found and liked online. The way I got started with CSS is an interesting story. I started developing static websites at a young age. I produced mostly ugly pages by myself and a wee-bit jazzy ones using something like Macromedia DreamWeaver. I hadn’t yet discovered the mystical world of stylesheets.

In the summer of 2006, it had only been a few days since France’s heart-wrenching loss in the final of FIFA football World Cup when I was absentmindedly browsing some WC pictures that I had painstakingly downloaded over my super-slow Internet connection. That delightful little folder of my favorite images was inside SUSE Linux. Whether it was version 9 or 10, I cannot remember.

As I was a KDE junkie, I naturally had the folder open in Konqueror, KDE’s default web and file browser. While scrolling through the list and mindlessly clicking this button and that menu, I stumbled across an option to generate a gallery out of images. I curiously clicked this option and, *boom*, there it was — a gallery of all photos in the folder in the form of a web page. What a beautiful web page it was. The page had supporting files, full-sized images, thumbnails, and an intriguing file with .css extension.

Clicking the CSS file opened it in my text editor. “Interesting, a .css file is only a text file,” I said to myself. Most of the contents in that file didn’t make sense to me, but there were these other pieces that seemed quite obvious such as background-color, color and font-family properties. In my reverse engineering fashion, I made a few changes here and there and refreshed the web page in browser. *Boom*, some of my changes were actually reflected. This seemingly innocuous incident created a minor explosion of curiosity in my mind.

Out came a new tab in Firefox, hastily typed were the letters “google.com” in address bar, and with a thud was hammered the Enter button on keyboard. A big search text box appeared in the next few seconds. What did I type in it? CSS, of course silly. To where did the very first search result point? W3Schools, of course silly. And so began my journey of learning CSS from the most popular web development learning resource on planet. I regret it to this day. My regretful mistake didn’t end at CSS, it was augmented by my learning HTML, advanced HTML and even JavaScript from W3Schools.

Out came a new tab in Firefox, hastily typed were the letters “google.com” in address bar, and with a thud was hammered the Enter button on keyboard.

Fast-forwarding to present times, just a couple of days ago I was listening to episode #7 (Online Resources for JavaScript Developers) of JavaScript Jabber, a popular podcast series for the lovers of the beautiful language. It was in it where a couple of web experts echoed my feelings about W3Schools. Just to be clear, when I was learning from the “great” W3Schools, I didn’t have any such feelings. In fact, I deemed every word and example on the website a work of experts, which they probably were. However, my feelings changed drastically when I “grew up” and started to discover most of my coding style that was derived from W3Schools was composed of a collection of anti-patterns.

In order to appeal to a wider section of audience and to make things simple, examples listed on W3Schools tutorials dumbed down so much that best practices were sacrificed. Take for instance their use of event handler attributes, such as onclick and onfocus, all the while blatantly ignoring the principle of separation of concerns. This was not even mentioned as a cautionary note to the initiated. Tricks and lies such as this put me back in my career by at least a couple of years.

<button onclick="var hello='world'; alert(hello);">Click me</button>

For years W3Schools piggybacked on the “W3” name to maintain its popularity. Meanwhile, other respected developer resources such as Mozilla Developer Network (MDN) took a diametrically opposite approach of going into deep discussions about each aspect of building blocks of the web. That looked scary initially, but with time your eyes and mind adjusted. I recently finished Part I and II of an exhaustive JavaScript resource called JavaScript.info. It also takes a profound approach similar to MDN’s. In fact, it encourages one to read W3C’s original specifications on various matters. Yes, it’s time consuming but hugely rewarding when applying your learning into practice.

I would like to conclude this rather loooong blog post by saying this:

Do not follow W3Schools or any such simplified online resource without questions. Be extra careful, use common sense, and do compare your learning from other (more detailed) sources. Do not let the details scare you away. Embrace detaily things. But don’t follow even the detaily things blindly.

Dev Blabber Ep 1: Building an Open-Core Startup

Posted on Leave a comment

The first-ever episode of a brand new podcast series called Dev Blabber. It’s an initiative that I came up with as part of the awesome Digital Futurists community, where a bunch of geeks, entrepreneurs and seasoned executives discuss technology and software like crazy.

There was a discussion last week in the Coding channel—one of many channels within the DF community, and the one that I lead—regarding the topic of our next knowledge-sharing session. 4 topics were proposed, ranging from React performance optimization to cybersecurity. But this one, about building open-core startups, rose as the clear winner. While deliberating the format of this session, I thought of making it in the form of a podcast. The idea was instantly liked by most in my channel, and thus was born Dev Blabber.

I hope you enjoy this episode, which being the first one is very loosely structured and borderline chaotic. At least it’s true to its ‘blabber’ name.

P.S. More details about DF and how to join are coming soon. Watch out!

Someone should fix how GitHub counts contributions

Posted on Leave a comment
A snapshot of my GitHub contributions

I have been doing a lot of commits lately. Sadly, none of my dozens of commits are included in my total contribution count on GitHub. Why? Because all those commits were to a forked repository. It’s 2019, and I think it’s plain stupid.

I love GitHub, but if there was one thing I’d like to fix about GitHub it would be this. It’s understandable why GitHub made this rule back in the day when they were introducing the contributions map/tracker thingy. Perhaps it was a decent guard against simply copying someone else’s work and adding a few minor commits here and there just to boost your “score”.

But it’s 2019; it’s modern times. Just think about it. One could be forking from a base/boilerplate repository that contains non-substantial code to build something substantial on top of it. This is exactly how I have been using forks lately. As part of following along the Flutter bootcamp-style course, I created a bunch of forks from the course creator’s boilerplates and transformed them into proper apps. I deserve to be recognized for that! It’s as simple as that.

Here’s what GitHub’s documentation has to say about how contributions are counted:

Commits made in a fork will not count toward your contributions. To make them count, you must do one of the following:

1. Open a pull request to have your changes merged into the parent repository.
2. To detach the fork and turn it into a standalone repository on GitHub, contact GitHub Support or GitHub Premium Support. If the fork has forks of its own, let support know if the forks should move with your repository into a new network or remain in the current network. For more information, see “About forks.”

Why are my contributions not showing up on my profile?

Those two options are not plausible every time, since:

  • Opening a pull request in the parent repository just does not make sense when the upstream is intentionally boilerplate. Asking its author to merge your commits into it would be like asking them to publicly publish the solution to their puzzle.
  • Contact GitHub support? Really? Who has the time and patience to do that when you’re working with dozens of forks?

GitHub, if you are listening at all, PLEASE FIX THIS!