How to grow faster in career? (For Beginners)

Vaibhav Arora — Thu, 01 Apr 2021 17:17:32 +0000

I am engineer who has spent 5 years already in software development industry. And I want to tell you some career hacks which have helped me in beginning or in middle of my career.

Hacks Hacks Hacks

There are always hacks to grow faster than someone else, or just yourself as well

Compete with others

Have a healthy competition with others, not only at your level but levels above you as well.
By Healthy competition, I meant -

to learn from them and try to get better than them or at least equivalent to them
to be good to them and not get bitchy. Healthy competition should not bring relation any effect, but on other hand relation should not come between competition always and you loosing out to get better

Why we do this?
Because you want to be valuable, and you are learning how others are valuable more than you in same industry.

It's not always about years, there's more to it.

Have good connections and many connections

Apart from getting skills, your connections building ability can you take very far.
Remember that world is not fair, all of us don't have same currency value, all of us not living same life or getting same opportunities.
Humans trust connections more than strangers, so why not have connections for future jobs, opportunities, knowledge, experiences?

Put more efforts in objectives

Objectives/Goals are what we/others look for. Teams get insane targets, people get insane long targets/goals.
But you got to keep tracking them, complete them, and celebrate once they are done.

Put extra efforts in completing objective you set. Keep setting harder goals, and learn on how to accomplish things in less time.

This will help you in management of time, efforts. This will give you realization that you can work on 1 feature for 1 week, 1 month, and even 1 year. You can do everything from scratch or use 10 libraries and customize it on the top.
In the end, it's your call and results of same you have to carry.

Over a long period of time, achievements matter, efforts are just push to cover distance till achievements

TDD - Learn from experience of Microsoft and IBM

Vaibhav Arora — Tue, 24 Mar 2020 18:20:45 +0000

TDD (Test Driven Development) is good or bad for you?
Answers to this depend on various factors. Maybe you need my opinion instantly, but it's really hard to give you a true answer.
This article is written to help you understand a case study which has collected experience of 4 different teams that have adopted TDD. Those teams are from Microsoft and IBM.

All four teams have different contexts in their working.
You might have similar context like them, or can have different as well.
But if you believe TDD is better for specific tech-stacks, or specific type of project. Then you my friend you definitely should see what these teams were working on.

The project and the teams

IBM

Their legacy product of device drivers has gone through several releases since 1998, and in 2002 they chose a new platform and moved to a completely new architecture and adopted TDD as well.
Their legacy system and new system had similar output, but with different approaches and tech stacks. Comparing both releases is not as balanced as you might be looking for, but still it's valuable to see what difference they had.

Microsoft

The TDD and non-TDD projects under above mentioned areas are developed by teams led by project managers with similar levels of responsibilities and reporting to the same high-level manager.
And here we will get a great balance to compare project values and find what TDD experience has been for teams.

Summary of Team Factors

Varying Contexts in case of these 4 teams

Still, results of case study indicate that pre-release defect density decreased between 40–90% relative to similar projects that did not use the TDD practice. Subjectively, the teams experienced a 15–35% increase in initial development time after adopting TDD.
I am still neither with TDD nor against it, but further in the article you will see some points with which you might be able to relate and understand these teams' experience.

TDD Implementation

The IBM team ….
who was responsible for device drivers parts made a pretty clear process for them in my views.
They got detailed specifications in-hand, they most of the time work on test case first to reduce ambiguity and to validate requirements.

They had set up a build system, which daily extracts the code, runs the test cases, and fires email to all people involved with a report of success and failure.

This daily integration setup came handy for them as part of validation and pushed them to keep things green and get a better report than last day. They target to keep 80% minimum all the time, it can't go below.

And there were legacy teams as well doing similar work with TDD but not that much dedication with TDD as the above team was. It missed quite a few steps.

And then comes, Microsoft teams
They had this Hybrid-TDD approach, where they followed TDD, but didn't adopt agile methodologies completely and also had design meetings and review sessions.
Their testing process had a variety of tools in addition to TDD, such as static analysis, dependency analysis as well as fault injection tools.
As there were 3 different teams here, some were aligned to running TDD in the command line, some had a step of triggering email for analysis purpose. But the teams were lacking any particular coverage measures goal like the IBM one had.

What's the outcome of TDD in quality and productivity for teams?

Increase in development time ranging from 15% to 35% if offset by the reduced maintenance costs due to improvement in quality, an observation that was backed up by the product teams at Microsoft and IBM.

Conclusions of case-study by researchers from this experience

TDD can be applicable in various domains. If you never heard of TDD in your type of project, how about you experience it?
It's team belief that TDD is able to significantly reduce the defect density without significant productivity reduction. There is a balance which people experience and decide which way is better for them and for their work.
Additionally future releases will also experience low defect densities due to use of test assets. Assets like unit, functional, integration.

What to remember if you choose to experience TDD?

Go with facts of other people's experience, and then choose to start or not to start. Don't overwhelm yourself with so many opinions on the internet.
Start TDD from the beginning of projects, because it seems to have advantage if done incrementally and continuously.
Convince the team to add a test case every time a problem is found.
Share unit tests with each other, collaboration is good for betterment of tests.
Track count of bugs found and fixed, source code count, test code count, code coverage, trend across time to always look back if TDD implementation you chose is working for you or not.
Check the morale of team members in the beginning and end of the project. If it's not providing value to them, something definitely needs a change.

References

Paper case study on which this article is based upon - Link to case study paper

DEV Community: Vaibhav Arora