DEV Community: Ravi Ojha

Don't be stuck at dev environment setup!

Ravi Ojha — Mon, 29 Jun 2020 13:42:32 +0000

One of the worst feelings as a developer is not being able to work on what you set out to do. Instead, you spent the entire day setting up the repository on your local system. And what's worse? It's the first week of your new job and you're already struggling, hastily googling the errors thrown by the terminal and running random commands from StackOverflow. This is not entirely your fault. Instruction unclear, fried the system. In this post, we discuss a few approaches and throw in advice (albeit some common ones but not-so-common) for the team as a whole, not just you or team leader, or engineering manager for that matter.

Dev onboarding

In most cases, you're struggling because you still don't have enough permissions and in some cases you're not even sure if that's a permission issue. As a team lead, make sure that the new dev has:

All the accounts in different environments (dev/staging/testing/qa) with enough permissions, of course for the services they will be working with
Accounts, access and configured way to VPNs required to access remote instances
Permissions to access the necessary remote instances i.e. ssh keys
And just to add a fourth point, don't forget about the accounts in all the third-party services you use as a dev; like VCS, build service, error logger, metrics watcher; the list could go on but you get the point

Once the permissions are sorted, next up on the list is find the right README to follow!

Leave it better than you found it

When going through the setup README, you may find yourself stuck at an issue that isn't mentioned there. You spend hours trying to figure out what went wrong and finally fix it. Once you get everything right and working, update the docs! Six months down the line, another dev will repeat it and god forbid if they ask you, and you answer "Aahhh.. I faced the exact same error but I can't recall how I fixed it". That's as good as u/denvercoder9 from this xkcd

Credits: https://xkcd.com/979/

Why aren't the docs updating? It's because sometimes they are hard to locate in a bunch of Confluence articles or Google Drive. It's harder to review the updates. An alternative solution to this is to git track the docs. The ability to easily update and commit makes it easier. There will never be a moment, where you say "I'll do it later" and then get on with business-as-usual. Another reason is just slacking off. Ingraining the culture as a part of the code-review process solves it. And you can always host the markdown files as a static site internally.

Dockerise!

Thyself be blessed by every developer setting up the service on their local when it works flawlessly with just one command docker-compose up. The command may take some time but letting a single command run for an hour is better than running multiple commands yourself for an entire day. Plus, in the meantime, install your own daily dev tools, chat up with the rest of your teammates, make new water cooler friends, or play ping-pong.

Although this advice doesn't apply to every developer's job, it still holds enough weight to be mentioned.

And when you can't containerize stuff, don't resort to installing packages and services system wide. Make use of virtual environments, venv managers and language version managers such as nvm, pyenv, rustup, rbenv, jabba.

Developer workflow

Every dev has their own work environment setup, which they've optimised and mastered over the years. Collection of tools, favorite terminal client, preferred editor to name a few. With a new project, and especially if it's a new language/framework, those tools might lack in one way or another. You'll have to figure out new tools to help with development and debugging. One of the best ways to learn and go about this is to pair-program! Watch someone on your team when they're working. Sit side-by-side and solve it together. Or have them share screen while they code, if you're remote.

One personal experience for me was with Clojure ecosystem. I couldn't figure out the right dev workflow and tools myself and ended up being super unproductive and I'm entirely to blame for it. Never got around to using REPL to its full potential. I might give it another shot sometime in future.

Don't install every microservice in your local

Every dev in the team is setting up every microservice their service interacts with. Unless you'll be modifying the source in those microservices, don't do that. Setup a test instance for devs and install all the services there. Point your local to those services and you're done. I wonder why this is not a common practice in most startups. The server cost will be way less than the time-cost all the devs will be paying collectively.

Also, don't create hundreds of microservices. It's better to have 5 large services than to have 25 micro services. Otherwise, and this is not an issue by the way, your half the git history will have version bump commits. This warrants a separate post and if you have strong feelings against the idea, my answer would be to meet me over chai. Although, like most engineering questions, we could get away with "It depends", you might like reading this.

Did I mention local DBs yet?

This is my favorite problem to fix whenever I start on any new project. Worst case scenario is, there's no db migration history, no local schema and no fixtures for local. And no access to prod/qa/staging databases to source the db dump from. So you track down the last person who had that service up and get the dump from their local machine, given that they didn't nuke it.

First of all, create a db migration history. Then create db fixtures for the local system to work out of the box. And for other random data, maintain a shared SQL db dump, and don't forget to update it regularly. Or write factory methods/scripts that generate such data and running that becomes part of local setup.

