Things I learnt in My Career

At the time of writing this, my career is more than 13 years old. Starting programming professionally in 2009, and doing some bits and pieces of learning back when I was studying, I have been playing with computers around the start of this century. In all these years, I have worked with 4-5 different tech stacks and worked in corporations with 400+ employees, software shops and startups as well. And with all these I gained a valuable experience. This post tries to summarise the experience for all the readers, including future me. So here we go.

1. Why is most important question rarely asked

Lot of literature in tech space like blog posts, social media posts, videos and questions to the very first instructions we recieve cover some important questions, like what to do and how to do something. It’s everywhere, including many posts here. They are neccessary. They get things done, properly, efficiently and most of the times with fun. And thus it’s documented a lot in one way or other.

But we often forget (or ignore) to ask why amongst all these questions. Why are we doing something? Why are we in this field? Why using this tech stack and not something else? Why are we developing something that is already developed and well tested? We don’t ask this question enough. And probably there are reasons for that.

May be, this question invites some discussion where tech is totally out of domain, and many of us are not comfortable to do anything which is not tech. May be we don’t ask it because we don’t know how to ask it without sounding rude. May be all the parties assumed that this question doesn’t need to be discussed because either we all know answers or we don’t need the answers at all.

But properly asking this question, with only intention of gaining knowledge can open a lot of possibilities. Will reveal the nature. The nature of a feature we’re developing, nature of conversation we are doing and the nature of people we’re dealing with. This makes our day-to-day work more clear, and clarity always helps. I have gained much more recently by asking more whys then whats and hows. And I suggest you should try it too.

2. Writing anything other than code is most under-rated talent in the industry

Writing a code is essential thing for all of us. But writing anything other than code is most underrated talent. Writing contains a blogpost, a documentation, a well explained answer to any forums or even a tweet. These all help us a lot in a lot of ways, like written things helps us to explain and understand things more clearly, or anyone can re-visit written things later on including those who have wrote that thing on first place. Writing also helps us to create a good and controled exposure about ourselves.

All of these is already written, if you search benefits of writing blogs, above points are already discussed in details about blogs. While being right about blogs, these benefits also apply to documentations and forum discussions as well. And in the era of remote working (which is here to stay in one way or other) this gives us another set of advantages. Writing something makes thing official from certain points of view and writing a proper documentation reduce a lot of meetings where people spend time to explain something verbally, which will be forgotten later. Most of the people in our industry focus a lot about the way we write the code, but sadly there is little focus about what else we write that explains what we have written and why we have written.

3. Javascript is inevitable but not necessary

Note: I have written something as a response to a question asked in reddit. This is an updated version of that response. You can see original answer here

There are lot of confusion about which language (or platform) to learn. And a lot of time, we have Javascript as an option.We have JavaScript in web pages, email clients (and emails), servers and many popular “native” apps that run on electron. JavaScript is everywhere. And in one way or other we have faced a task that involve us writing some sort of Javascript. Because Javascript is inevitable.

Javascript is easier to learn, with toolset we have it’s easier to start a project and itereating the things with Javascript is fun. But that fun ends as soon as your project sees a structure. And the loosely typed nature create more problems then it helps.

There are lot of problems that is faced while developing a big project in JavaScript. Some of them include:

• Unless you (and your team) has a habit hard wired into your brain to write docs, good luck about finding the library (or dependency) code you intend to call, does this method exist? How many arguments are there? What type do they accept? It’s harder to find those answers without a proper documentation.

• There are tons of options right now in the ecosystem, which is a good thing one hand, and confusing on the other hand. NPM or Yarn? Do I need Gulp or Webpack? What are they? There will be lot of this kind of questions you’ll have to answer before we settle on a project.

• Have we talked anything about the confusing == vs ===? null vs undefined, ever confusing type system.I get many of these concepts now but it will be hard when you find yourself out of js ecosystem.

• Ok, callbacks are fastest but there is a reason why the word callback hell exists. And Promise (and as their extension async await) are not as faster. I found coroutines and Goroutines (and channels) lot faster.

• Typescript exists, but the moment you face any, it’s of no use. And many of their checks are not available runtime.

So, my recommendation, learn Javascript, for web development it’s a must, for others keep your Javas and Golangs ready whenever you need them.

You can code well, you have expertise over

4. A good tech stack is nothing without good tooling and good community

If you have choice and money is not a question, where would you develop majority of your code? Notepad? Notepad++? VSCode? or Jetbrains?. The majority of us will pick VSCode or Jetbrains because they provide best in class tooling, and many of us are already started moving towards VSCode or Jetbrains and stopped using Notepad++ altogether. And the reason we chose something is, our choice makes our day to day work more easier and less stressful to deal with, even if we have to chose vim or emacs for that.

Me and the teams I have worked with gave weightage to one criteria to evaluate our options, which is good tooling around options and better community support. And that satisfies above criteria, having good tools makes working with the techstack far easier, and having better community support means when we stuck, we may already have our answer or a hint which will help us to move forward.

5. Getting deep into one language is important, only then you can spread out

There are so many questions in the community asking which language or stack they should chose?

My answer is: Start with one language, master it and be part of their community & ecosystem. That will help you to learn many concepts. Including basic ones like branching, looping, object management to intermediate like Network and File Processing to advanced topics like connecting to database or publishing re-usable packages.

