We talk about Django with a fellow DF member, Varun Singhal. We discuss its benefits, how it compares with some other web frameworks, and why YOU should pick Django.
Today is my last day at Accenture. I am finally leaving it (for the second and last time) after more than 9 years of giving myself to it. In today’s rapidly moving world, that’s a very long time. Long enough to see so many colleagues come and go until you were the only one left. It’s the rightest time to move out for me. I had a mix of fond and not-so-fond memories during my two stays. I’ll ever be so thankful for all the good ones. Mostly there was a lot to learn, but the learning had dried up since a year or so. I dragged it too far. The learning should never stop! Goodbye, Accenture.
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:
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.
More than 2 years ago, I created a lightweight point of sale system (POS) for our restaurant in Jalandhar called SkewerSpot (SS). I wrote the thing in under a week (cowboy coding, yodlee yodlee youdoo) in Ionic/Angular. Essentially, it’s a collection of hybrid mobile apps that allows a restaurant to manage orders in real-time via Firebase. The 3 apps in this collection are:
- SS Menu — to take orders
- SS Orders — to manage orders
- SS Stats — to view sales data
Nothing too complicated. The thing has been running quite reliably since 2.5 years. So why the rewrite?
Recently, Dad asked me to change a few things in SS Menu. When I got to working on the changes, I realized that my Ionic tooling had somehow become broken. I just couldn’t create new builds. I left it as is and informed Dad I didn’t have sufficient time to fix things around. But he insisted. So much that I finally decided to just rewrite the entire thing in a more modern mobile SDK — Flutter.
I donned my cowboy hat again and sat down to create the menu app from scratch using a skill I had just recently acquired. I think I was able to spit out a functional version of the app in 4-5 non-contiguous days. Creating in Flutter is such a blissful experience. I loved every bit of it.
Flutter makes it infinitely easy to create 100% custom interfaces inspired by designs at Dribbble. You are never crippled by the difficulty of customizing platform’s underlying UI controls. You are always in the driver’s seat.— Me, after having created several Flutter apps based on designs at Dribbble
Unlike the last time, I created the app from day 1 with open-sourcing in mind. I also made sure that my git history was readable enough to help others starting in the world of Flutter learn quickly from my development experience.
But due to a lack of time, I had to make certain trade-offs: the code lacks automated tests, i18n, l10n and accessibility options. There’s also no iOS version as of now. What a bummer!
Check out the code and more details about the app on GitHub:
Help me, if you can, take it to the next level by fixing the caveats and implementing TODOs.
Some screenshots to feast your eyes on:
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.
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?
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).