Be loud and clear in communicating the changes in db schema, you don't want the next person to pull the repo and panic because their local was working yesterday evening. This is mostly solved by maintaining migration history, however, there are some cases when you might have to run some manual commands.

Don't take security for granted

Share credentials to services via encrypted password managers or fallback to sharing PGP keys with internal teams. Don't trust any service/person no matter how convincing it sounds, you'll develop trust issues when you're betrayed by one. It's not a bad quality to have. Trust, but verify. Yeah, that's just a nice way to put "Don't trust". Be like this good boye.

Be humble to your new teammates

When you're helping a new teammate who has more experience than you but you find that they don't know some of the stuff that you use daily, don't get annoyed when they ask you the most obvious of the questions. It takes a bit of time to get used to a new tool/service/product. If you do, they'll hesitate to ask further questions and those questions will arise again when another dev joins the team after a few months. And if the present new dev is helping the future new dev, an answer "I don't know man, that's how it is. It just works." is a bad bad first impression to make.

Be humble, even if you have to explain it twice. They were smart enough to clear the interview process as you did. Initial support will go a long way, you may even end up making lifelong friends.

Originally posted on rookieslab.com

Forgot the name of your recently used git branch? Gotcha fam!

Ravi Ojha — Wed, 12 Jun 2019 04:03:11 +0000

Add this alias to your terminal's rc or profile file. For most users, it is .bashrc or .bash_profile in the home directory. Fire up a new terminal tab, cd to any git repository and try out the command gitrecent.

alias gitrecent="git for-each-ref --sort=committerdate refs/heads/ --format='%(HEAD) %(color:yellow)%(refname:short)%(color:reset) - %(color:red)%(objectname:short)%(color:reset) - %(contents:subject) - %(authorname) (%(color:green)%(committerdate:relative)%(color:reset))'"

Source: This stackoverflow answer

What was the config of your first computer?

Ravi Ojha — Fri, 07 Jun 2019 05:33:06 +0000

Mine was a Compaq PC with Celeron D processor, 256 MB Ram, 80 GB HDD accompanied with a Floppy and CD drive. And the only programming activity I did on that machine was writing C code to print one of them * patterns.

[Personal Story] What it takes to develop, test and release a Software Product

Ravi Ojha — Thu, 30 May 2019 12:07:45 +0000

Prologue

As a human being you are always pleased when someone appreciates your work. It was that day at work when appreciations were flooding from all directions! Mentor, Manager, HR, CTO everyone seems happy with your performance throughout the year. You're overwhelmed with their response and after a short one-to-one with every concerned party, you go back to your desk, feeling delightful. 4 quarters of development, 512+ commits in production, features shipped within reasonable time. The feeling of being on top of the tiny little world!

Software Breaks

There's some hitch in the company's product that serves the business needs of enterprise clients. Sales team is facing some heat from the clients. Drop-off has touched a new height. CEO is furious. The same product used to work seamlessly a year ago. You're curious. You go back and use that product as a client. The product works flawlessly! But what do you say to the client? "IT WORKS!" NO! You read support tickets, analyze user activity logs, get on call with clients, go onsite and watch the product being used right then and there! You finally figure out why it doesn't work. When 1000 users share a 100 MBPS lease line, which has been poorly distributed, your website takes forever to load.

Again, what do you say to the client? "Our website isn't made to handle such a scenario." YES and NO! You have an enterprise product. This wasn't the problem you initially set out to solve, but it is now a problem for your client. Now it is YOUR problem and you solve it to retain the client. So, it is decided. We get back to work and optimize the hell out of every single line of code.

Wired In

You have a small team of engineers, countable on fingertips. You cannot make everyone go out of their way to work on one single project. The company has to keep innovating to keep up with the competition. Can't afford to loose the client, can't afford to get the whole team to work on it, it goes without saying, it has to be fixed, and fixed fast! And you're the man to do it.

You, your mentor and a fresh recruit roll up the sleeves and identify all the pain points. You don't have the liberty, in terms of time, to fix all of them. You highlight the major ones. After exhaustive five days of architectural discussions, you spend the weekend in identifying the solutions to the technical challenges you figured so far.

Initial plan is set up. You'll build a prototype in a week using a new framework you found that will drastically improve the site performance. Your mentor is not just your mentor, he's got more burden on his shoulders. He left you there, with the new kid. You are not yet sure how things would wind up, junior is equally bewildered. You pull down the list of all the bugs and tiny feature requests and ask him to choose any of those. You have him sorted. A week passed and you have a basic prototype ready, it is not exactly what you expected, but hey, at-least now you know how to use that framework. You three huddle up again. Figure out the exact classes and relations. Now starts a two week cycle.