Once you are comfortable enough in one language/ecosystem, you can branch out to different languages and their ecosystems. Here you don’t need to re-learn all of the things for new languages. All you need to translate the concepts you have learnt earlier to new languages and start changing it into idiomatic code.

6. Guidelines are Rules in beta, you should have strong reason to move away from them

We have read guidelines in various places. There are processes in our jobs, there are guideline on how best to implement some feature, there are guidelines on how to complete some tasks, and we also have guidelines on how to save yourselves from natural disasters and calamities.

These guidelines exist because they have been formed after years of collective observations, enforcing or allowing some opinions to flourish and allowing our lives to continue as smooth as possible. So there are more benefits to closely follow the guidelines. Because they will provide some security against many un-forseen circumstances.

But they are guidelines for a reason and not rules. There are benefits of these guidelines but they are not enforced on us. The absence of enforcement allows people to be creative and find out more use-cases then originally thought. But not following guidelines means we won’t get any guarantee mentioned above. This harms everyone in the long run.

We may deviate a little from the established guidelines, that will expand the horizon of solution they provide. And we must have strong reason to do that, mostly that reason involves a new use-case or absence of some documentation.But this deviation must be documented, and to prevent any negative effect a rule must be established.

7. You should use your own products/services

This is called dogfooding, this happens when the team that developed the prodcuts is the one who is using it extensively. This helps iron out most of the product’s problems before they reach the end users. And there are many examples where successfull products are result of extensive dogfooding.

• AWS was developed as dogfooding for Amazon’s infrastructure. Once Amazon was able to scale, they were able to monetize AWS successfully. We all agree that AWS is a market leader in cloud platforms.

• Jetbrains are using their own IDEs to develop the features and IDES on top of that. We all agree that Jetbrains have one of the most fines suites of IDEs.

• Earlier and internal versions of Facebook’s Apps and Websites are being tested by ~75000 people in internal testing group, and majority of issues are being caught by them before they go to production (Source: Pragmatic Engineer Blog)

So, to make your product successfull, you should use it regularly. No body will use your product if you don’t find a good reason to use it daily. However, you should have the doors open for customers’ feedback and evaluate them so that this product will have more than 1 users.

8. Going into management (or leadership) is not always a promotion

If you are thinking that Team Lead, Tech Lead or management is a promotion that you’re happy or supposed to get, it’s not always going to be the case. It looks like a career going upwards, but actually it is a career going in other direction. The career in leadership requires a skill that many of us most likely don’t have, that includes planning and people management.

Many of us are promoted because either we are most strongest developer or the first one in the growing team or the last survivor from the team who has lost majority of their original members (or a combination of these). In either of these cases it’s your technology or your willingness played part in the new role. A role which requires good planning skills, good people management skills and a skill that requires us to navigate through hard times more often, and very few of us are prepared for that.

If you’re like that, there are very good communities like r/ExperiencedDevs, LeadDev, or books like Peopleware: Productive Projects and Teams help us a lot.

9. Building a good team is a rare talent

Lot of people build good software, write great documentation. But building a good team, that just jells and create a good product for longer is something that’s rare talent. I haven’t seen a team where each member is treated equal, wanting to learn something from each other, creating something that installs pride in every members, making work fun and that too without involving (or showing) egos.

If you are part of this team, consider this as a valueble time and learn everything you can from this team. If you have built such team, please accept my heartfelt thanks and give yourself a treat (and pat on the back) because this is a rare talent that’s hard to find in the industry. Personally, I was lucky to be part of such team and now I am tryig to apply same knowledge.

10. Your environment must foster trust to make teams successfull

The product and the team will always be successfull if the members are trusted to do their job. And you can’t have one single way of doing the job. A team can have different approach to solve one problem. As a leader, we must put our trust on those approaches and chose one that fits the need, without hurting the other approach or the person.

If you can’t put the trust on the team you have, it’s either they are not empowered enough to take the good decision, or you are not empowered enough to remove the factor that doesn’t allow to develop trust. And that’s always hampering the success of people and the projects.

11. A good work-life balance contains both work, and life

It’s that simple, to have a balance, you should be able to do your work properly, and you should have a life outside of your work.

To grow, we need to give our focused time in work. And when our work should be done, we should be able to switch off and focus on other part which is not directly linked to work. Both of the parts are important, that’s why it’s referred as balance between work and life. One thing should not suffer because of other.

12. We are not siths, we should not deal with absolutes

Someone likes working from home? Fine as long as they’re productive. Someone likes working from office? Fine, it’s their choice, but someone shouldn’t be forced to come to office because someone higher up like to come to office or 2 team-members come to office while other 8 likes to work from home. Someone likes Dark mode? Fine, Light mode? Fine.

Everybody have their reasons behind the choice they make, and in 99% of cases one group is not wrong because they didn’t make that choice or the other group is not wrong because they made their choices.

13. Life is not quantitive

I should not add 13th point just because I had completed 13 years, and next year I shouldn’t force myself to add the 14th…

That’s it. These are the things I learnt and written in this post. There are lot which I learnt, written in the draft but removed from the post because I don’t agree with the point fully. There are other controversial points but I believe that requires a separate space and post. So till the time I decide to write other post like this.

May the force be with you…