How Do You Become Better?
4 min read

How Do You Become Better?

How Do You Become Better?

Experience.
https://xkcd.com/1171/
It seems so painfully obvious in retrospect but I didn't really fully understand until recently. Studying theory, getting classes, reading articles, how-tos and so on can only get you so far. Experience is where skills are honed and knowledge is built on.

A Little Backstory

As I was browsing Quora, I came about the question, "How do I become a better java developer?". Having grown software-rendered gray hair, I thought I can answer it without too much trouble. I ended up spending a lot of time reflecting on understanding where growth come from and ended up writing this.

After thinking about it for a while, I remembered I was in the same exact situation a few years ago. Having a coffee chat with my mentor at the time, I asked a similar question. "How do I become better?" Her answer? Experience. I needed to go do different projects. I needed to go to different teams. I needed to try different technologies.

Thinking back, I thought, "Is that it?". I didn't fully understand. Do you just become better with time? Well, dear hypothetical reader, yes.

Why Experience?


What is it in experience that makes it so valuable? Throughout your software development career, you are constantly tasked to deliver the seemingly impossible on a daily basis. You have to adapt and survive which leads you to learning skills and gaining knowledge. In fact, gaining experience in software development is pretty much that (in a quote form so that if it sounds cool, someone can quote me in a book)

You gain experience by constantly being asked to deliver perfection in imperfect conditions.

Anyway..

Gaining Experience

You can gain experience by diving into projects. The projects can be school, hobby or during work. Work projects is probably the the best for gaining experience because of the scale, business pressure and ever changing conditions.

The Real World

In school, the conditions are pretty darn good. You have x amount of days to deliver something. The professor checks a few functionalities and you get a grade. Done. Commence celebration.

In hobby projects, you have some time to build something. It may work or it may not. You can spend more time or spend more money depending on what you feel like.

Let's contrast that to "real world" projects. These are just some of the many many common situations:

Time.
When projects start, you are given x amount of days to gather requirements, another x days to build the software and another set of days to ship the software. It's not bad until you realize you can't move realize dates. Requirements took too long or are being added late? Release date stays the same. Critical bugs not reported earlier? Release date stays the same.

Budget. You have $1m for your project. You get just enough money for databases, servers, etc. Oh wait...someone needs half of that for a different project. You can do it with half the money, right?

Technology. You're assigned in a new team. They use a different database. Their architecture is a mystery. Their documentation is a non-existent. Doesn't matter, still have to deliver requested functionality by yesterday.

Load. Your software is live. People are loving it! People are sharing it. Suddenly, your software is going down. It can't seem to handle the 5 people using it at the same time.

The real world won't give you great conditions. Time, money and budget are things that dramatically grow shorter in a moment's notice. That doesn't even include working with company process, coworkers, legacy architecture and so on.

You just have to make do with the current situation.

Developing a Foundation of Knowledge

http://xkcd.com/979/
You have to find a way to deliver when the odds are against you.

You strive to make things work. You ask your coworkers for help. You pray to the StackOverflow gods that you can find someone who has done this before. You test things out. You break things. You fix them. You plead if some features can be delivered later. Figure out how the database is arranged. You figure out why the application is crapping out. Read logs. Fix more things... Eventually something gets shipped.

You might succeed in some projects and you might fail at others. Either way, whenever you work on projects and whenever you deal with the struggles of software development, you are gaining experience. With experience, you gain knowledge. You gain a pool of information that becomes useful in making your life easier. Some of these pool of information are possibly categorized in your brain as the following:

  • What NOT TO EVER DO (again)
  • Steps I do when something breaks (besides panic)
  • List of things that break applications
  • How to find information to fix things
  • Technologies I should use and never use again

When Experience Turns Second Nature


In your next project the sales team has decided that they want a button that sends cat pictures to all your customers at midnight. Hey... in that last project you built an application that grabs dog pictures from google. In another project, you were asked to send email receipts. Suddenly, The new project seem more possible. If you just combine and modify some of your previous stuff maybe, just maybe, you can deliver this one on time.

And... end up barely delivering. But, you've become an expert at cat-picture-finding and emailing-at-midnight functionality. As you move on, you might not even realize that you've delivered a lot of things. You've gained a lot of skills. You have gained vast knowledge. Things become easy because you've been using all the past experiences to learn what to do in the next one.

You repeat the cycle until one day you realize you've become a full-stack rockstar data science javascript growth ninja engineer...with a beard.