You create a design document using the pictures of white-boards you took during those discussions. You get into the zone. After a week, you have coded down the classes. However, when you revisit the design doc, you find that the implementation has been done differently than what you thought initially. Not a problem, it happens. You go back and edit the doc to reflect what you had implemented. You stroll back to home, on a Friday night, thinking you have finished a two week job in a week. You're satisfied with yourself and give yourself a break. You spend two days goofing around, having your favorite dishes, messing up with LSPD in GTA V and making up for sleeping only 24 hours in last 5 days.

Another week, you take a look at the specs again, you don't want to lose out on some feature that you had in the old architecture while building a new one. You found a few things and make amends for that, in code and doc. You get back to the new teammate and help him push his first commit to production. Meanwhile, you start looking at how the codebase might look like at the end of this quarter. And there's another weekend.

Time Flies

Time flies, half past quarter of the year. Product Manager is looking for an exact date of release, because sales is asking for it, because they have to say "something" to the client. And you sit there thinking about a rough estimation. Your company has a policy that the one who is actually working on the project names the release date. You have to give some date by the end of day. You have only modeled the architecture and it's hard to explain why it is so hard to estimate the time to release. You have no clue how many obstacles lie ahead. It is end of day and you shoot an email saying that you'll release it in the first week of new quarter.

Everyone seems happy about that. Your mentor is worried because he knows you made a very ambitious timeline. You both get back on the white-board and figure out the exact implementation details. You start to categorize features: must have, good to have, great to have. You have covered must have and implement them with 2 weeks of buffer time. New kid is doing great, he is learning fast and delivers within reasonable time, and well, plays along with your occasional bitching about the old architecture.

Meanwhile, you add a few of the good to have features in the new implementation. The only QA in the team has started doing terrible things to your website. You yell, "Why are you trying to submit an integer when I have provided you with auto-suggestions in that goddamn location field!". You get a list of 40 something bugs. You stop adding the good to have features and get back on fixing those bugs. You and your teammate divide 50-50. Some of them are very critical. And there doesn't exist a quick fix. You have been working 60 hours a week since last 5 weeks and are still on it this weekend. You are cursing yourself and swear that you'll perform an extensive research before shouting out the release date for the next project.

Final Push

The first week of the new quarter is here. Everyone is looking at you. They are not saying anything, but you can see expectations in their eyes. Your mentor casually passes by saying "Let me know if you need any help, I'm always here". You feel good to know that someone's got your back.

You're done with almost all the bugs. There were some easy fixes, ugly fixes and terrible fixes. Now, everyone involved in the project starts testing the product. There are some minor bugs and UI changes. The QA comes up with 10 more functionality issues. You go through each of them. You're frustrated. Some new good to have features have broken some must have features. Meanwhile, the sales team had also promised those good to have features. You cannot just rollback the changes. But it's not just that, you as a developer like to own the product and cannot afford compromises yourself. You sheepishly ask for a week's extension.

Another week passes by and you declare that you'll release the product and replace the one in place on early Saturday morning. But hey! We forgot about one important part of the whole software development process. What about code review? Ahh.. yes! Code review. Your mentor had a good look at it. You have been working for quite a while with him and know what is expected of you in terms of code quality. There were some suggestions, but you make a call to try and rework on it in the next 2-week cycle after launch. Let's ship the product, we have already delayed by a week.

You had prepared a release checklist in the last quarter: database migrations, new framework, new packages, dependencies, tests, scripts that syncs the new and old tables, and the final git push origin master.

You were awake all night and waiting for your window of opportunity. At around 4 in the morning, you start the release process. It took 3 long hours to setup and deploy the product. Those 3 hours were the most intense 3 continuous hours of your life. You had sat and written hundreds of 3 hour examinations in your life, but this doesn't compare with any of them. You were nervous, scared, drowsy, yet delighted, thrilled to see the new dashboard live in production. Finally, the new, lightning fast product was up and running.

Epilogue

It is 7:00 AM now, the all-nighter had taken its toll. Your body cannot take it anymore, however, you write down a long email highlighting all the improvements, full with emotions, sipping a cup of coffee. Before you hit the send button you get a gtalk ping from your mentor "I'm very proud of you". You're glad to know that he was watching you, all this time. You end the email mentioning the contribution of every single person, highlight the new kid's work and hit the send button. Everyone is so happy to start their day with such a good news. Emails with Kudos \m/, Exceptional Job, Superb work pour in. You're having the most soul satisfying moment of your life. You pack your bags and leisurely walk your way to home. You take the long awaited sweetest sleep.

