Software development is teamwork

Software development is teamwork. If you think you are the only person doing all the work. Think again. No one can do it alone. We need help and we get it either directly or indirectly. You may have solved this problem but not without the help of others. So let’s respect that.

Someone has pitched to get the project.

Someone has found the bug in your project before it goes live.

Someone has helped you out when you were stuck with a stupid bug for the last 2 days.

Someone has given a different perspective to a problem.

Software development is teamwork if you think you do it all alone.

Knock knock

You are wrong.

Everything pays off

Eventually, everything pays off.

The song you have written. The movies you have watched. Every day with our every interaction we learn something. The internship you did after college or those experiments you did with your new business pays off.

Failure pays off. Does nobody like what you do? It’s a chance of improvement and that’s how failure pays off.

Every skill. Every extra class. Every curriculum activity. Your every experience in every area of life eventually helps you do something else better. Everything is connected somehow to something.

You did something good for someone. Someone else will do good for you.

It’s about doing and being content with it, without expecting and without attachment to the result.

Everything eventually pays off. You are not wasting your time learning something new for no reason. It’s knowledge, and like everything, it pays off.

Deadline or code quality

Why not both?

Reality matters, even if it is not fair. We can fight it as much as we want, but if we don’t work for real people, real organizations, and real customers, our work is not real.

Working for real people will bring real deadlines.

Why do we even have deadlines?

Because time and money are on the stack and we live in the real world. We don’t get paid to write code, we get paid to make useful and profitable software.

Profit can be money, happiness, or just fun for someone, whatever it is we have to make our product profitable in a period of time or our client loses money and time.

In the journey of writing the best software possible writing good code which is

  • Easy to understand
  • Better handle edge cases
  • Easily configurable

Helps us deliver application quickly instead of undermining our ability to deliver on time.

It’s a myth and an excuse.

We can learn to be fast. We can learn to be good. We can learn to be fast and good.

There is no stopping it. It’s a stereotype. We cling to it as our only lifeline to avoid improving our code quality and delivery time, because improving is hard and we need a shield from all the unfair things which can go wrong.

Constraining ourselves to do the job in a given timeline is part of our job, still thousands of developers around the world waste a lot of money and time giving this excuse to every client they meet.

If we don’t push ourselves, how are we supposed to grow?

If you have to fit clothes inside the only suitcase you got and your flight is going to leave in 30 minutes, believe me, you will do anything in your power to fit those clothes inside the suitcase.

Because if you don’t you will lose your money and your time as well.

Why don’t we implement the same analogy with deadlines?

You Know Less

We always know less. We can’t know more about something. Everything is made of so many things. We possibly can’t comprehend all of them with our minds.

You can read every day. You can learn every day, still a lot of new things to try out, a new piece of information in every interaction.

A lot to learn. It is fascinating to even think about how much information is there.

Yet here we are, every day thinking we know better, we know how things work and we know what is the right thing to do next.

We struggle with problems every day but choose to solve them with our limited perspective, never considering the possibility of learning something new, expanding the horizon of our perspective, or changing it altogether.

We feel vulnerable. We hide behind excuses. We hide behind reasons. Never improving. Never learning.

Why is it hard to read for 30 mins every day? When we scroll through Instagram all night?

Why is it hard to go to Wikipedia and randomly learn something new? When every day we look for happiness in this self-obsessed world?

The goal is to expand. The goal is to move. The goal is to keep learning.

What Will You Do Differently

What will you do differently? What will you build, create or provide differently?

How do I differentiate you from all the thousands of developers I can hire?

How will you perform a job differently which has been already performed millions of times?

Why do I choose you? instead, of someone with the same experience and same knowledge base?

Find that. Show that to me. Show that to your clients, to your audience.

Show what unique you package together. What they will get when they sign up to go on a journey with you?

Your audience can be your clients, your students, your friends, and Interviewer. Anybody.

The rule is as long as you are innovating, trying things differently, and at the same time that benefits your audience. Your audience is hooked.