Originally posted on rookieslab.com

How to apply for Software Engineering Internships at startups

Ravi Ojha — Thu, 23 May 2019 07:34:37 +0000

With the beginning of the new year, every startup’s open mailing list starts receiving emails from graduate students for a summer internship. I have read hundreds of applications that follow a generic template, somewhat like this:

Dear Sir/Ma’am,

My name is and I am currently pursuing my in from . I am well-versed with C/C++ and have started learning Java. I’m also learning about Android and iOS apps. I have good knowledge of HTML, CSS, JS too.

If given the chance, I’ll give my 100% at work. I am confident that I will be a valuable asset to your team.

Please find the attachment of my CV

Kind regards,

Seems like a decent email, however, there’s one major red flag about this application. The applicant is not talking anything about the startup he is applying to and how he will benefit them. This shows that the applicant has not researched about the company’s business and engineering. So, how to write an application email for Software Engineering Internships at startups?

Find the right point of contact

Try to address the right person in the company. When you begin with “Hi” or “Hey there” or “Sir/Ma’am” you’re diffusing the responsibility of a reply, a lot of emails are lost in the haystack because everybody in the group thinks that it is not meant for them or someone else will reply. Connect with someone in the company and ask them for the right person to contact for the purpose. Address them in your application email.

Keep the intro short

Keep the subject line and introduction short. Begin with your name, major and institute. That’d be all. Next, you should be talking about what you know about the company and how you both can benefit each other.

Talk more about what you can give to the company, less about what you’ll take away

Research about the company’s engineering. Many tech companies have engineering blogs. You’ll know what technologies they use. Now you have what technologies you should highlight in the application, only if you know them well.
Check out the open source projects of the company. Every good tech company knows what engineering tasks they are going to accomplish in the upcoming year. You can contribute to their public repositories. And then highlight this in your application.
Use the product or services offered by the company. Find all sorts of possible improvements and suggest solutions for them in your application email. Every user out there is pointing out problems to them via support tickets, so suggesting solutions for them is an important part.

Sure that’s going to make your application a little longer than usual, however, it will make you stand out among the crowd. Ideally, such an application should be addressed to one of the engineers at the company.

Be objective about why you’d be a good addition to the team

Terms like “I’ll be a good addition to the team”, “Fast learner” etc. are subjective in nature. You have to prove it objectively. This is why many companies have started giving away take-home projects. Candidates can work on it for a week and depending on the work accomplished, companies get a good idea of how the candidate will perform during the internship. Some companies think that the candidate can cheat by asking someone else to do the take-home project. So they keep the candidate for a week-long project on trial. To overcome all of this, you, as a candidate, can think of features or apps that you can build which could be of value to the company. You can also make use of any APIs exposed by the company. You can then highlight such contributions to the company in your application, which shows that you’re reliable because you have a good past record.

Have an online presence

LinkedIn and AngelList are extensively used by Talent Acquisition team because they are quite familiar with their profile format and features. A Github account with few repositories and regular commits helps you in two ways: It shows that 1. You know how to use git 2. You’re consistent at work. Engineers may check your code to judge you by its quality.

You may also create a portfolio for yourself. You can extensively highlight all your projects in the portfolio. You can also write tech blog posts about the challenges you faced during some project and how you solved them. By thy way, if you’re good at communication (written or verbal) you will do well in any job in the world. And your application email is one of the things by which every company is going to judge your communication skills.

Personally, I've landed two startup jobs so far because the founders found my blog.

Résumé

Lastly, prepare a short résumé that highlights your strengths and modify it for the target company. The resume format suggested by careercup seems adequate. However, it is suggested to apply your creativity to make it stand out. People don’t spend more than 30 seconds to go through any resume. Make sure you make those 30 seconds count.

All of the above points are “DOs”, let’s have a look at few of the “DON’Ts”:

Don’t send blind emails in bulk in to or cc or bcc expecting at least one of them to respond. Target a few companies and write personalized emails.
Don’t write a subject line longer than 5-8 words.
Don’t share your email format with your friend who is going to send the same email to the company by replacing a few things. You both will be rejected.
Don’t mention all the technologies you know, a company is not interested in what you know, they are interested in what you know that they use. Do your research well.
Don’t include subjective statements which cannot be proved like “I always give my 100%” and similar statements.
Don’t send reminder emails on your application email frequently. Give it a week for them to respond. They receive hundreds of emails every day.
Don’t say that “Review my CV and match it to open roles in your company”. It is the candidate’s duty to target a particular position.

The startup hiring process includes resume filtering, phone screening, face-to-face interviews (plus take-home projects in some cases) and final interview with founders. Many good candidates are not able to get past the first hurdle. To all those candidates, next time you apply for an internship, use this post as a checklist. All the best!

Originally posted on HackerEarth

Python caveats #1: Multiline comment within a Python dict

Ravi Ojha — Wed, 22 May 2019 12:34:21 +0000

Let's say we have a Python dict and we were to document the general format of the key-value pairs. For the lack of a better example, let's take the following dict as an example:

family = {
    "goku": {
        "name": "Goku",
        "race": "Saiyan",
        "aliases": ["Son Goku", "Kakarot"],
    },
    "chi-chi": {
        "name": "Chi Chi",
        "race": "Human",
        "aliases": ["The Ox-Princess"],
    },
    "gohan": {
        "name": "gohan",
        "race": "Saiyan",
        "aliases": ["Great Saiyaman", "Son Gohan"],
    },
}

The general format of the key-value pair is:

"username": {
    "name": "",
    "race": "",
    "aliases" [],
}

And to add this as comment, we might try this:

family = {
    """
    General format of entries is

    "username": {
        "name": "",
        "race": "",
        "aliases" [],
    }

    """
    "goku": {
        "name": "Goku",
        "race": "Saiyan",
        "aliases": ["Son Goku", "Kakarot"],
    },
    "chi-chi": {
        "name": "Chi Chi",
        "race": "Human",
        "aliases": ["The Ox-Princess"],
    },
    "gohan": {
        "name": "gohan",
        "race": "Saiyan",
        "aliases": ["Great Saiyaman", "Son Gohan"],
    },
}

Let's check the keys of this dict now.

In [15]: family.keys()
Out[15]: 
['\n    General format of entries is\n\n    "username": {\n        "name": "",\n        "race": "",\n        "aliases" [],\n    }\n\n    goku',
 'gohan',
 'chi-chi']

Hold up! Why'd that modify the goku string? This is because surrounding something with """ doesn't necessarily mean as comments in Python. It is just a multiline string. Imagine it as a string literal, which isn't assigned to any variable. There's no such thing as multiline comments in Python, unlike other programming languages. The right way to put multiline comments is by using #.

You'd recall using """ to put comments at the beginning of function/class, also otherwise known as docstrings. Well, what do you know, those docstrings aren't really comments. It is just a string literal and a standard convention^[1].

So the right way to put a comment in dict would be

family = {

    # General format of entries is
    # "username": {
    #    "name": "",
    #    "race": "",
    #    "aliases" [],
    # }

    "goku": {
        "name": "Goku",
        "race": "Saiyan",
        "aliases": ["Son Goku", "Kakarot"],
    },
    "chi-chi": {
        "name": "Chi Chi",
        "race": "Human",
        "aliases": ["The Ox-Princess"],
    },
    "gohan": {
        "name": "gohan",
        "race": "Saiyan",
        "aliases": ["Great Saiyaman", "Son Gohan"],
    },
}

tl;dr

There's no such thing as a multiline comment in Python. Use # at every line to truly create multiline comments.

[1] PEP 257 -- Docstring Conventions

Originally posted on rookieslab.com

Is it boring working in Web Development startups?

Ravi Ojha — Thu, 16 May 2019 13:05:45 +0000

Prologue

An overwhelming majority of startups are serving their software as a service via either mobile app or web app. Many startups have tried to go mobile-only and haven’t really seen much appreciation from consumers because web interfaces allow more control and focus compared to mobile apps. Unless we discover a new radical medium that takes people off their computers, web apps will live high on the hog.

Many aspiring software engineers argue that web development is boring, “So what do you do? Change the size of a button?” :D. As a matter of fact, that is not a false statement. However, it is an incomplete statement. The reason that most of the projects started by individuals are at 80- 90% of completion, yet not production ready, is because they halt at the boring part. Let’s go over a general process that takes an idea and makes it live in production.

Ideation and Mockups

Almost every startup is trying to solve a problem faced by either businesses or common netizens. The real fun lies in talking to those users and making the product that all of them will use or pay to use. And if you yourself are among the end users of the product, the work will not feel like work at all, because all the way, it will feel like you’re working for yourself.