As long as you try to paint a different picture on the canvas which is given to everybody. Your audience is hooked.

Be different and entertain your audience. Your audience will stay hooked.

Better sooner than later

Catch that bug early. Better sooner than later.

Catching them while developing might be a good place, or when you just deployed the code. How about giving that new feature a last testing round?

Most of the time, Most of us ( the software developers ). Don’t test our code. Sometimes because of overconfidence or sometimes we are just tired.

Sometimes we ignore it. If we found a hole in the feature, we have to stay up late and fix that before leaving.

And sometimes it’s just Friday.

But ignoring it doesn’t solve the problem. It is going to come back. You know that.

When someone makes the payment in our app. It’s going to come back. When someone is doing the most important thing that software is designed to do. You know it. It’s going to come back.

When that bug will come into production. We are doomed. We lose important users, the users who gave a chance to our app after months of development and marketing. In seconds those users choose to go away.

Stop ignoring those bugs. Fix them. Test them. Fix some more. Ship the application. Repeat.

Transparency and Feedback

We tell stories to ourselves. Our mind is designed from the very start to be curious. If we don’t know the answer or reason to something we make one. We tell a different story to ourselves or to be precise we go ahead and assume. We assume the best or the worst of the situation.

If we can’t improve we stay the same. If we stay the same world moves on leaving us behind.

But these assumptions lead to a change in our perspective. We make things from thin air and then act as they were true. We think we are performing well. We think we are performing badly.

Do you want to help your fellow developers? Be brutally honest with them. Be empathetic but let them know where they are going wrong. Be open to feedback from them as well. Never back out from hard conversations.

Most of the time we hide in our positions, meaningless meetings, and by just being busy. We hide because we are not courageous enough to stand up and say we are bad at something.

Because that makes us a failure and failure is bad. You can’t fail. I can’t fail. Once we fail there is no coming back. We fear rejection and feedback which undermine our abilities so much we create a parallel universe where we can’t fail and anybody saying otherwise is not intelligent enough to understand our talent and skills.

We are doomed if we take this path because if we can’t fail we can’t improve. If we can’t improve we stay the same. If we stay the same world moves on leaving us behind. Be open to feedback, know that you can fail. Know that failing is better than not being open to feedback.

Fail. Listen to feedback. Improve. Fail better. Repeat.

There is no such thing as bad code

Either good code or the code which needs your attention to be improved.

There is countless standards of coding. Different people have different styles and it’s impossible to meet all of the standards.

Focus on making your applications good. Everything else comes later. We don’t get paid to code. We get paid to make this world a better place by writing good software.

Writing code which helps us accomplish good software.
That code is of the greatest quality.

Writing better code is improving on the previous iteration. We don’t get everything right on the first try.

My process is, write code. Test it. It works voila!!. Refactor it. Repeat.

Build. Build. Build.

Just build. Build anything. Build everything. Build clones. Build prototypes. Build just for the sake of building. Building things makes you an engineer. Someone who can build. Someone who knows what it takes to build in the face of adversity.

the more you sweat in practice the less you bleed in battle - Norman Schwarzkopf

It’s true. It is going to cost you a little if you build and fail now than when you build for someone else.

It’s like practicing math problems. You go on and solve problems until you ace the exams.

The only difference is we don’t stop once we build one product. We keep going, we keep building.

We keep improving.

On the Journey of Finding Success

We strongly want to believe there is a secret recipe to success. To achieve our goals. We look for it everywhere. In people. In books. On the internet. There are lot of people who can give you those recipes but most of the time they don’t work.

Because we forget the most important thing. They tell you what worked for them. Their audience. Their customers. Their dreams. Not yours.

You have to be flexible. They give you a guideline to work with. How they overcame their fear. How they achieved their dreams.

Now you have to find yours and there is no single, pre-made recipe for it. You have to get out there. Show up every day. Work when you don’t feel like it. Stay consistent. Write every day. Code every day. Build every day. Get feedback from your audience and repeat.