Once you have a good idea of what problem you’re solving, first task at hand is to design a wireframe mockup. Generally, you’ll just sit by the side of a dedicated UX designer. List down all the user actions and how your app will react to that. In the end, you’ll have multiple screens and that will define the entire flow of a user’s journey on your app. This is the point when you’ll have a vague idea about the backend structure for the app.

Design and Architecture

Talk with a couple other developers, perhaps tech leads, about the architecture that will act as the backbone of the system, keeping the future possible requirements in mind i.e. any change in specs in future should be easily incorporable in the current architecture. Sometimes, developers try to escape this part and jump straight into development. This causes havoc at a later stage when code becomes complex and causes unnecessary delays in product launch. And then you launch it anyway, which leads to bugs in production and then you end up fixing bugs for few more weeks. It is advisable to pen down everything in a document, because when you’re actually writing code, you tend to forget one or more features. Moreover, that design documentation will help as a good reference for the team and for any other developer who might want to join you mid-way.

Estimating the number of users, servers, database and minimizing the server cost also comes under this section. You don’t want to pay for servers that stay idle most of the time. Depending on your app, you’ll have to decide about the number of CPU cores, memory and disk size of the server, type of the database etc. There are design decisions like which process has to be run on which server. Not every process is run on single server. Some processes can be executed on another server (whose sole purpose is to perform low-priority process intensive tasks), thus reducing the load on the server and ensuring faster response time. Knowledge to take such decisions is acquired over time. This is why it is important to have at-least one senior engineer on the ship.

Backend and Frontend

Once, you have figured the position of every piece of the jigsaw puzzle, you start to build each piece to eventually put all of them together. You put on your headphones and convert the design documentation into actual code, often sipping coffee all the way, writing unit tests for critical components. Generally, you’d want to keep the backend code totally independent of frontend. People write APIs and then expose their endpoints for later use while developing frontend. In the meantime, designer would be done with the first version of designs (converting wireframes to actual UI design).

Now, you get into developing the part that end users will be interacting with. Some people don’t like this part and argue that it is repetitive and boring. However, this is what defines your app. No matter how beautiful your backend code is, how optimized your architecture is, if you don’t get this part right, you can’t get a user onboard. The best way to develop frontend is by becoming a user of your product. That way you’ll avoid making compromises.

Test and Release

Finally, when you have put together every component, the product is ready for use. Before releasing it, you’d go through manual testing phase. Best way to test a product is by watching two kinds of people use the product: one who knows every bit of the product usage, another who has no idea what the product has to offer. The former is usually done by dedicated manual testers and/or automated selenium tests. The latter are your colleagues or close friends or beta testers. Use the feedback from both of them to further improve the UX and fix bugs.

Startups are agile in nature. We move fast and break things. A bare minimum, usable product launch in 6 months is arguably considered better than a complete product in half a decade. You also have to survive the competition. You launch it when you see it fit enough for your end users. Someone once said “Before you launch it, take a week off, have a good time with family and friends. Once you’re back, use your app as an end user”. This is because you get emotionally attached with the app after working so long and hard, which leads to compromises. However, this practice is rarely followed because it is hard to control emotions and the urge to release. People go on a vacation after launching the product and then come back and mould it around using direct customer feedback.

Epilogue

If you read it this far, you did enjoy the process, didn’t you? For simplicity, a lot of minor details have been skipped, however, in general the entire cycle is more or less the same. Also, this is accurate if you view it from the lens of a product developer working in a startup of not more than 15 engineers. There are engineers who work on totally different things that create entirely different impact which is not visible to users directly. Some examples of their projects are: Compressing and Lazy Loading Images, AI that replies to support tickets, Autoscaling servers by learning the past traffic trends and guessing the future flux and many more. Some projects do not make any impact on product in anyway, instead, they help other developers to work efficiently and enable them to deploy code seamlessly to production in a matter of minutes, thus increasing engineering productivity. Bottomline is, you choose to work on projects that you find challenging and what leaves you with utmost satisfaction when you walk back to your home in the evening.

Originally posted on rookieslab.com

How to become better at reading and debugging code

Ravi Ojha — Thu, 09 May 2019 18:00:29 +0000

Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it.

- Brian Kernighan and P.J. Plauger, The Elements of Programming Style

The first thing you do when you join any company as a Software Engineer is read the existing codebase. How do they make you read it? They ask you to solve bugs or develop tiny features so that you get acquainted to the codebase. I have a pretty hilarious analogy for this. Ever played GTA? Initially, you spawn up somewhere in the city and they give you small missions that requires you to travel around the city. As you travel more you get familiar with city streets. Just like that, as you fix bugs and develop tiny features, you start getting familiar with various modules in the codebase and eventually you become experienced enough to work on large projects, much like how you carry out complex missions later in the game.

Reading unknown code is usually intimidating. You crawl through a function which calls other functions in turn which may further call some other utility functions. Eventually this increases the scope of your knowledge about the codebase. This means that your ability to read code matters more than you can write. Yet, we are never taught how to read code and debug. That is one of the reasons why the first 3-4 weeks are so hard at any new job. Also, most of the companies fail to test this capability because there’s no way to test this unless the candidate works on a large enough codebase in some phase of the interview process. Some companies do 1 week pair-programming sessions to test this and some other additional things. However, it is not possible for all candidates due to various reasons. Let’s see a couple of ways that can help you in becoming good at reading someone else’s code and debug it.

Work on community projects

Open source projects are as close as you can get to a production-like code. If I tell you to find open source projects of your interests and try to go through their code then there are higher chances that you might give up on the way, because reading someone else’s code is arduous and distressing, which is why you’d see that a new developer working on previous developer’s code is often cursing the latter^[1]. However, the new developer doesn’t know why it was done the way it was because he hasn’t been in the previous developer’s shoes yet.

A better way is to look out for real world problems that you or your friends are facing. Try to come up with a programming solution, don’t start to code it just yet. Pen it down in plain English. Once you think you have a good enough solution, look out for open source projects that are solving that specific problem or a general version of such a problem. At this point, you’ll have a strong desire to know how others solved it. This curiosity will generate enough motivation to literally make you crawl through their documentation, code and previous discussions. Use that project to solve your problem. On the way, you’ll notice how you can improve some part of code to obtain some extra functionality. That will be your first contribution to the project. By this time, you’ll get the hang of how to read code. This exercise will help you understand large codebase, its structure and why it is so. And it will make you empathetic towards previous developers. Over time, codebase grows, just like an organism^[2].

Compete in online programming challenges

Another approach is to take part in competitive programming contests. But again, why should I do it. There’s no straightforward answer to this, however, it is worthwhile to mention that competitive programming will make you write faster, efficient solutions; makes you great at debugging your own pile of unreadable code, because in the initial days you’ll tend to write buggy solutions; helps you think about corner cases and write a bug-free code. And yeah, your knowledge about data structures, algorithms, mathematics and logic will improve drastically. From an undergrad’s point of view, these qualities are quite handy when you turn up for campus interviews. Companies like Google, Facebook, Quora ask related questions to fresh graduates.

If that motivates you to dive into competitive programming then think no further. Head on to any of the competitive programming websites such as Codeforces, CodeChef, TopCoder, HackerEarth, HackerRank and start solving problems. There will be moments when you’ll not know how to solve a problem and that’s when you’ll read someone else’s solution. Now, keep in mind that, everybody writes partly obfuscated solutions because they are meant to be one-time thing and moreover, there’s not much time during a contest to add comments to the solution or use descriptive variable names. So, going through such bad, unreadable, unmaintainable, non-reusable code will make reading and debugging quite easy for you in the future. I should mention that this is like preparing yourself for the storm but finding a drizzle in the end, so that you can just sail past through it. Naruto reference: Rock Lee used to weight-train himself so that in an actual fight, by dropping the weight, he can fight at incredible speed.

Bring projects to life in a hackathon

Yet another approach is to not look out for the open source projects after you found a good enough solution yourself. Instead, shift in hackathon gear and build your own project overnight. Deploy the code and start using your own product, fix bugs, add more functionality and do other terrible things to it^[3]. Now take a break for 6 months. Forget that you ever built that project. After half a year, continue your work on that project. At this moment, you’ll curse yourself because you’ll find it hard to read and extend your own project. This will also make you care about future developers who are going to work on the project. Other than making you good at reading your own code, this exercise will also teach you to accept your mistakes and next time, you’ll structure your code better, write documentation, use descriptive variable names and commit maintainable code.

Have you mastered the art of reading and debugging code in your own way? Share it in the comments.

[1] Why your previous developer was terrible

[2] Codebase is an organism

[3] Do terrible things to your code

Originally posted on rookieslab.com

T-shaped smart creatives

Ravi Ojha — Thu, 02 May 2019 19:52:49 +0000

In How Google Works^[1], they describe smart creatives as "impatient, outspoken risk-takers who are easily bored and change jobs frequently".

The term "T-shaped person" is, quoting straight from wikipedia^[2], "used to describe abilities of a person, where the vertical bar on the T represents the depth of related skills and expertise in a single field, whereas the horizontal bar is the ability to collaborate across disciplines with experts in other areas and to apply knowledge in areas of expertise other than one's own".

The traits of T-shaped smart creatives are apparent by now. Although they specialize in certain skills, they will not limit themselves to tasks in their bucket. That's what the horizontal bar on that T represents. They tend to work for short focused hours to get in the zone and solve deep technical problems, which leads to growth in the vertical bar.

For most startups, the two most important factors from engineering point of view for their product are: speed and reliability. They ought to get a couple of these T-shaped smart creatives on their team early on. Why, you ask? Let's see what makes this species and how you spot them?

We often come across the title fullstack developer, often misused; in my personal opinion, I like to describe them as engineers who can build a full fledged web/mobile/desktop app with a reliable backend and frontend from bare mockups, with ability to deploy and manage future deployments with ease. Don't worry, in a few days’ time, they will bore out of the daily deployments and create automated processes or integrate a CI/CD tool.

They are business savvy and will not start with development until they understand the product in its entirety and how it's going to make the target audience's life easier. They will become the user and that's how they think beyond the product requirement docs. They realize the importance of flexible and robust backend architecture and the deeper understanding of the product helps them build a system which can accommodate unaccounted requirements with low effort.

Once the product understanding is checked off the list, they step on the gas and build the independent parts with the team. After the initial setup, they will probably write generator scripts for most of the repetitive parts of the code or convert them in generic form so as not to repeat them at all, thus saving them time to invest in acquiring more knowledge and expand the horizontal bar on that T. For example, if you're working with React.js and Redux, you'll end up writing a script that generates initial boilerplate files and code for your components.

In their minds, the job is not finished when the product is deployed. They love to see the results. What other way to measure success, or failure, than by measuring user behaviour? Looking at metrics is gratifying to start the day. If the decisions taken by gut during execution were validated by data later, that's reassuring. If they don't, they now have data that directs them towards the right path. Although, the scope of managing a product is slightly out of purview of this individual, this approach will get the startup through till MVP and could even work till product market-fit.

They are expressive and do not shy away from positing their opinions. And boy, aren't they strongly opinionated! However, as they gain experience, they learn to hold them weakly. In fact, if you hold frequent conversations with them, sometimes you'll find they might contradict their own opinions with time, the frequently acquired knowledge helps them change their views. It's always a good idea to not confine them or shut their opinions. Those conversations will in turn generate more ideas and possibly the next big innovation in the company.

They may hate meetings, definitely the ones without a solid agenda because such meetings sometimes last too long without any concrete outcome. But if an insidesales executive asked them to hop on a call to observe a totally new user use the product for those first 10-15 mins, they will love to live through that fresh perspective again because working for last 6 months has made them so comfortable with the product, they probably access every page of the product by typing in the url now.

They will not wait for users to report issues with the app. They will capture error logs and raise loud alarms for them to fix the issue. There will be times, when the issue will be fixed in the production before the CXO forwards the support ticket to dev mailing list. They realize that if the issue has a minor fix and something can be done in 5 minutes, better do it right now rather than scheduling it.

Beware, as the first line of the post says, they are impatient, easily bored, and will question status quo. They will be the first ones to leave if they are not challenged, or are confined, or their productivity is hit by management processes. And the traditional management team will find hard to manage them. Do not expect them to follow step-by-step instructions. Tell them what you want and then let their thoughts and creativity take over. They uphold high moral standards and create a culture where every one of them trust each other on their word. This weeds out possibilities on internal politics and management has to make sure the culture is preserved with every new hire.

In most resume screening processes, a candidate with frequent job hops may not make the cut; neither the one having experience in multiple domains/skills as that may indicate that the candidate holds expertise at none. If we think from the company's point of view, there's risk in first investing time in interviewing and training for about a month and then watch the candidate quit less than a year later because of any of these common reasons: too slow for gratification, bored with no challenging work, not able to fulfil their curiosity to acquire new knowledge, monotonous work, need a fresh product to work on.

Large companies become more and more risk averse as they grow and it's in the best interest of both parties to screen such candidates out if these reasons don't sound concerning. However, startups are courageous by nature. At an early stage, co-founders wish their employees work as if they own the company, people who get things done, who they can blindly trust when they say "We'll figure it out". And if groomed well, these T-shaped smart creatives are the future CXOs in line.

[1] How Google Works by Eric Schmidt, Jonathan Rosenberg

[2] T-shaped skills

Originally posted on rookieslab.com